Created attachment 1970937 [details] win11-uefi-to-rhev Description of problem: Fail to install storage Driver Red Hat VirtIO SCSI, after converting win11 uefi to rhev via virt-v2v Version-Release number of selected component (if applicable): virt-v2v-2.3.4-2.el9.x86_64 libvirt-9.4.0-1.el9.x86_64 qemu-kvm-8.0.0-5.el9.x86_64 RHEV version:4.5.2.1-0.1.el8ev How reproducible: 100% Steps to Reproduce: 1.Prepare win11 uefi guest on ESXi server; 2.Convert the guest to rhev via virt-v2v; # virt-v2v -ic vpx://root.212.129/data/10.73.212.36/?no_verify=1 -o rhv-upload -of raw -os nfs_data -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /v2v-ops/rhvpasswd -oo rhv-cafile=/v2v-ops/ca22.pem -oo rhv-cluster=Default --mac 00:50:56:a0:23:70:bridge:ovirtmgmt esx8.0-win11-x86_64-efi -it vddk -io vddk-libdir=/home/vddk8.0.0 -io vddk-thumbprint=CB:9F:B1:9D:33:49:6C:60:AD:3C:A5:16:77:91:5F:CD:1B:24:B1:43 -ip /v2v-ops/esxpw [ 0.0] Setting up the source: -i libvirt -ic vpx://root.212.129/data/10.73.212.36/?no_verify=1 -it vddk esx8.0-win11-x86_64-efi [ 1.9] Opening the source [ 7.4] Inspecting the source [ 21.2] Checking for sufficient free disk space in the guest [ 21.2] Converting Windows 10 Enterprise to run on KVM virt-v2v: This guest has virtio drivers installed. [ 26.4] Mapping filesystem data to avoid copying unused and blank areas [ 27.7] Closing the overlay [ 28.0] Assigning disks to buses [ 28.0] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 28.0] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data [ 36.7] Copying disk 1/1 █ 100% [****************************************] [1535.9] Creating output metadata 3. start the guest and Check the Device Manager-> Storage controllers; No "Red Hat VirtIO SCSI controller" is installed. (Please check the attachment) Actual results: No "Red Hat VirtIO SCSI controller" is installed. Expected results: "Red Hat VirtIO SCSI controller" should be installed. Additional info: Try to convert the guest to libvirt. # virt-v2v -ic vpx://root.212.129/data/10.73.212.36/?no_verify=1 -o libvirt -of raw --mac 00:50:56:af:a9:ac:bridge:virbr0 esx8.0-win11-x86_64-efi -it vddk -io vddk-libdir=/home/vddk8.0.0 -io vddk-thumbprint=CB:9F:B1:9D:33:49:6C:60:AD:3C:A5:16:77:91:5F:CD:1B:24:B1:43 -ip /v2v-ops/esxpw [ 0.0] Setting up the source: -i libvirt -ic vpx://root.212.129/data/10.73.212.36/?no_verify=1 -it vddk esx8.0-win11-x86_64-efi [ 1.9] Opening the source [ 7.5] Inspecting the source [ 23.0] Checking for sufficient free disk space in the guest [ 23.0] Converting Windows 10 Enterprise to run on KVM virt-v2v: This guest has virtio drivers installed. [ 28.1] Mapping filesystem data to avoid copying unused and blank areas [ 29.4] Closing the overlay [ 29.6] Assigning disks to buses [ 29.6] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 29.6] Setting up the destination: -o libvirt [ 31.4] Copying disk 1/1 █ 100% [****************************************] [1482.8] Creating output metadata [1482.9] Finishing off Checking the Device Manager-> Storage controllers; "Red Hat VirtIO SCSI controller" is installed. (Please check the attachment)
virt-v2v-2.3.4-2.el9.x86_64 corresponds to: - commit 9c18f8772f7c on the rhel-9.3 branch in the upstream repo - commit 0aadbb4e02f8 in dist-git - the fix for bug 2190387 Here's my understanding, from the according source code, and from the log file of the supposedly incorrect conversion from comment 2: (1) In RHEL-9.3, at the noted build ID, we have removed the upstream command line option "--block-driver". (2) We copy all virtio drivers from libosinfo into the "/Windows/Drivers/VirtIO" directory, including "viostor" and "vioscsi" both. (3) In accordance with point (1), we perform the special processing on "viostor.sys" (and *not* on "vioscsi.sys"), namely: - we copy it from "/Windows/Drivers/VirtIO/" to "/Windows/System32/drivers/", - we associate it with PCI IDs "VEN_1AF4&DEV_1001&REV_00" (virtio-0.9.5 block device) and "VEN_1AF4&DEV_1042&REV_01" (virtio-1.0 block device) in the registry. (4) In the generated OVF near the end, we see "ovf:disk-interface='VirtIO'" (and not 'VirtIO_SCSI'). Therefore the behavior appears intended: - first, we don't need vioscsi for booting, and - even though the vioscsi driver is installed under "Windows/Drivers/VirtIO" (like all the other virtio drivers), the domain (as configured by RHV) may not have (and should not have) a virtio-scsi controller. Thus it's not surprising that the virtio-scsi device and/or driver don't appear in Device Manager -- the driver is available but no device needs it. What *is* surprising is that in the libvirt output, we do have "Red Hat VirtIO SCSI controller" listed in Device Manager. Therefore I would rephrase this bug report. The expected output is not that Device Manager show "Red Hat VirtIO SCSI controller" on RHV; that's uncalled-for. Instead, the expectation may be (at best) that Device Manager *consistently* show the *same one* SCSI controller in both outputs: Device Manager should show "Red Hat VirtIO SCSI controller" in either both the RHV and libvirt outputs, or in none of them. I suspect there could be a difference in virtual hardware. I propose that the conversion step (= the virtio-win driver injection from libosinfo) is identical in both runs, only the vioscsi driver is "put to use" in just one case: when the output is libvirt. And that could be caused by - the domain XML that virt-v2v generates directly for the libvirt output differring from - the domain XML that RHV generates from virt-v2v's OVF. I notice that in the RHV output, Device Manager displays a generic "SCSI Controller". That's certainly a bit strange. If that controller is actually a virtio-scsi controller, then the bug report seems valid as *originally reported*, because then we have identical virtual hardware, but different driver behavior. For saying more, we should review: (a) The conversion log for not just the RHV output, but also the libvirt one -- this should prove that the conversion steps (virtio-win driver injections) are identical between both runs. (b) The domain XML that virt-v2v generates for the libvirt output (which should be available at once from the previous bullet). (c) The domain XML that RHV generates for libvirt when the domain is started up (I presume this can be taken from the oVirt logs somewhere). (d) From the converted domain running on RHV, any information that Device Manager can produce about the generic "SCSI Controller" -- most relevant would be the (d.1) PCI Vendor and Device IDs, plus (d.2) any Windows driver in use (I see no yellow triangle / exclamation mark, so *some* Windows driver must have bound the controller). Either way, this does not look like a functional issue; at worst it is a cosmetic one. But we can investigate a bit, to understand the difference. Thanks.
Hi, Laszlo I tried to convert the Windows11 guest with bios setting to the same rhev server. And "Red Hat VirtIO SCSI controller" is installed after converting. Please check the attachments for details.
Sorry, I've found no relevant difference between the win11_BIOS-to-RHV and win11_UEFI-to-RHV logs. Anyway, please upload the logs I asked for at the end of comment 3. Alternatively, please give me access to a host where both conversion output domains are available / running (win11_UEFI-to-RHV, win11_UEFI-to-libvirt). I need to compare the conversion logs, the libvirt domain XMLs (including the one that RHV generates!), and poke around in Windows. Thanks.
Setting Triaged so JIRA stops sending me emails.