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