[Engine-devel] Mapping between supported display protocols and video devices
Hi everyone, Recently the changes #18150, #18677 and #17885 were submitted in order to avoid the selection of display protocols and virtual video cards that are incompatible with the PPC64 architecture and to map the VNC protocol with the standard VGA virtual device, since the Cirrus Logic device is not supported in the PPC64 architecture. I would like some feedback about that. So far, these changes use an existing parameter in the osinfo (called "spiceSupport") to validate if the selected operating system supports SPICE and hide it in the frontend in case it doesn't. They also change the default virtual video card for each display protocol according to new properties in the osinfo, e.g.: os.other.spiceSupport.value = true os.other.devices.vnc.vmDeviceType.value = cirrus os.other.devices.qxl.vmDeviceType.value = qxl os.other_ppc64.spiceSupport.value = false os.other_ppc64.devices.vnc.vmDeviceType.value = vga (This maps the qxl protocol into the qxl device and the VNC protocol into the cirrus device in the x86_64 arch, and the VNC protocol into the VGA device in the PPC64) However, this still has some limitations, such as: * It doesn't allow the user to choose between the different virtual devices that exist and can be used in the VNC protocol (such as the QXL and VMware VGA) * The syntax is ugly. As suggested in the code reviews, it could be a list of supported protocols, e.g.: os.other.displayProtocols = vnc, spice So, how should the engine be modified to allow multiple video cards for each display protocol? What do you think should be done? Thanks, Vitor de Lima
On 08/30/2013 07:33 PM, Vitor de Lima wrote:
Hi everyone,
Recently the changes #18150, #18677 and #17885 were submitted in order to avoid the selection of display protocols and virtual video cards that are incompatible with the PPC64 architecture and to map the VNC protocol with the standard VGA virtual device, since the Cirrus Logic device is not supported in the PPC64 architecture. I would like some feedback about that.
So far, these changes use an existing parameter in the osinfo (called "spiceSupport") to validate if the selected operating system supports SPICE and hide it in the frontend in case it doesn't. They also change the default virtual video card for each display protocol according to new properties in the osinfo, e.g.:
os.other.spiceSupport.value = true os.other.devices.vnc.vmDeviceType.value = cirrus os.other.devices.qxl.vmDeviceType.value = qxl os.other_ppc64.spiceSupport.value = false os.other_ppc64.devices.vnc.vmDeviceType.value = vga (This maps the qxl protocol into the qxl device and the VNC protocol into the cirrus device in the x86_64 arch, and the VNC protocol into the VGA device in the PPC64)
However, this still has some limitations, such as:
* It doesn't allow the user to choose between the different virtual devices that exist and can be used in the VNC protocol (such as the QXL and VMware VGA) * The syntax is ugly. As suggested in the code reviews, it could be a list of supported protocols, e.g.: os.other.displayProtocols = vnc, spice +1 list style is cleaner, expressive and easy to use. spiceSupport was just the way to convert the old code to the osinfo style.
protocol-device mapping can be achieved by pairing them literally - os.other.displayProtocols.value = vnc/cirrus, spice/qxl which reads VNC over cirrus device, SPICE over qxl device. and for ppc64: os.other_ppc64.displayProtocols.value = vnc/qxl, spice/qxl I like this approach better than naming the keys with terms ...devices.vnc.VMDviceType....
So, how should the engine be modified to allow multiple video cards for each display protocol? What do you think should be done?
Thanks, Vitor de Lima _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Sep 1, 2013, at 12:28 , Roy Golan <rgolan@redhat.com> wrote:
On 08/30/2013 07:33 PM, Vitor de Lima wrote:
Hi everyone,
Recently the changes #18150, #18677 and #17885 were submitted in order to avoid the selection of display protocols and virtual video cards that are incompatible with the PPC64 architecture and to map the VNC protocol with the standard VGA virtual device, since the Cirrus Logic device is not supported in the PPC64 architecture. I would like some feedback about that.
So far, these changes use an existing parameter in the osinfo (called "spiceSupport") to validate if the selected operating system supports SPICE and hide it in the frontend in case it doesn't. They also change the default virtual video card for each display protocol according to new properties in the osinfo, e.g.:
os.other.spiceSupport.value = true os.other.devices.vnc.vmDeviceType.value = cirrus os.other.devices.qxl.vmDeviceType.value = qxl os.other_ppc64.spiceSupport.value = false os.other_ppc64.devices.vnc.vmDeviceType.value = vga (This maps the qxl protocol into the qxl device and the VNC protocol into the cirrus device in the x86_64 arch, and the VNC protocol into the VGA device in the PPC64)
However, this still has some limitations, such as:
* It doesn't allow the user to choose between the different virtual devices that exist and can be used in the VNC protocol (such as the QXL and VMware VGA) * The syntax is ugly. As suggested in the code reviews, it could be a list of supported protocols, e.g.: os.other.displayProtocols = vnc, spice +1 list style is cleaner, expressive and easy to use. spiceSupport was just the way to convert the old code to the osinfo style.
protocol-device mapping can be achieved by pairing them literally -
os.other.displayProtocols.value = vnc/cirrus, spice/qxl
which reads VNC over cirrus device, SPICE over qxl device.
and for ppc64:
os.other_ppc64.displayProtocols.value = vnc/qxl, spice/qxl
I like this approach better than naming the keys with terms ...devices.vnc.VMDviceType….
+1 if not too much complicated
So, how should the engine be modified to allow multiple video cards for each display protocol? What do you think should be done?
Thanks, Vitor de Lima _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (3)
-
Michal Skrivanek -
Roy Golan -
Vitor de Lima