On 12/17/2013 11:22 AM, Bob Doolittle wrote:
I inserted some media, and tried again. I got the same output error. I then tried unmounting the media from the host itself, and retried the command, but the same result.
In the log (full log attached) I see:
Thread-3469::DEBUG::2013-12-17 11:16:07,402::BindingXMLRPC::974::vds::(wrapper) cl ient [172.16.0.58]::call vmChangeCD with ('99f89b62-d8e2-4ffd-b2e1-e471beff63b6', '/dev/sr0') {} Thread-3469::INFO::2013-12-17 11:16:07,402::clientIF::350::vds::(prepareVolumePath ) prepared volume path: /dev/sr0 Thread-3469::DEBUG::2013-12-17 11:16:07,456::libvirtconnection::108::libvirtconnec tion::(wrapper) Unknown libvirterror: ecode: 1 edom: 10 level: 2 message: internal error unable to execute QEMU command 'change': Could not open '/dev/sr0': Permiss ion denied Thread-3469::DEBUG::2013-12-17 11:16:07,456::vm::4150::vm.Vm::(_changeBlockDev) vm Id=`99f89b62-d8e2-4ffd-b2e1-e471beff63b6`::updateDeviceFlags failed Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 4148, in _changeBlockDev diskelem.toxml(), libvirt.VIR_DOMAIN_DEVICE_MODIFY_FORCE) File "/usr/share/vdsm/vm.py", line 835, in f ret = attr(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 76, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1755, in updateDevice Flags if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=s elf) libvirtError: internal error unable to execute QEMU command 'change': Could not op en '/dev/sr0': Permission denied Thread-3469::DEBUG::2013-12-17 11:16:07,457::BindingXMLRPC::981::vds::(wrapper) re turn vmChangeCD with {'status': {'message': 'Failed to change disk image', 'code': 41}}
I tried with both /dev/cdrom and /dev/sr0 with the same result.
-Bob
BTW - I note that even after I unmounted the media, the CDROM kept spinning up and down, so it's possible that some host software still claimed ownership of the device, which was causing the error. -Bob