[Users] Physical CDROM access

[Dan Kenigsberg]

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.