[Users] Physical CDROM access
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
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@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. Thanks, Itamar
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@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.
On 12/16/13 08:44, Dan Kenigsberg wrote:
> 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@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.
That's right. I never even thought of the spice client case. Although
that also sounds useful it would be much more complex. Luckily it's not
what I need. I'll file that RFE in any case since it does sound useful,
in addition to this one.
> 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.
It appears this command is slightly incorrect, I believe it should be:
vdsClient -s <host> changeCD <VM-UUID> /dev/cdrom
when I try this, however, I get an error: "Failed to change disk image"
I've attached the vdsm.log file. There is also one suspicious entry in
syslog, although I think it was from before I tried this particular command:
Dec 16 10:03:57 xion2 vdsm vm.Vm WARNING
vmId=`99f89b62-d8e2-4ffd-b2e1-e471beff63b6`::_readPauseCode unsupported
by libvirt vm
I had previously tried a 'list table' and a 'help' command to see how
vdsClient worked. It is more likely a result of one of those given the
timestamp.
Thanks,
Bob
On Mon, Dec 16, 2013 at 10:23:36AM -0500, Bob Doolittle wrote:
> On 12/16/13 08:44, Dan Kenigsberg wrote:
> >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@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.
>
> That's right. I never even thought of the spice client case.
> Although that also sounds useful it would be much more complex.
> Luckily it's not what I need. I'll file that RFE in any case since
> it does sound useful, in addition to this one.
>
> >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.
>
> It appears this command is slightly incorrect, I believe it should be:
>
> vdsClient -s <host> changeCD <VM-UUID> /dev/cdrom
thanks for the correction.
>
> when I try this, however, I get an error: "Failed to change disk image"
>
> I've attached the vdsm.log file. There is also one suspicious entry
> in syslog, although I think it was from before I tried this
> particular command:
>
> Dec 16 10:03:57 xion2 vdsm vm.Vm WARNING
> vmId=`99f89b62-d8e2-4ffd-b2e1-e471beff63b6`::_readPauseCode
> unsupported by libvirt vm
> I had previously tried a 'list table' and a 'help' command to see
> how vdsClient worked. It is more likely a result of one of those
> given the timestamp.
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 09:39 AM, Dan Kenigsberg wrote:
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}}
Thanks - I missed this in the log, which is quite verbose. Now I know better what to look for. 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
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
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.
participants (3)
-
Bob Doolittle -
Dan Kenigsberg -
Itamar Heim