oh by the way spcie support is not going away in upstrem nova qemu or libvirt by the way. as stephen mentioned it is going away in rhel and as a result many of the redhat peopel that used to work on it have already moved to other things but i expect it to contiue to be supported in qemu and in other distros. he is correct however that spcie is less well tested and while it can support multipel monitors you simarly can enabel multiple dispaly heads in the libvirt xml so i woudl expect the behavior to be the same as vnc today. On Tue, 2021-06-22 at 12:14 +0100, Sean Mooney wrote:
On Mon, 2021-06-21 at 20:57 +0000, DHilsbos@performair.com wrote:
Just realized that I sent this to Sean, but not the list...
Sean;
Thank you for that pointer to hw_video_model=virtio, that addressed the resolution issue!
Any chance you could point me at a metadata option that would tell libvirt to provide 2 monitor devices? It looks like I need to send the max_outputs=2 to qemu, or libvirt or directly to virtio-vga (I'm not sure which) [1], though I don't see a way to pass that through in nova.virt.libvirt.driver [2]. what you really need is https://github.com/openstack/nova/blob/master/nova/api/validation/extra_spec... but unfortunetly
os:monitors is only supported by hyperv.
we could add support for multiple monitors as a feature but that would not be backportable. really this should be in the hw: namespace and typecialy this should be done with an image property not an flavor extra spec but i guess we could support both.
this likely shoudl be handeled as a small specless blueprint or short spec.
i would suggest using "hw_virtual_displays=#" and "hw:virtual_displays=#" personally as the image and flavor extra specs to have something easy to understand.
we could then use that to set the display heads on the the video device. https://libvirt.org/formatdomain.html#video-devices
unfortunetly i dont know of ay way to do this in nova today with libvirt that you can use but if you have time to work on it i woudl be supprotive of adding this functionality.
if you did end up working on this and had a spec i wouls also consider wether you wanted to enable accel3d feature to expose opengel to the guest. that requires a little more setup on the host to get working but it may or may not be useful for your vdi usecase. from a nova point of view exposing accel3d is relitivly trivial but you likely woudl want to be able to schdule to a host that supports it so we woudl want to consider if a standard trait shoudl be exposed for that or if it should be left to the operator to do manuyally with a custom trait.
anyway i hope that helps at least somewhat. i guess for now you will have to use the larger resolution.
As to how GoToMyPC works... I don't know, but I believe it captures the framebuffer.
[1] https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/ [2] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py
Thank you,
Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos@PerformAir.com www.PerformAir.com
-----Original Message----- From: Sean Mooney [mailto:smooney@redhat.com] Sent: Monday, June 21, 2021 4:57 AM To: Dominic Hilsbos; laurentfdumont@gmail.com; openstack-discuss@lists.openstack.org Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE
We're trying to virtualize desktops for remote workers. Guests will be Windows. Remote connection method will be GoToMyPC. As such, I need the OS to believe either 1) it has 2 1920 x 1080 monitors, or 2) it has a single 3840 x 1080 monitor. Neither of which have I found a way to do in VNC. i am not sure the resoltution that rdp or whatever GoToMyPC uses will be affected by the use of vnc or spcice on the host. I think this is related to the video model used in the guets unless GoToMyPC is running on the host and connecting the the qemu process. thats not normally something we would recommend but if its directly conecting to the qemu
On Fri, 2021-06-18 at 20:44 +0000, DHilsbos@performair.com wrote: process then the use of vnc or spice might be a factor
have you tried changing the video model to virtio for example, that should enabel more resolutions in the guest. i know that usign RDP in a windows guest with hw_video_model=virtio in the image does allow higher resolutions and i think it enables multi monitor support too.
Thank you,
Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos@PerformAir.com www.PerformAir.com
From: Laurent Dumont [mailto:laurentfdumont@gmail.com] Sent: Friday, June 18, 2021 12:39 PM To: Dominic Hilsbos Cc: stephenfin@redhat.com; openstack-discuss Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE
Are you using the Openstack console itself? You might have more flexibility with a dedicated VNC server inside the VM and connect directly to it. So you would not be tied to the Openstack VNC support which I dont think was ever designed for graphical usage. More of a "it's 2AM, server is crashed and I need a way in!".
On Fri, Jun 18, 2021 at 1:58 PM <DHilsbos@performair.com> wrote: Stephen;
Thank you for the information.
What's the replacement? Is VNC getting improvements to allow higher resolutions, and multi-monitor, in the guest?
We've already decided to transition our OpenStack cluster away from CentOS, as RDO doesn't package some of the OpenStack projects we'd like to use, and RedHat has lost our trust.
Thank you,
Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos@PerformAir.com www.PerformAir.com
-----Original Message----- From: Stephen Finucane [mailto:stephenfin@redhat.com] Sent: Friday, June 18, 2021 10:33 AM To: Dominic Hilsbos; openstack-discuss@lists.openstack.org Subject: Re: [ops][nova][spice][victoria] Switch from VNC to SPICE
On Fri, 2021-06-18 at 16:53 +0000, DHilsbos@performair.com wrote:
All;
We have a Victoria cluster, and I'd like to switch from VNC to SPICE. Cluster is installed with packages (RDO), and configured manually.
I have located https://docs.openstack.org/nova/victoria/admin/remote-console-access.html , but this doesn't tell me which services need to be installed on which servers.
Looking at packages, I'm fairly certain nova-spicehtml5proxy (openstack-nova-spicehtml5proxy on CentOS 8) needs to be installed where the nova-novncproxy is currently.
I also suspect that qemu-kvm-ui-spice needs to be installed on the nova-compute nodes. Is spice-server needed on the nova-compute nodes?
Not an answer, but I'd be very careful about building solutions based on SPICE. It has been deprecated in RHEL 8.3 and recent versions of Fedora and is slated for removal in RHEL 9, as this bug [1] points out. It is also receives very little attention in nova as some deployments tooling (such as Red Hat OSP) has not supported it for some time. There's a non-zero chance support for this console type will be dropped entirely in some future release.
Stephen
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1946938
Thank you,
Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos@PerformAir.com www.PerformAir.com