QXL will nowadays present a basic VGA video card even to guests
which don't have QXL drivers, so it should always be a safe choice.

Should change default video type from cirrus to qxl for windows guest too if target openstack version >=15, this is because windows guests(except win2008r2 and win7) has no colour in desktop and resolution is abnormal after v2v converting to OSP16.1, pls refer to screenshot"osp16-windows-guest". Check guest libvirtxml in compute node of OSP16.1 environment, can find windows guest has cirrus in video attribute

()[root@overcloud-novacompute-0 /]# virsh dumpxml instance-00000009
<domain type='kvm' id='12'>
  <name>instance-00000009</name>
  <uuid>3cbea0d6-8b01-496a-91bc-6d19c1640d14</uuid>
  <metadata>
    <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0">
      <nova:package version="20.3.1-0.20200626213433.38ee1f3.el8ost"/>
      <nova:name>win2019</nova:name>
......
 <graphics type='vnc' port='5900' autoport='yes' listen='192.168.24.20'>
      <listen type='address' address='192.168.24.20'/>
    </graphics>
    <video>
      <model type='cirrus' vram='16384' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
......

Created attachment 1712358 [details]
osp16-windows-guest.png

Starting some time in RHEL 9 we will just use standard VGA.  See:
https://bugzilla.redhat.com/show_bug.cgi?id=1961107#c1

Video type of windows guest has been qxl after converting to OSP16.2 by v2v on rhel8.5

Package versions:
virt-v2v-1.42.0-14.module+el8.5.0+11846+77888a74.x86_64
libguestfs-1.44.0-3.module+el8.5.0+10681+17a9b157.x86_64
libvirt-libs-7.5.0-1.module+el8.5.0+11664+59f87560.x86_64
qemu-img-6.0.0-25.module+el8.5.0+11890+8e7c3f51.x86_64
virtio-win-1.9.17-3.el8_4.noarch
nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64
kernel-4.18.0-324.el8.x86_64
python3-openstackclient-4.0.2-2.20210528091917.54bf2c0.el8ost.1.noarch
RHOS-16.2-RHEL-8-20210722.n.0


$  openstack volume show -f json esx6.7-win10-x86_64-efi-sda
{
  "attachments": [],
  "availability_zone": "nova",
  "bootable": "true",
  "consistencygroup_id": null,
  "created_at": "2021-07-29T07:05:48.000000",
  "description": "esx6.7-win10-x86_64-efi disk 1/1 converted by virt-v2v",
  "encrypted": false,
  "id": "f1b22bcf-f70a-45d4-a07f-d9d08b2fdff2",
  "migration_status": null,
  "multiattach": false,
  "name": "esx6.7-win10-x86_64-efi-sda",
  "os-vol-host-attr:host": "hostgroup@tripleo_iscsi#tripleo_iscsi",
  "os-vol-mig-status-attr:migstat": null,
  "os-vol-mig-status-attr:name_id": null,
  "os-vol-tenant-attr:tenant_id": "de72e7e0138b40c2861bd5d677387503",
  "properties": {
    "virt_v2v_version": "1.42.0rhel=8,release=14.module+el8.5.0+11846+77888a74",
    "virt_v2v_conversion_date": "2021/07/29 07:05:00",
    "virt_v2v_guest_name": "esx6.7-win10-x86_64-efi",
    "virt_v2v_disk_index": "1/1",
    "virt_v2v_vm_generation_id": "c6e0f21f-8d61-afcb-7082-a407d3a935c7",
    "virt_v2v_guest_id": "12345678-1234-1234-1234-123456789123"
  },
  "replication_status": null,
  "size": 15,
  "snapshot_id": null,
  "source_volid": null,
  "status": "available",
  "type": "tripleo",
  "updated_at": "2021-07-29T07:19:27.000000",
  "user_id": "2c707988bc58474daeecd27095fb51c8",
  "volume_image_metadata": {
    "architecture": "x86_64",
    "hypervisor_type": "kvm",
    "vm_mode": "hvm",
    "hw_disk_bus": "virtio",
    "hw_vif_model": "virtio",
    "hw_video_model": "qxl",
    "hw_machine_type": "pc",
    "os_type": "windows",
    "os_distro": "windows",
    "hw_cpu_sockets": "1",
    "hw_cpu_cores": "2",
    "hw_cpu_threads": "1",
    "os_version": "10",
    "hw_rng_model": "virtio",
    "hw_firmware_type": "uefi"
  }
}

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Unfortunately this bug was closed in error by an idiotic process
that we have no control over.  Reopening.

*** This bug has been marked as a duplicate of bug 1961107 ***