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. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users