On Tue, Dec 17, 2013 at 11:25:40AM -0500, Bob Doolittle wrote:
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.
I'd blame selinux or /dev/cdrom ownership. Do you see anything in audit.log? What's `ls -lZ /dev/sr0`? Can you `less -F /dev/cdrom` after su'ing to qemu? Dan.