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