[Users] Physical CDROM access

[Bob Doolittle]

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