Bug 1817416

Summary: RFE: Should change default video type from cirrus to qxl for windows guest if target outputs are libvirt and openstack
Product: Red Hat Enterprise Linux 9 Reporter: mxie <mxie>
Component: virt-v2vAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: juzhou, lersek, mzhan, ptoscano, rjones, tyan, tzheng, virt-maint, xiaodwan
Target Milestone: betaKeywords: FutureFeature, Reopened, Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Unspecified   
Whiteboard: V2V
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-04 10:03:20 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
cirrus-windows-libvirt.png
none
osp16-windows-guest.png none

Description mxie@redhat.com 2020-03-26 10:18:37 UTC
Created attachment 1673753 [details]
cirrus-windows-libvirt.png

Description of problem:
Should change default video type from cirrus to qxl for windows guest if target output is libvirt

Version-Release number of selected component:
virt-v2v-1.40.2-22.module+el8.2.0+6029+618ef2ec.x86_64
libguestfs-1.40.2-22.module+el8.2.0+6029+618ef2ec.x86_64
libvirt-6.0.0-14.module+el8.2.0+6069+78a1cb09.x86_64
qemu-kvm-4.2.0-16.module+el8.2.0+6092+4f2391c1.x86_64
nbdkit-1.16.2-2.module+el8.2.0+5664+dd92f997.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Convert a windows guest from VMware to libvirt by virt-v2v
# virt-v2v  -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -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  esx6.7-win2019-x86_64 -of qcow2
[   0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win2019-x86_64 -it vddk  -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA
[   1.8] Creating an overlay to protect the source from being modified
[   5.1] Opening the overlay
[  12.4] Inspecting the overlay
[  17.7] Checking for sufficient free disk space in the guest
[  17.7] Estimating space required on target for each disk
[  17.7] Converting Windows Server 2019 Standard to run on KVM
virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing.  
Firstboot scripts may conflict with PnP.
virt-v2v: warning: there is no QXL driver for this version of Windows (10.0
x86_64).  virt-v2v looks for this driver in
/usr/share/virtio-win/virtio-win.iso

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[  26.7] Mapping filesystem data to avoid copying unused and blank areas
[  27.3] Closing the overlay
[  27.6] Assigning disks to buses
[  27.6] Checking if the guest needs BIOS or UEFI to boot
[  27.6] Initializing the target -o libvirt -os default
[  27.7] Copying disk 1/1 to /var/lib/libvirt/images/esx6.7-win2019-x86_64-sda (qcow2)
    (100.00/100%)
[ 726.6] Creating output metadata
Pool default refreshed

Domain esx6.7-win2019-x86_64 defined from /tmp/v2vlibvirt6b88f0.xml

[ 726.8] Finishing off


2.Check guest has below graphic configuration in libvirtxml after finishing conversion, power on guest but found the guest has no color in desktop and resolution is abnormal, pls refer to screenshot"cirrus-windows-libvirt"
# virsh dumpxml esx6.7-win2019-x86_64
.....
  <graphics type='vnc' port='-1' autoport='yes'>
      <listen type='address'/>
    </graphics>
    <video>
      <model type='cirrus' vram='16384' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
.....

3.Power off guest to change video type from cirrus to qxl, power on guest then the desktop of guest has colour  and resolution is normal

Actual results:
Windows guest has no colour in desktop and resolution is abnormal if default video type is cirrus after v2v conversion

Expected results:
Should change default video type from cirrus to qxl for windows guest if target output is libvirt


Additional info:
1.Default video type is qxl when convert windows guest to rhv by virt-v2v and all display of windows guests works well after conversion, so changing default video type to qxl for target libvirt won't bring any problem.

2.Cirrus has been deprecated in rhel8 (bug1668139)

Comment 1 Richard W.M. Jones 2020-03-26 10:24:31 UTC
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.

Comment 2 mxie@redhat.com 2020-08-24 13:28:51 UTC
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>
......

Comment 3 mxie@redhat.com 2020-08-24 13:30:58 UTC
Created attachment 1712358 [details]
osp16-windows-guest.png

Comment 6 Richard W.M. Jones 2021-06-16 11:35:53 UTC
Starting some time in RHEL 9 we will just use standard VGA.  See:
https://bugzilla.redhat.com/show_bug.cgi?id=1961107#c1

Comment 8 mxie@redhat.com 2021-07-29 07:24:17 UTC
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"
  }
}

Comment 10 RHEL Program Management 2021-09-26 07:26:49 UTC
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.

Comment 11 Richard W.M. Jones 2021-09-26 15:47:22 UTC
Unfortunately this bug was closed in error by an idiotic process
that we have no control over.  Reopening.

Comment 12 Laszlo Ersek 2022-05-04 10:03:20 UTC

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