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.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.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