we should rather use standard VGA
We need to remove the QXL for every guest since the usage of centos-stream 9 hosts. For RHEL9, we probably should use virtio-vga driver.
Related: Can the oVirt developers please enhance the setDeviceByResource() method in "OvfReader.java" such that it parse VMD_DEVICE as well, and if that one says "vga", then the method please pick "VmDeviceType.VGA"? [Libguestfs] specifying a standard VGA video controller in OVF for oVirt Message-Id: <6c7b94b5-e234-90e5-9fd7-c48b87442c63> https://listman.redhat.com/archives/libguestfs/2021-November/msg00149.html
(In reply to Laszlo Ersek from comment #2) > Related: > > Can the oVirt developers please enhance the setDeviceByResource() > method in "OvfReader.java" such that it parse VMD_DEVICE as well, > and if that one says "vga", then the method please pick > "VmDeviceType.VGA"? > > [Libguestfs] specifying a standard VGA video controller in OVF for oVirt > Message-Id: <6c7b94b5-e234-90e5-9fd7-c48b87442c63> > https://listman.redhat.com/archives/libguestfs/2021-November/msg00149.html Apparently this part is already being supported. In OvfReader::readVmDevice() if (selectSingleNode(node, VMD_DEVICE, _xmlNS) != null && !StringUtils.isEmpty(selectSingleNode(node, VMD_DEVICE, _xmlNS).innerText)) { vmDevice.setDevice(String.valueOf(selectSingleNode(node, VMD_DEVICE, _xmlNS).innerText)); } else { setDeviceByResource(node, vmDevice); } Given: <Item><rasd:Caption>Graphical Controller</rasd:Caption><rasd:InstanceID>2834786b-e9d0-4419-8e6a-c4843fed2f9c</rasd:InstanceID><rasd:ResourceType>32768</rasd:ResourceType><rasd:VirtualQuantity>1</rasd:VirtualQuantity><rasd:SinglePciQxl>false</rasd:SinglePciQxl><Type>video</Type><Device>vga</Device><rasd:Address></rasd:Address><BootOrder>0</BootOrder><IsPlugged>true</IsPlugged><IsReadOnly>false</IsReadOnly><Alias></Alias><SpecParams><vram>16384</vram></SpecParams></Item> It will be read as VGA. If Device element isn't provided, it will go into the setDeviceByResource().
Laszlo, you wrote on the email thread that in virt-v2v we have: 678 (* We always add a qxl device when outputting to RHV. 679 * See RHBZ#1213701 and RHBZ#1211231 for the reasoning 680 * behind that. 681 *) 682 let qxl_resourcetype = 683 match ovf_flavour with 684 | OVirt -> 32768 (* RHBZ#1598715 *) 685 | RHVExportStorageDomain -> 20 in 686 e "Item" [] [ 687 e "rasd:Caption" [] [PCData "Graphical Controller"]; 688 e "rasd:InstanceId" [] [PCData (uuidgen ())]; 689 e "rasd:ResourceType" [] [PCData (string_of_int qxl_resourcetype)]; 690 e "Type" [] [PCData "video"]; 691 e "rasd:VirtualQuantity" [] [PCData "1"]; 692 e "rasd:Device" [] [PCData "qxl"]; 693 ] The OVF specification doesn't include the "Device" tag which aligns with the code Liran quoted above So virt-v2v should write "Device" instead of "rasd:Device" - the latter is not parsed by oVirt it seems
*** Bug 2000047 has been marked as a duplicate of this bug. ***
video RAM size related updates are needed in ovirt-engine, or else we need to make the virt-v2v-generated XML fragment more explicit: https://listman.redhat.com/archives/libguestfs/2021-November/msg00264.html
I would urge this to be reconsidered. As long standing user of RHEV/oVirt removing SPICE/QXL would make our internal VDI system, which serves a little over 1,000 users, no longer serviceable. We would be immediately forced to look at competing software. VNC is non-comparable to SPICE in almost every conceivable way.
(In reply to Alex McWhirter from comment #7) > I would urge this to be reconsidered. As long standing user of RHEV/oVirt > removing SPICE/QXL would make our internal VDI system, which serves a little > over 1,000 users, no longer serviceable. We would be immediately forced to > look at competing software. VNC is non-comparable to SPICE in almost every > conceivable way. I second this. SPICE is why we started using RHEV back in v2.2 days. It is the reason we still use RHV today.
(In reply to Alex McWhirter from comment #7) > I would urge this to be reconsidered. As long standing user of RHEV/oVirt > removing SPICE/QXL would make our internal VDI system, which serves a little > over 1,000 users, no longer serviceable. We would be immediately forced to > look at competing software. VNC is non-comparable to SPICE in almost every > conceivable way. (In reply to Colin Coe from comment #8) > I second this. SPICE is why we started using RHEV back in v2.2 days. It is > the reason we still use RHV today. Note there are two distinct topics raised here. This bug was specifically about resolving QXL usage in oVirt on CentOS 9 platforms, but folks have raised the distinct question of SPICE support in RHEV that they have deployed today. First, on QXL usage, SPICE can work with many graphics devices including modern options like virtio-vga, which continue to provide a good solution. Second, on SPICE removal, nothing is happening to SPICE in RHEL-8.x which is the platform used by the RHEV product that anyone has deployed today. While SPICE was deprecated in RHEL-8.3: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.3_release_notes/rhel-8-3-0-release#deprecated-functionality_virtualization https://access.redhat.com/solutions/5414901 it still exists in all subsequent RHEL-8.x updates. The deprecation was rather an early warning that a future /major/ RHEL release would not be likely to include SPICE, which is what is seen in RHEL-9 or CentOS-9-Stream. Again this doesn't affect RHEV product users, because that is based on the RHEL-8.x platform which continues to have SPICE support. Hopefully this alleviates some concerns about current usage of SPICE in RHEV for VDI.
*** Bug 2030598 has been marked as a duplicate of this bug. ***
We are past 4.5.0 feature freeze, please re-target.
Summarizing an offline discussion about this part: 1. It won't be enough the remove QXL from osinfo because we wish existing VMs to keep running after upgrading to centos stream 9 2. We should differentiate oVirt and RHV since QXL should still be available in RHV 3. Without a new cluster-level it will be very challenging to realize when we should not use QXL anymore
*** Bug 2074484 has been marked as a duplicate of this bug. ***
*** Bug 1976605 has been marked as a duplicate of this bug. ***
Liran, can you please also check that if we start with a VM with SPICE+VNC, then make it headless and then add VNC we end up with VNC/VGA?
(In reply to Arik from comment #15) > Liran, can you please also check that if we start with a VM with SPICE+VNC, > then make it headless and then add VNC we end up with VNC/VGA? API - yes (adding back VNC graphics). Unfortunately, UI will set it them (if they are not server type and UEFI) to SPICE/QXL. If they are set with server type and UEFI, it will be VNC/Bochs. I'll look into defaulting the UI from headless to VNC/VGA.
(In reply to Liran Rotenberg from comment #16) > Unfortunately, UI will set it them (if they are not server type and UEFI) to > SPICE/QXL. If they are set with server type and UEFI, it will be VNC/Bochs. > I'll look into defaulting the UI from headless to VNC/VGA. That's not that important, when you switch-off headless-mode, you see in the UI what you get so if you want to use something else, it's easy to change
(In reply to Liran Rotenberg from comment #16) > (In reply to Arik from comment #15) > > Liran, can you please also check that if we start with a VM with SPICE+VNC, > > then make it headless and then add VNC we end up with VNC/VGA? > > API - yes (adding back VNC graphics). And thanks for the confirmation on that, I updated the doc text to reflect that
Verified: ovirt-engine-4.5.1.2-0.11.el8ev vdsm-4.50.1.3-1.el8ev.x86_64 qemu-kvm-6.2.0-11.module+el8.6.0+15489+bc23efef.1.x86_64 libvirt-8.0.0-5.2.module+el8.6.0+15256+3a0914fe.x86_64 Verification scenario: 1. Test cluster compatibility defaults, see https://bugzilla.redhat.com/show_bug.cgi?id=1949004#c4 Verify Bochs/VNC functionality with the next features: 2. Import VM from VMware - will be supported with virt-v2v-1.45.92-1.el9 3. OVA export & OVA import 4. Make template and create VM from template. 5. VM migration 6. Create new instance type with Bochs/VNC and create new VM using this instance type. 7. VM pool
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: RHV Manager (ovirt-engine) [ovirt-4.5.1] security, bug fix and update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:5555
Due to QE capacity, we are not going to cover this issue in our automation