Red Hat Bugzilla – Bug 1431579
Windows 8 UEFI from VMware to KVM fails to boot after conversion
Last modified: 2017-08-02 04:13:50 EDT
Created attachment 1262386 [details] win8-boot Description: Can't boot os normally after converting windows uefi guest from vmware to kvm by virt-v2v Version-Release number of selected component (if applicable): OVMF-20170228-1.gitc325e41585e3.el7.noarch virt-v2v-1.36.2-1.el7.x86_64 libguestfs-1.36.2-1.el7.x86_64 libvirt-3.1.0-2.el7.x86_64 qemu-kvm-rhev-2.8.0-6.el7.x86_64 Reproduce steps: 1:Convert windows8.1 with uefi from vmware to kvm # virt-v2v -ic vpx://root@10.73.75.182/data/10.73.3.19/?no_verify=1 win8-uefi --password-file /tmp/passwd -of qcow2 [ 0.0] Opening the source -i libvirt -ic vpx://root@10.73.75.182/data/10.73.3.19/?no_verify=1 win8-uefi [ 1.2] Creating an overlay to protect the source from being modified [ 1.8] Initializing the target -o libvirt -os default [ 1.8] Opening the overlay [ 10.5] Inspecting the overlay [ 84.5] Checking for sufficient free disk space in the guest [ 84.5] Estimating space required on target for each disk [ 84.5] Converting Windows 8.1 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 (6.3 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 96.2] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/sda2 failed. Usually you can ignore this message. To find out more read "Trimming" in virt-v2v(1). Original message: fstrim: fstrim: /sysroot/: the discard operation is not supported [ 96.9] Closing the overlay [ 96.9] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 96.9] Assigning disks to buses [ 96.9] Copying disk 1/1 to /var/lib/libvirt/images/win8-uefi-sda (qcow2) (100.00/100%) [ 397.0] Creating output metadata Pool default refreshed Domain win8-uefi defined from /tmp/v2vlibvirte5646b.xml [ 397.2] Finishing off 2:After conversion successfully,boot the guest we can see there is no error info but we can see the display unnormally by virt-manager or virt-viewer as the attachment picture. # virsh start win8-uefi Domain win8-uefi started Actual results: as above Expected results: The guest with uefi should be boot and display normally . Addition info: 1:When convert windows2012r2 guest with uefi ,it can't boot with the same error with win8.1. 2：When convert rhel7.3 with uefi,it boot normally.
Created attachment 1262387 [details] v2v.log
I see no obvious reason why it would fail, but I'll have to test things locally.
(CC Ladi) From the BSOD capture: Bug Check 0x7B: INACCESSIBLE_BOOT_DEVICE https://msdn.microsoft.com/en-us/library/windows/hardware/ff559218(v=vs.85).aspx [...] changing the BIOS configuration [...] might induce this error The MSDN article suggests that WinDbg can be used -- in our case: connected from another Windows VM -- to figure out the cause that underlies INACCESSIBLE_BOOT_DEVICE.
(In reply to Laszlo Ersek from comment #4) > (CC Ladi) > > From the BSOD capture: > > Bug Check 0x7B: INACCESSIBLE_BOOT_DEVICE > https://msdn.microsoft.com/en-us/library/windows/hardware/ff559218(v=vs.85). > aspx > > [...] changing the BIOS configuration [...] might induce this error > > The MSDN article suggests that WinDbg can be used -- in our case: connected > from another Windows VM -- to figure out the cause that underlies > INACCESSIBLE_BOOT_DEVICE. BSOD 0x7B is typically caused by a missing or broken storage driver. Given that this is Q35, is it possible that the virtio-block device is configured as modern-only? From the log it looks like we only install the driver for VEN_1AF4&DEV_1001 and not for the modern VEN_1AF4&DEV_1042.
(In reply to Ladi Prosek from comment #5) > Given that this is Q35, is it possible that the virtio-block device is > configured as modern-only? From the log it looks like we only install the > driver for VEN_1AF4&DEV_1001 and not for the modern VEN_1AF4&DEV_1042. Yes, this does seem possible. At least it's easy for me to change that and test it anyhow ...
(In reply to Richard W.M. Jones from comment #6) > (In reply to Ladi Prosek from comment #5) > > Given that this is Q35, is it possible that the virtio-block device is > > configured as modern-only? From the log it looks like we only install the > > driver for VEN_1AF4&DEV_1001 and not for the modern VEN_1AF4&DEV_1042. > > Yes, this does seem possible. At least it's easy for me to change > that and test it anyhow ... I had a chat with libvirt developers and it seems as if machine=q35 does imply virtio-1.0 only. If we wanted to enable legacy virtio we'd need to use the disable-legacy=off flag, but libvirt provides no way to get that. In any case this does appear to be a bug in virt-v2v as described by comment 5.
I was able to reproduce this (or at least an 0x7B) error by: (1) Install Win8 UEFI guest. I'm using local libvirt for this, for convenience. Shut it down after installation. (2) Modify the libvirt XML to change the loader from OVMF_CODE.fd to OVMF_CODE.secboot.fd. This will ensure that virt-v2v chooses machine='q35' during conversion. (3) Modify the libvirt XML to remove any IDE CD-ROMs (because of bug 1442036). (4) Perform virt-v2v conversion using: virt-v2v -i libvirt test1 -o local -os /var/tmp -on test2 Check that virtio drivers are installed during the conversion. (5) Define and boot the guest: virsh define /var/tmp/test2.xml virsh start test2 The boot should fail with a 0x7B error.
And I was able to verify that the fix I proposed here: https://www.redhat.com/archives/libguestfs/2017-April/msg00135.html does fix the 0x7B error in the previous comment. Therefore moving to POST state.
Upstream commit is d8e1c4bb474203d71903261fb06fe267c3cce3c7
Awesome! Ladi, thank you very much for the incredible insight in comment 5.
Indeed, I don't think we'd have solved this without Ladi's comment.
Verify the bug with below builds: virt-v2v-1.36.3-3.el7.x86_64 libvirt-3.2.0-2.el7.x86_64 OVMF-20170228-3.gitc325e41585e3.el7.noarch qemu-kvm-rhev-2.8.0-6.el7.x86_64 Verify steps: 1:Convert a windows8.1 guest with uefi from vmware to kvm # virt-v2v -ic vpx://root@10.73.75.182/data/10.73.3.19/?no_verify=1 win8-uefi --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root@10.73.75.182/data/10.73.3.19/?no_verify=1 win8-uefi [ 1.6] Creating an overlay to protect the source from being modified [ 2.3] Initializing the target -o libvirt -os default [ 2.4] Opening the overlay [ 28.2] Inspecting the overlay [ 310.7] Checking for sufficient free disk space in the guest [ 310.7] Estimating space required on target for each disk [ 310.7] Converting Windows 8.1 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 (6.3 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 348.0] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/sda2 failed. Usually you can ignore this message. To find out more read "Trimming" in virt-v2v(1). Original message: fstrim: fstrim: /sysroot/: the discard operation is not supported [ 373.3] Closing the overlay [ 374.0] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 374.0] Assigning disks to buses [ 374.0] Copying disk 1/1 to /var/lib/libvirt/images/win8-uefi-sda (raw) (100.00/100%) [ 693.8] Creating output metadata Pool default refreshed Domain win8-uefi defined from /tmp/v2vlibvirtcd4ae1.xml [ 694.3] Finishing off 2:Conversion was successful and all checkpoints all passed. Additions:Convert windwos2012r2 with uefi and windows7 guest with uefi from vmware to kvm all successful. So, move the bug to VERIFIED
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, 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/RHBA-2017:2023