Bug 1961107
Summary: | Change video type from qxl to vga after v2v conversion | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | mxie <mxie> | ||||
Component: | virt-v2v | Assignee: | Laszlo Ersek <lersek> | ||||
Status: | CLOSED ERRATA | QA Contact: | mxie <mxie> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | urgent | ||||||
Version: | 9.0 | CC: | chhu, jsuchane, juzhou, kkiwi, kraxel, lersek, mdean, mxie, mzhan, rjones, tyan, tzheng, vrozenfe, vwu, xiaodwan, yvugenfi | ||||
Target Milestone: | beta | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | virt-v2v-1.45.92-1.el9 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2022-05-17 13:41:55 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 2011713 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
I think reading Kraxel's analysis here, we should probably just use Standard VGA for everything: https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#VGA Gerd: I've got a few questions about Windows support which are not answered in your page above as far as I can tell: (1) Standard VGA and virtio-vga are listed as "VGA compatible". Does this mean Windows ought to just work (albeit at a lower resolution)? There are not any Windows drivers that I can find for either. We do not need high performance, only the ability to log in and perform simple admin tasks. (2) Do you have any objection to us just dropping QXL support from virt-v2v everywhere? Note we have to support some older guests (eg. RHEL 6, Windows 7), and I'm not sure at the moment if they will just work with Standard VGA. (In reply to Richard W.M. Jones from comment #1) > I think reading Kraxel's analysis here, we should probably just use > Standard VGA for everything: > > https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#VGA > > Gerd: I've got a few questions about Windows support which are not > answered in your page above as far as I can tell: First: we have virtio-gpu windows drivers meanwhile. Not sure whenever they are shipped on our driver iso and what the support status is. https://github.com/virtio-win/kvm-guest-drivers-windows (viogpu subdir) > (1) Standard VGA and virtio-vga are listed as "VGA compatible". > Does this mean Windows ought to just work (albeit at a lower resolution)? Yes. In BIOS mode Windows can use whatever vgabios offers and can switch resolutions at runtime. In UEFI mode Windows will use the GOP provided by OVMF as-is and can not switch resolutions at runtime (like efifb in linux). GOP resolution can be configued in OVMF firmware settings. [ This is without the new virtio-gpu driver for Windows, with the driver installed restrictions should go away but I didn't try that myself yet. ] If you don't want bother installing the windows virtio-gpu driver there is little reason to prefer virtio-vga over standard vga though. > (2) Do you have any objection to us just dropping QXL support from > virt-v2v everywhere? Note we have to support some older guests > (eg. RHEL 6, Windows 7), and I'm not sure at the moment if they > will just work with Standard VGA. No objections. I have yet to find a guest which does not work with standard vga ;) I'm just resetting the assignee back to the backlog. This should have been assigned to me, not sure why Vadim was ever involved. The fix here is to use standard VGA (see comment 1 and comment 2) which we'll try to look at for RHEL 9. Since it's described as being "in the backlog", removing the ITR until it's planned to be in a release. [virt-v2v PATCH wave 1] lib/types: remove "source video: QXL" constructor Message-Id: <20211020163503.9525-1-lersek> https://listman.redhat.com/archives/libguestfs/2021-October/msg00100.html (In reply to Laszlo Ersek from comment #14) > [virt-v2v PATCH wave 1] lib/types: remove "source video: QXL" constructor > Message-Id: <20211020163503.9525-1-lersek> > https://listman.redhat.com/archives/libguestfs/2021-October/msg00100.html Commit 17e7cbffb9e5. I have some (simple, introductory) patches for this, but before I can progress, I need to ask some questions. I plan to structure the patch series as follows: (a) Introduce the Standard_VGA constructor for the "guestcaps_video_type" variant. At this point, only "assert false" expressions are added to patterns that match (sub)expressions of type "guestcaps_video_type", so that the OCaml compiler not emit new "incomplete matches" warnings (which we treat as errors). (b) Implement actual handling for Standard_VGA in the conversion modules "convert_linux.ml" and "windows_virtio.ml". (c) Implement actual handling for Standard_VGA in the output modules (OVF, JSON, libvirt XML, OpenStack, direct QEMU cmdline) (d) Policy change: if the requested guest caps do not express a preference for any particular video type, pick Standard_VGA over *both* QXL *and* Cirrus. This will likely require updates to the test suite as well. (e) Modify patterns that match "guestcaps_video_type" to "assert false" upon seeing QXL. (f) Remove the QXL data constructor altogether (with the "assert false" branches). The idea behind this structuring is that I'd like to keep the series bisectable. Problem: in step (c), I have no clue about expressing "standard VGA" in the following output formats: - OVF: this format seems to require QXL in *all* cases (with reference to bug 1213701, bug 1211231, bug 1598715). Can we just drop QXL here? And how exactly do I express "standard VGA" in the output? ("Open Virtualization Format Specification" seems to be a public spec from the DMTF, but it doesn't even mention "qxl", which virt-v2v uses at the moment.) - JSON: this seems like an ad-hoc format, from commit fba6a498d472 ("v2v: add -o json output mode", 2019-04-01). How do I express "standard VGA" in it? The JSON format seems to use ad-hoc key names such as "block-bus" and "net-bus", without any particular specification for the *domains* of the permissible values of those keys. - OpenStack: same as the JSON case, except use "hw_video_model" and similar for the field names. How do I express "standard VGA"? Should I rely on <https://docs.openstack.org/glance/rocky/admin/useful-image-properties.html>? (It suggests "vga".) Thanks. [virt-v2v RFC wave 2 00/10] replace QXL with standard VGA Message-Id: <20211101170618.31274-1-lersek> https://listman.redhat.com/archives/libguestfs/2021-November/msg00007.html [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 [virt-v2v wave 2 PATCH v1 00/16] replace QXL (and Cirrus) with standard VGA Message-Id: <20211113222959.8159-1-lersek> https://listman.redhat.com/archives/libguestfs/2021-November/msg00150.html (In reply to Laszlo Ersek from comment #19) > [virt-v2v wave 2 PATCH v1 00/16] replace QXL (and Cirrus) with standard VGA > Message-Id: <20211113222959.8159-1-lersek> > https://listman.redhat.com/archives/libguestfs/2021-November/msg00150.html Pre-requisite commits from Rich (forgot to mention them earlier): 1. https://github.com/libguestfs/virt-v2v/commit/b28cd1dcfeb40e7002e8d0b0ce9dcc4ce86beb6c 2. https://github.com/libguestfs/virt-v2v/commit/f0afc439524853508938b2bfc758896f053462e3 IIUC Liran is telling us that we need to change the VirtualSystem/DefaultDisplayType element (again!), from 1 to 2. Please refer to the history of the VirtualSystem/DefaultDisplayType element: https://github.com/libguestfs/virt-v2v/commit/b6189a8e18f3 -> added it as 1 https://github.com/libguestfs/virt-v2v/commit/5f2d3d06f383 -> changed it to 2 https://github.com/libguestfs/virt-v2v/commit/ab89c9dabe3e -> changed it back to 1 Now we need to change it to 2 again. :/ [virt-v2v wave 2 PATCH v2 00/16] replace QXL (and Cirrus) with standard VGA Message-Id: <20211202094637.8020-1-lersek> https://listman.redhat.com/archives/libguestfs/2021-December/msg00000.html (In reply to Laszlo Ersek from comment #40) > [virt-v2v wave 2 PATCH v2 00/16] replace QXL (and Cirrus) with standard VGA > Message-Id: <20211202094637.8020-1-lersek> > https://listman.redhat.com/archives/libguestfs/2021-December/msg00000.html Upstream commit range ddc96fc5aae4..dbbdd4c20a6a. We should get these patches via rebase, not by backporting. We don't seem to have a dedicated virt-v2v rebase BZ at this point; however, I'm quite sure we'll rebase for the sake of modularization (bug 2011713), so I'm making this bug dependend on that one. Removal of the TestOnly keyword was necessary to get check-gitbz to pass. I will add it back in a moment. Test the bug with below builds: virt-v2v-1.45.93-1.el9.x86_64 libguestfs-1.46.0-5.el9.x86_64 guestfs-tools-1.46.1-5.el9.x86_64 nbdkit-1.28.2-2.el9.x86_64 libvirt-libs-7.9.0-1.el9.x86_64 qemu-img-6.1.0-7.el9.x86_64 openssh-8.7p1-5.el9.x86_64 Steps: 1.Convert different guests from VMware to rhv by virt-v2v #virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -ip /home/passwd -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data -b ovirtmgmt $ 1.1 Check the video type of guest after v2v conversion, get below result: Guest Video_type Checkpoints - esx7.0-ubuntu20.04.2-x64-uefi vga Only bug1652480 - esx7.0-rhel8.5-x86_64 vga Only bug1642021 - esx7.0-sles15sp2-x86_64-vmware-tools vga PASS - esx6.7-debian10.1.0-i386 vga PASS - esx6.7-win11-x86_64 vga PASS - esx6.7-opensuse42.3-x86_64 vga PASS 2.Convert different guests from VMware to openstack16.2 by virt-v2v 2.1 # virt-v2v -ic vpx://vsphere.local%5cAdministrator.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd -o openstack -oo server-id=v2v-appliance-rhel9_0 $guest_name 2.2 launch the volume as instance on OSP env after v2v conversion 2.3 Check video type of guest libvirtxml in compute node and check if checkpoints of guest are passed, get below result: Guest Video_type Checkpoints - esx7.0-win11-x86_64 vga PASS - esx7.0-rhel8.5-x86_64 vga Only bug1642021 - esx7.0-sles15sp2-x86_64 vga PASS - esx7.0-debian10.1.0-x86_64 vga PASS - esx7.0-ubuntu20.04.2-x86_64 vga Only bug1652480 - esx7.0-opensuse42.3-x86_64 vga PASS 3.Convert different guests from VMware to local libvirt by virt-v2v 3.1 Check the video type of guest after v2v conversion, get below result: Guest Video_type Checkpoints - esx7.0-ubuntu20.04.2-x64-uefi vga Only bug1652480 - esx7.0-rhel8.5-x86_64 vga Only bug1642021 - esx7.0-sles15sp2-x86_64-vmware-tools vga PASS - esx6.7-debian10.1.0-i386 vga PASS - esx6.7-win11-x86_64 vga PASS - esx6.7-opensuse42.3-x86_64 vga PASS 4.Convert different guests from VMware to json format by virt-v2v 4.1 # virt-v2v -ic vpx://vsphere.local%5cAdministrator.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd -o json -os /home/json $guest_name 4.2 Check video type in guest.json file # cat $guest_name.json |grep video "video": "qxl", 4.3 Get below result: Guest Video_type - esx7.0-ubuntu20.04.2-x64-uefi qxl - esx7.0-rhel8.5-x86_64 qxl - esx7.0-sles15sp2-x86_64-vmware-tools qxl - esx6.7-debian10.1.0-i386 qxl - esx6.7-win11-x86_64 qxl - esx6.7-opensuse42.3-x86_64 qxl Hi Laszlo, The video type is not vga when target is json format, please check the result of step4, thanks Hi Ming Xie, unfortunately, I have no idea. You mention virt-v2v-1.45.93-1.el9.x86_64. I've now checked the SRPM for that build (buildID=1815433 in Brew). I've run: $ rpm -ivh virt-v2v-1.45.93-1.el9.src.rpm $ cd ~/rpmbuild/SPECS $ rpmbuild --define 'rhel 1' -bp virt-v2v.spec $ cd ../BUILD/virt-v2v-1.45.93/ $ grep -r -i qxl The only matches are in documentation files (under po-docs/, po/, and docs/), and in *comments* in "lib/create_ovf.ml". In particular, "output/create_json.ml" outputs "vga", not "qxl". Anyway, I think I have the credentials for your server, so I'll try to reproduce myself. (Not clearing the needinfo on myself just yet.) I should note that the json output is a weird templated thing (because CNV at the time was not confident enough in the stability of their yaml files to bake the format into virt-v2v so they wanted a template that they could fiddle with at will -- we should revisit this decision). Anyhow it's entirely possible that the qxl string comes from the template and not from virt-v2v. https://libguestfs.org/virt-v2v-output-local.1.html#output-to-json (In reply to Laszlo Ersek from comment #47) > Hi Ming Xie, > > unfortunately, I have no idea. > > You mention virt-v2v-1.45.93-1.el9.x86_64. I've now checked the SRPM for > that build (buildID=1815433 in Brew). I've run: > > $ rpm -ivh virt-v2v-1.45.93-1.el9.src.rpm > $ cd ~/rpmbuild/SPECS > $ rpmbuild --define 'rhel 1' -bp virt-v2v.spec > $ cd ../BUILD/virt-v2v-1.45.93/ > $ grep -r -i qxl > > The only matches are in documentation files (under po-docs/, po/, and > docs/), and in *comments* in "lib/create_ovf.ml". In particular, > "output/create_json.ml" outputs "vga", not "qxl". > > Anyway, I think I have the credentials for your server, so I'll try to > reproduce myself. (Not clearing the needinfo on myself just yet.) Sorry, I forgot to update virt-v2v to 1.45.93-1 when converting guest to json because I was verifying this bug and bug2011713 at the same time, retest the step4 of comment46, get below result, so the bug has been fixed Guest Video_type - esx7.0-ubuntu20.04.2-x64-uefi vga - esx7.0-rhel8.5-x86_64 vga - esx7.0-sles15sp2-x86_64-vmware-tools vga - esx6.7-debian10.1.0-i386 vga - esx6.7-win11-x86_64 vga - esx6.7-opensuse42.3-x86_64 vga Hi Ming Xie, thank you for re-checking; that's a relief ;) Laszlo Verify the bug with below builds: virt-v2v-1.45.97-1.el9.x86_64 libguestfs-1.46.1-2.el9.x86_64 guestfs-tools-1.46.1-6.el9.x86_64 libvirt-libs-8.0.0-1.el9.x86_64 qemu-img-6.2.0-4.el9.x86_64 nbdkit-1.28.4-2.el9.x86_64 libnbd-1.10.3-1.el9.x86_64 openssh-8.7p1-6.el9.x86_64 Steps: 1.Convert different guests from VMware to rhv by virt-v2v # virt-v2v -ic vpx://root@vcenter_ip/dc/esxi_host/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data -b ovirtmgmt $guest 1.1 Check the video type of guest after v2v conversion, get below result: Guest Video_type Checkpoints - esx7.0-ubuntu20.04.2-x64-uefi vga bug1652480 and bug2042479 - esx7.0-rhel8.5-x86_64 vga bug1642021 and bug2042479 - esx7.0-sles15sp2-x86_64-vmware-tools vga bug2042479 and bug2042479 - esx6.7-debian10.1.0-i386 vga bug2042479 and bug2042479 - esx7.0-win11-x86_64 vga bug2042479 and bug2042479 - esx6.7-opensuse42.3-x86_64 vga bug2042479 and bug2042479 2.Convert different guests from VMware to openstack16.2 by virt-v2v 2.1 # virt-v2v -ic vpx://root@vcenter_ip/dc/esxi_host/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd -o openstack -oo server-id=v2v-appliance-rhel9_0 $guest_name 2.2 launch the volume as instance on OSP env after v2v conversion 2.3 Check video type of guest libvirtxml in compute node and check if checkpoints of guest are passed, get below result: Guest Video_type Checkpoints - esx7.0-win2022-x86_64-uefi vga PASS - esx7.0-rhel8.3-efi-without-secure vga Only bug1642021 - esx7.0-sles15sp2-x86_64 vga PASS - esx7.0-debian10.9.0-x64-uefi vga Bug 1965176 - esx7.0-ubuntu20.04.2-x86_64-uefi vga Only bug1652480 - esx7.0-opensuse15.2-x86_64-efi vga PASS 3.Convert different guests from VMware to local libvirt by virt-v2v 3.1 #virt-v2v -ic vpx://root@vcenter_ip/dc/esxi_host/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd $guest 3.2 Check the video type of guest after v2v conversion, get below result: Guest Video_type Checkpoints - esx7.0-ubuntu20.04.2-x64 vga Only bug1652480 - esx7.0-rhel6.10-x86_64 vga Only bug1642021 - esx7.0-sles15sp2-x86_64-vmware-tools vga PASS - esx7.0-debian10.1.0-i386 vga PASS - esx7.0-win2022-x86_64 vga PASS - esx7.0-opensuse42.3-x86_64 vga PASS Result: Guest will get vnc+vga graphic after v2v conversion, move the bug from ON_QA to VERIFIED *** Bug 1817416 has been marked as a duplicate of this bug. *** 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 (new packages: virt-v2v), 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/RHEA-2022:2566 |
Created attachment 1783988 [details] v2v-convert-linux-guest-to-rhel9-qxl.log Description of problem: Change video type of linux guest from qxl to other after v2v conversion if target is rhel9 Version-Release number of selected component (if applicable): virt-v2v-1.44.0-1.el9.1.x86_64 libguestfs-1.45.5-1.el9.x86_64 libvirt-7.0.0-6.el9.x86_64 qemu-kvm-6.0.0-2.el9.x86_64 guestfs-tools-1.46.1-2.el9.x86_64 How reproducible: 100% Steps to Reproduce: 1.Convert a linux guest from VMware to local libvirt by v2v on rhel9 # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 esx7.0-rhel8.3-x86_64 -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.3-x86_64 -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 2.3] Creating an overlay to protect the source from being modified [ 3.3] Opening the overlay [ 13.6] Inspecting the overlay [ 27.9] Checking for sufficient free disk space in the guest [ 27.9] Estimating space required on target for each disk [ 27.9] Converting Red Hat Enterprise Linux 8.3 (Ootpa) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 125.7] Mapping filesystem data to avoid copying unused and blank areas [ 127.7] Closing the overlay [ 128.0] Assigning disks to buses [ 128.0] Checking if the guest needs BIOS or UEFI to boot [ 128.0] Initializing the target -o libvirt -os default [ 128.0] Copying disk 1/1 to /var/lib/libvirt/images/esx7.0-rhel8.3-x86_64-sda (raw) (100.00/100%) [ 335.7] Creating output metadata virt-v2v: warning: could not define libvirt domain: unsupported configuration: domain configuration does not support video model 'qxl'. The libvirt XML is still available in ‘/tmp/v2vlibvirte747d1.xml’. Try running ‘virsh -c qemu:///system define /tmp/v2vlibvirte747d1.xml’ yourself instead. [ 335.8] Finishing off Actual results: As above description Expected results: As qxl has been removed from rhel9, should change video type of linux guest to other after v2v conversion Additional info: