Bug 1431579 - Windows 8 UEFI from VMware to KVM fails to boot after conversion
Summary: Windows 8 UEFI from VMware to KVM fails to boot after conversion
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
Yehuda Zimmerman
URL:
Whiteboard: V2V
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-13 10:52 UTC by kuwei@redhat.com
Modified: 2020-09-10 10:19 UTC (History)
11 users (show)

Fixed In Version: libguestfs-1.36.3-3.el7
Doc Type: Bug Fix
Doc Text:
Converted Windows UEFI guests boot properly Previously, when converting Windows 8 UEFI guests, _virtio_ drivers were not installed correctly. Consequently, the converted guests did not boot. With this update, _virtio_ drivers are installed correctly in Windows UEFI guests. As a result, converted Windows UEFI guests boot properly.
Clone Of:
Environment:
Last Closed: 2017-08-01 22:13:55 UTC
Target Upstream Version:


Attachments (Terms of Use)
win8-boot (177.87 KB, image/png)
2017-03-13 10:52 UTC, kuwei@redhat.com
no flags Details
v2v.log (228.89 KB, text/plain)
2017-03-13 10:53 UTC, kuwei@redhat.com
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2023 normal SHIPPED_LIVE libguestfs bug fix and enhancement update 2017-08-01 19:32:01 UTC

Description kuwei@redhat.com 2017-03-13 10:52:07 UTC
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.

Comment 2 kuwei@redhat.com 2017-03-13 10:53:49 UTC
Created attachment 1262387 [details]
v2v.log

Comment 3 Richard W.M. Jones 2017-04-12 10:48:30 UTC
I see no obvious reason why it would fail, but I'll have to
test things locally.

Comment 4 Laszlo Ersek 2017-04-12 11:23:30 UTC
(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.

Comment 5 Ladi Prosek 2017-04-12 13:20:24 UTC
(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.

Comment 6 Richard W.M. Jones 2017-04-12 15:25:16 UTC
(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 ...

Comment 7 Richard W.M. Jones 2017-04-12 16:09:39 UTC
(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.

Comment 8 Richard W.M. Jones 2017-04-13 12:21:09 UTC
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.

Comment 9 Richard W.M. Jones 2017-04-13 12:26:39 UTC
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.

Comment 10 Richard W.M. Jones 2017-04-13 12:30:01 UTC
Upstream commit is d8e1c4bb474203d71903261fb06fe267c3cce3c7

Comment 11 Laszlo Ersek 2017-04-13 13:40:27 UTC
Awesome!

Ladi, thank you very much for the incredible insight in comment 5.

Comment 12 Richard W.M. Jones 2017-04-13 13:49:48 UTC
Indeed, I don't think we'd have solved this without Ladi's comment.

Comment 14 kuwei@redhat.com 2017-04-19 06:12:35 UTC
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

Comment 27 errata-xmlrpc 2017-08-01 22:13:55 UTC
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


Note You need to log in before you can comment on or make changes to this bug.