Description of problem: After migrating a Windows Server 2019 Datacenter guest VM, the QXL driver and related spice agent. The error specifies only QXL though. Then a generic VGA driver is used according to the log. Version-Release number of selected component (if applicable): - RHVM 4.4.3 Host - CloudForms 5.0 - virtio-win-1.9.14 - UEFI BIOS enabled - libosinfo-1.8.0-3.fc33.x86_64 How reproducible: Steps to Reproduce: 1. Run a migration plan in CloudForms UI 2. Conversion Host is recognized and the migration appears to finish. 3. The Spice doesn't work and the QXL driver isn't installed. Actual results: - The guest tools doesn't install the QXL driver automatically as part of migration. Expected results: - The QXL driver should be found and installed automatically. Additional info: - The remaining guest tools are installed correctly.
The PC\VEN hardware IDs are: PCI\VEN_1B36&DEV_0100&SUBSYS_11001AF4&REV_05 PCI\VEN_1B36&DEV_0100&SUBSYS_11001AFA PCI\VEN_1B36&DEV_0100&CC_03000 PCI\VEN_1B36&DEV_0100&CC_030 Thank you for your help.
(In reply to Bryan Kinney from comment #11) > The PC\VEN hardware IDs are: > > PCI\VEN_1B36&DEV_0100&SUBSYS_11001AF4&REV_05 > PCI\VEN_1B36&DEV_0100&SUBSYS_11001AFA > PCI\VEN_1B36&DEV_0100&CC_03000 > PCI\VEN_1B36&DEV_0100&CC_030 > > Thank you for your help. That is the qxl device. So the driver is missing. Please try to install it manually as I mentioned in comment#13 Best, Vadim.
The v2v migration import log shows that the QxlWddmDod_x64.msi was found in virtio-win package. Attachment to this case: v2v-import-20201130T110112-494647.log --- libguestfs: trace: virtio_win: find = [ ... "qxl-wddm-dod", "qxl-wddm-dod/QxlWddmDod_x64.msi", "qxl-wddm-dod/QxlWddmDod_x86.msi", "qxl/2k8R2", "qxl/2k8R2/amd64", "qxl/2k8R2/amd64/qxl.cat", "qxl/2k8R2/amd64/qxl.inf", "qxl/2k8R2/amd64/qxl.sys", "qxl/2k8R2/amd64/qxldd.dll", "qxl/w7", "qxl/w7/amd64", "qxl/w7/amd64/qxl.cat", "qxl/w7/amd64/qxl.inf", "qxl/w7/amd64/qxl.sys", "qxl/w7/amd64/qxldd.dll", "qxl/w7/x86", "qxl/w7/x86/qxl.cat", "qxl/w7/x86/qxl.inf", "qxl/w7/x86/qxl.sys", "qxl/w7/x86/qxldd.dll", "qxldod", "qxldod/w10", --- But the error is for this, 2k19, version of Windows: --- { "message": "there is no QXL driver for this version of Windows (10.0 x86_64). virt-v2v looks for this driver in /rhev/data-center/mnt/LAB-RHEV-NFS01.EXAMPLE.COM:_nfsroot_ISO/{UUID}/images/11111111-1111-1111-1111-111111111111/virtio-win-1.9.14.iso\n\nThe guest will be configured to use a basic VGA display driver.", "timestamp": "2020-11-30T11:01:52.223072722+10:00", "type": "warning" } --- The NFS01.EXAMPLE.COM and {UUID} are redactions here. This error is for a Windows Server 2019 Datacenter guest. So for just the missing versions of Windows the driver will need to be installed manually?
(In reply to Bryan Kinney from comment #15) > The v2v migration import log shows that the QxlWddmDod_x64.msi was found in > virtio-win package. > Attachment to this case: v2v-import-20201130T110112-494647.log > > --- > libguestfs: trace: virtio_win: find = [ ... > "qxl-wddm-dod", "qxl-wddm-dod/QxlWddmDod_x64.msi", > "qxl-wddm-dod/QxlWddmDod_x86.msi", "qxl/2k8R2", "qxl/2k8R2/amd64", > "qxl/2k8R2/amd64/qxl.cat", "qxl/2k8R2/amd64/qxl.inf", > "qxl/2k8R2/amd64/qxl.sys", "qxl/2k8R2/amd64/qxldd.dll", "qxl/w7", > "qxl/w7/amd64", "qxl/w7/amd64/qxl.cat", "qxl/w7/amd64/qxl.inf", > "qxl/w7/amd64/qxl.sys", "qxl/w7/amd64/qxldd.dll", "qxl/w7/x86", > "qxl/w7/x86/qxl.cat", "qxl/w7/x86/qxl.inf", "qxl/w7/x86/qxl.sys", > "qxl/w7/x86/qxldd.dll", "qxldod", "qxldod/w10", > --- > > But the error is for this, 2k19, version of Windows: > > --- > { "message": "there is no QXL driver for this version of Windows (10.0 > x86_64). virt-v2v looks for this driver in > /rhev/data-center/mnt/LAB-RHEV-NFS01.EXAMPLE.COM:_nfsroot_ISO/{UUID}/images/ > 11111111-1111-1111-1111-111111111111/virtio-win-1.9.14.iso\n\nThe guest will > be configured to use a basic VGA display driver.", "timestamp": > "2020-11-30T11:01:52.223072722+10:00", "type": "warning" } > --- > > The NFS01.EXAMPLE.COM and {UUID} are redactions here. > > This error is for a Windows Server 2019 Datacenter guest. > So for just the missing versions of Windows the driver will need to be > installed manually? there are two different kinds of qxl drivers for Windows. One of them is based on so-called XPDM architecture and designed to work on WinXP..Win7 platforms. Another, a new one, is based on WDDM technology and designed to work on Win10 and higher. Whaterver can be found under "qxl/xxxxx" path is based on XPDM and cannot be installed on Win10/WS2016/WS2019. So please try installing qxl dod (Display Only Driver) manually, and let me know how it works. Thanks, Vadim.
Installing manually does fix the driver issue for Windows newer than Windows 7. That leaves a lot of newer Windows to be done manually. I assume this now becomes a migration issue as manual installation works. We just need to know how and what to change there.
We can't really have a solution where drivers must be installed manually, virt-v2v must install them automatically somehow. For other drivers this happens because we copy them to C:\Windows\Drivers\VirtIO and set that directory in the Windows Registry DevicePath entry, and Windows installs the drivers it needs from there at boot. I know nothing about .msi files, but why is the QXL driver available only as an .msi for this version of Windows? Note it works fine on other versions of Windows where it's a regular .sys file. Also if we did copy the .msi file to C:\Windows\Drivers\VirtIO is Windows going to be able to find the .msi file and install it automatically at boot without any manual intervention?
A new virtio-win RPM that includes qxldod drivers is available at https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1494889
Test the bug with below builds: virt-v2v-1.42.0-9.module+el8.4.0+9561+069bb9c1.x86_64 libguestfs-1.44.0-1.module+el8.4.0+9398+f376ac33.x86_64 libvirt-libs-7.0.0-3.module+el8.4.0+9709+a99efd61.x86_64 qemu-kvm-5.2.0-5.module+el8.4.0+9775+0937c167.x86_64 package ndbkit is not installed virtio-win-1.9.16-0.el8.noarch Steps: 1.Check qxl drivers in virtio-win folder # ls /usr/share/virtio-win/drivers/by-driver/qxldod/ 2k16 2k19 w10 # ls /usr/share/virtio-win/drivers/by-driver/qxl 2k8R2 w7 2.Convert a win2016 guest from VMware to rhv4.4 by virt-v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -ip /home/passwd -op /home/rhvpasswd -os nfs_data -n ovirtmgmt esx7.0-win2016-x86_64-vmware-tool -oo rhv-direct=true [ 0.7] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2016-x86_64-vmware-tool -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 2.5] Creating an overlay to protect the source from being modified [ 5.6] Opening the overlay [ 28.3] Inspecting the overlay [ 35.8] Checking for sufficient free disk space in the guest [ 35.8] Estimating space required on target for each disk [ 35.8] Converting Windows Server 2016 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. [ 53.7] Mapping filesystem data to avoid copying unused and blank areas [ 54.4] Closing the overlay [ 54.6] Assigning disks to buses [ 54.6] Checking if the guest needs BIOS or UEFI to boot [ 54.6] Initializing the target -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data [ 56.1] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.LFqplq/nbdkit4.sock", "file.export": "/" } (qcow2) (100.00/100%) [ 817.2] Creating output metadata [ 819.3] Finishing off 3.Check win2016 guest after v2v conversion, qxl driver can installed for display device successfully 4. Convert a win2019 guest from VMware to rhv4.4 by virt-v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -ip /home/passwd -op /home/rhvpasswd -os nfs_data -n ovirtmgmt esx7.0-win2019-x86_64 -oo rhv-direct=true [ 0.5] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 2.2] Creating an overlay to protect the source from being modified [ 5.4] Opening the overlay [ 12.1] Inspecting the overlay [ 15.7] Checking for sufficient free disk space in the guest [ 15.7] Estimating space required on target for each disk [ 15.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. [ 24.5] Mapping filesystem data to avoid copying unused and blank areas [ 24.9] Closing the overlay [ 25.2] Assigning disks to buses [ 25.2] Checking if the guest needs BIOS or UEFI to boot [ 25.2] Initializing the target -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data [ 56.1] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.LFwplq/nbdkit4.sock", "file.export": "/" } (qcow2) (100.00/100%) [ 818.2] Creating output metadata [ 820.4] Finishing off 5.Check win2019 guest after v2v conversion, qxl driver can installed for display device successfully 6. Convert a win10 x86 guest from VMware to rhv4.4 by virt-v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -ip /home/passwd -op /home/rhvpasswd -os nfs_data -n ovirtmgmt esx7.0-win10-i386 [ 0.5] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win10-i386 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 2.1] Creating an overlay to protect the source from being modified [ 5.2] Opening the overlay [ 11.8] Inspecting the overlay [ 16.7] Checking for sufficient free disk space in the guest [ 16.7] Estimating space required on target for each disk [ 16.7] Converting Windows 10 Enterprise 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 i386). 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. [ 24.2] Mapping filesystem data to avoid copying unused and blank areas [ 25.0] Closing the overlay [ 25.0] Assigning disks to buses [ 25.0] Checking if the guest needs BIOS or UEFI to boot [ 25.0] Initializing the target -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data [ 26.3] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.XoMMCb/nbdkit4.sock", "file.export": "/" } (qcow2) (100.00/100%) [ 780.9] Creating output metadata [ 782.7] Finishing off 7.Check win10 x86 guest after v2v conversion, qxl driver can installed for display device successfully 8. Convert a win10 x64 guest from VMware to rhv4.4 by virt-v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -ip /home/passwd -op /home/rhvpasswd -os nfs_data -n ovirtmgmt esx7.0-win10-x86_64 [ 0.5] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win10-x86_64 -it vddk -io vddk-libdir=/home/vddk6.5 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 2.1] Creating an overlay to protect the source from being modified [ 5.3] Opening the overlay [ 12.3] Inspecting the overlay [ 18.4] Checking for sufficient free disk space in the guest [ 18.4] Estimating space required on target for each disk [ 18.4] Converting Windows 10 Enterprise 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. [ 29.1] Mapping filesystem data to avoid copying unused and blank areas [ 29.6] Closing the overlay [ 29.9] Assigning disks to buses [ 29.9] Checking if the guest needs BIOS or UEFI to boot [ 29.9] Initializing the target -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data [ 31.2] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.VKda1g/nbdkit4.sock", "file.export": "/" } (qcow2) (100.00/100%) [ 995.0] Creating output metadata [ 996.9] Finishing off 9.Check win10 x64 guest after v2v conversion, found qxl driver isn't installed for display device successfully, pls refer to screenshot"win10-x64-qxl-not-install.png" 10.Check qxl driver is C:\Windows\Drivers\Virtio, found qxl drivers aren't copied to the folder, pls refer to screenshot"no-qxl-in-win10-x64-driver-folder.png" Hi Richard, Please help to check step8~step10, v2v can't install qxl driver for win10-x64 guest because qxl drivers aren't copied to win10x64 during conversion , thanks
Created attachment 1755676 [details] no-qxl-in-win10-x64-driver-folder.png
Created attachment 1755677 [details] win10-x64-qxl-not-install.png
Created attachment 1755691 [details] virt-v2v-win10-x64-qxl.log
I think this is a libosinfo thing. mxie is using libosinfo-1.8.0-1.el8.x86_64
Do you know what version of osinfo-db is installed? I suspect it lacks this commit: commit 43913618247a70ed7727dcf24e5b560507ccaf20 Author: Fabiano Fidêncio <fidencio> Date: Tue Sep 24 18:43:06 2019 +0200 win-10: pre-install all the possible virtio-win drivers Signed-off-by: Fabiano Fidêncio <fidencio> Reviewed-by: Cole Robinson <crobinso>
(In reply to Richard W.M. Jones from comment #53) > Do you know what version of osinfo-db is installed? I suspect it lacks this > commit: Current the installed version of osinfo-db is 20200813-1.el8.noarch, the version is a bit old indeed. Update osinfo-db to 20210202-1.el8.noarch, then convert win10 x64 guest from VMware again, but qxl drivers are still not copied to win10 x64 guest during conversion, so qxl driver can't be installed for display device
I'm going to have to investigate this further. I thought that /usr/share/osinfo/os/microsoft.com/win-10.d/pre-installable-drivers.xml containing qxldod entries would mean that the driver would get installed automatically by v2v.
OK I found out what the problem is, but I don't really understand it. libosinfo returns the following data to us about win-10: https://fedorapeople.org/groups/virt/unattended/drivers/postinst/spice-guest-tools/0.141: [x86_64, not pre-installable, unsigned, priority 50] virtio-0.141.cer qxl-0.141.cer spice-guest-tools-0.141.cmd spice-guest-tools-0.141.exe https://fedorapeople.org/groups/virt/unattended/drivers/preinst/virtio-win/0.1.171/w10/amd64: [x86_64, pre-installable, unsigned, priority 50] viostor.sys viostor.inf viostor.cat vioser.sys vioser.inf vioser.cat vioscsi.sys vioscsi.inf vioscsi.cat viorngum.dll viorngci.dll viorng.sys viorng.inf viorng.cat vioinput.sys vioinput.inf vioinput.cat viohidkmdf.sys qxldod.sys qxldod.inf qxldod.cat qemupciserial.inf qemupciserial.cat qemufwcfg.inf qemufwcfg.cat pvpanic.sys pvpanic.inf pvpanic.cat netkvmco.dll netkvm.sys netkvm.inf netkvm.cat balloon.sys balloon.inf balloon.cat file:///usr/share/virtio-win/drivers/by-os/amd64/w10/: [x86_64, pre-installable, signed, priority 50] viofs.sys viofs.inf viofs.cat viostor.sys viostor.inf viostor.cat vioser.sys vioser.inf vioser.cat vioscsi.sys vioscsi.inf vioscsi.cat viorngum.dll viorngci.dll viorng.sys viorng.inf viorng.cat vioinput.sys vioinput.inf vioinput.cat viohidkmdf.sys qemupciserial.inf qemupciserial.cat qemufwcfg.inf qemufwcfg.cat pvpanic.sys pvpanic.inf pvpanic.cat netkvmco.dll netkvm.sys netkvm.inf netkvm.cat balloon.sys balloon.inf balloon.cat For reasons which are unclear qxldod.* is not included in the file:/// list. Virt-v2v filters out the https:// URLs here: https://github.com/libguestfs/virt-v2v/blob/4c435a6e90600842d2a57d4f2c7f0834cd872dfe/v2v/windows_virtio.ml#L488 Because the file:/// list does not contain qxldod.*, it is not copied into the guest. I will ask libosinfo developers about this.
(In reply to Richard W.M. Jones from comment #56) > OK I found out what the problem is, but I don't really understand it. > > libosinfo returns the following data to us about win-10: > > > https://fedorapeople.org/groups/virt/unattended/drivers/postinst/spice-guest- > tools/0.141: [x86_64, not pre-installable, unsigned, priority 50] > virtio-0.141.cer qxl-0.141.cer spice-guest-tools-0.141.cmd > spice-guest-tools-0.141.exe > > https://fedorapeople.org/groups/virt/unattended/drivers/preinst/virtio-win/0. > 1.171/w10/amd64: [x86_64, pre-installable, unsigned, priority 50] > viostor.sys viostor.inf viostor.cat vioser.sys vioser.inf vioser.cat > vioscsi.sys vioscsi.inf vioscsi.cat viorngum.dll viorngci.dll viorng.sys > viorng.inf viorng.cat vioinput.sys vioinput.inf vioinput.cat viohidkmdf.sys > qxldod.sys qxldod.inf qxldod.cat qemupciserial.inf qemupciserial.cat > qemufwcfg.inf qemufwcfg.cat pvpanic.sys pvpanic.inf pvpanic.cat netkvmco.dll > netkvm.sys netkvm.inf netkvm.cat balloon.sys balloon.inf balloon.cat > file:///usr/share/virtio-win/drivers/by-os/amd64/w10/: [x86_64, > pre-installable, signed, priority 50] viofs.sys viofs.inf viofs.cat > viostor.sys viostor.inf viostor.cat vioser.sys vioser.inf vioser.cat > vioscsi.sys vioscsi.inf vioscsi.cat viorngum.dll viorngci.dll viorng.sys > viorng.inf viorng.cat vioinput.sys vioinput.inf vioinput.cat viohidkmdf.sys > qemupciserial.inf qemupciserial.cat qemufwcfg.inf qemufwcfg.cat pvpanic.sys > pvpanic.inf pvpanic.cat netkvmco.dll netkvm.sys netkvm.inf netkvm.cat > balloon.sys balloon.inf balloon.cat Rich, those are not used downstream. Please, take a look at the following commit from osinfo-db downstream repo for rhel-8.3: 1b03d21054a786e947fc3e91eca9ab4e961aff86, which is present in the version used (osinfo-db-20200813-1.el8). Author: Fabiano Fidêncio <fidencio> AuthorDate: Tue Dec 10 09:50:00 2019 +0100 Commit: Fabiano Fidêncio <fidencio> CommitDate: Tue Dec 10 10:59:27 2019 +0100 Remove upstream virtio-win / spice-guest-tools Related: rhbz#1780529 - Update to the latest upstream release Signed-off-by: Fabiano Fidêncio <fidencio> > > For reasons which are unclear qxldod.* is not included in the file:/// list. > Virt-v2v filters out the https:// URLs here: > > https://github.com/libguestfs/virt-v2v/blob/ > 4c435a6e90600842d2a57d4f2c7f0834cd872dfe/v2v/windows_virtio.ml#L488 Instead of using the upstream drivers, libosinfo uses whatever is provided by virtio-win, once virtio-win is installed. So, looking at: Refs: [rhel-8.4.0], {origin/rhel-8.4.0}, virtio-win-1.7.4-1.el7-55-gd7f5743 Author: Vadim Rozenfeld <vrozenfe> AuthorDate: Mon Feb 8 12:49:20 2021 +1100 Commit: Vadim Rozenfeld <vrozenfe> CommitDate: Mon Feb 8 12:49:55 2021 +1100 add qxldod to virtio-win iso - Resolves: rhbz#1902635 I don't see an update done in any of the virtio-win-pre-installable-drivers-win-{7,8,8.2,10}.xml. As those were not added there, there's absolutely no way for libosinfo to return them to the apps querying for those drivers. So, what should be done? Update the XMLs accordingly to include the files added by that commit. Rich, does this answer your question?
OK I see, it's in fact a bug in the updated virtio-win. The following XML file also needs to be changed to list the new files: /usr/share/osinfo/os/microsoft.com/win-10.d/virtio-win-pre-installable-drivers-win-10.xml
Please check with virtio-win-1.9.16-1.el8 (available from https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1496986 ) I added the following section <file>qxldod.cat</file> <file>qxldod.inf</file> <file>qxldod.sys</file> <device id="http://pcisig.com/pci/1B36/0100"/> to virtio-win-pre-installable-drivers-win-10.xml Vadim.
(In reply to Vadim Rozenfeld from comment #59) > Please check with virtio-win-1.9.16-1.el8 > (available from > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1496986 ) > > I added the following section > <file>qxldod.cat</file> > <file>qxldod.inf</file> > <file>qxldod.sys</file> > <device id="http://pcisig.com/pci/1B36/0100"/> > > to virtio-win-pre-installable-drivers-win-10.xml Yup, works for me with upstream virt-v2v now.
Test bug with below builds: virtio-win-1.9.16-1.el8.noarch virt-v2v-1.42.0-9.module+el8.4.0+9561+069bb9c1.x86_64 libguestfs-1.44.0-1.module+el8.4.0+9398+f376ac33.x86_64 libvirt-libs-7.0.0-3.module+el8.4.0+9709+a99efd61.x86_64 qemu-kvm-5.2.0-5.module+el8.4.0+9775+0937c167.x86_64 nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64 Result: qxl driver can be successfully installed in win10x64, win10x86, win2016 and win2019 after v2v converting to rhv4.4
Set status to verified according to comment#60 and comment#61. Thanks all.
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 (virtio-win bug fix and enhancement 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/RHEA-2021:1959
For now it'd be good to keep it there. I've not actually changed virt-v2v yet so removing it would break virt-v2v.