Hi, With VMware ESX, when you edit the CD device you have of course the option of attaching an ISO, but IIRC you also have the option of selecting the physical CDROM device for the Host. There seems no way to do this with oVirt. It would be a really nice addition to the "Change CD" menu to have something like "/dev/cdrom". Is there a technical issue preventing this? Of course that would prevent VM migration such as HA while the CDROM device is attached, but that didn't stop VMware and it would be a valuable addition. Thanks, Bob _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

On Mon, Dec 16, 2013 at 09:58:15AM +0200, Itamar Heim wrote: > On 12/13/2013 09:15 PM, Bob Doolittle wrote: >> Hi, >> >> With VMware ESX, when you edit the CD device you have of course the >> option of attaching an ISO, but IIRC you also have the option of >> selecting the physical CDROM device for the Host. >> >> There seems no way to do this with oVirt. It would be a really nice >> addition to the "Change CD" menu to have something like "/dev/cdrom". Is >> there a technical issue preventing this? Of course that would prevent VM >> migration such as HA while the CDROM device is attached, but that didn't >> stop VMware and it would be a valuable addition. >> >> Thanks, >> Bob >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > 1. at some point i hope spice will allow this to connect remote > cd-rom's and install from them. > 2. please open an RFE (bugzilla) to track this. > 3. you can use a custom hook for this - an adaption on hostusb, or > maybe even vmdisk would work. if you need help with the custom hook, > just ping back on the list. I think Bob asked to access the /dev/cdrom device of the host machine, not the one of the spice client.

Bob, if that's the case, I think you can do it by circomventing Engine and calling `vdsClient -s <host> changeCD /dev/cdrom`; please try it out.

The answer is in the log: "No medium found". Could you retry with a cd inside? Thread-311::DEBUG::2013-12-16 10:09:36,221::BindingXMLRPC::974::vds::(wrapper) client [172.16.0.58]::call vmChangeCD with ('99f89b62-d8e2-4ffd-b2e1-e471beff63b6', '/dev/cdrom') {} Thread-311::INFO::2013-12-16 10:09:36,222::clientIF::350::vds::(prepareVolumePath) prepared volume path: /dev/cdrom Thread-311::DEBUG::2013-12-16 10:09:36,307::libvirtconnection::108::libvirtconnection::(wrapper) Unknown libvirterror: ecode: 38 edom: 18 level: 2 message: cannot open file '/dev/cdrom': No medium found Thread-311::DEBUG::2013-12-16 10:09:36,307::vm::4150::vm.Vm::(_changeBlockDev) vmId=`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 updateDeviceFlags if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self) libvirtError: cannot open file '/dev/cdrom': No medium found Thread-311::DEBUG::2013-12-16 10:09:36,325::BindingXMLRPC::981::vds::(wrapper) return vmChangeCD with {'status': {'message': 'Failed to change disk image', 'code': 41}}

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.