Bug 1152369

Created attachment 946643 [details]
virt-v2v  debug info

This is likely to be a regression, but there's no realistic chance
that we can fix it before RHEL 7.1, so I'm deferring it to 7.2.

*** This bug has been marked as a duplicate of bug 1184690 ***

I can also reproduce this issue with new build:
libguestfs-1.28.1-1.44.el7.x86_64
virt-v2v-1.28.1-1.44.el7.x86_64
libvirt-1.2.17-1.el7.x86_64

Steps:
# virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export --network rhevm  rhel6u7rc1.2-OVMF -on rhel6u7rc1.2-OVMF-juzhoutest
[   0.0] Opening the source -i libvirt rhel6u7rc1.2-OVMF
[   0.0] Creating an overlay to protect the source from being modified
[   0.0] Opening the overlay
[  95.0] Initializing the target -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export
virt-v2v: warning: cannot write files to the NFS server as 36:36, even 
though we appear to be running as root. This probably means the NFS client 
or idmapd is not configured properly.

You will have to chown the files that virt-v2v creates after the run, 
otherwise RHEV-M will not be able to import the VM.
[  96.0] Inspecting the overlay
[ 108.0] Checking for sufficient free disk space in the guest
[ 108.0] Estimating space required on target for each disk
[ 108.0] Converting Red Hat Enterprise Linux Server release 6.7 (Santiago) to run on KVM
virt-v2v: error: no grub1/grub-legacy or grub2 configuration file was found

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

But i can get expected error message with build version:

libguestfs-1.28.1-1.43.el7.x86_64
virt-v2v-1.28.1-1.43.el7.x86_64

# virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export --network rhevm  rhel6u7rc1.2-OVMF -on rhel6u7rc1.2-OVMF-juzhoutest
[   0.0] Opening the source -i libvirt rhel6u7rc1.2-OVMF
[   0.0] Creating an overlay to protect the source from being modified
[   0.0] Opening the overlay
[  95.0] Initializing the target -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export
virt-v2v: warning: cannot write files to the NFS server as 36:36, even 
though we appear to be running as root. This probably means the NFS client 
or idmapd is not configured properly.

You will have to chown the files that virt-v2v creates after the run, 
otherwise RHEV-M will not be able to import the VM.
[  95.0] Inspecting the overlay
virt-v2v: error: this guest cannot run on the target, because the target 
does not support uefi firmware (supported firmware on target: bios)

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

So rjones, shall we reopen this bug now to track this issue, thanks.

The patch added to -1.44.el7 moved this test:

  virt-v2v: error: this guest cannot run on the target

to later on, exposing the error:

  virt-v2v: error: no grub1/grub-legacy or grub2 configuration file was found

I'm reopening this bug.  Please can you supply the full -v -x
output with -1.44.el7 (or -1.45.el7 if it gets built in time).

(In reply to Richard W.M. Jones from comment #6)

Hi rjones:

Always using following package version:

libvirt-1.2.17-1.el7.x86_64
libguestfs-1.28.1-1.44.el7.x86_64
virt-v2v-1.28.1-1.44.el7.x86_64

Steps:

# virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export --network rhevm  rhel6u7rc1.2-OVMF -on rhel6u7rc1.2-OVMF-juzhoutest -v -x |& tee >rhel6u7rc1.2-OVMF.deubg

I will attach debug log.

Created attachment 1049194 [details]
rhel6u7rc1.2-OVMF.deubg

Insufficient information to proceed on this bug, so moving
to RHEL 7.4.

*** Bug 1368008 has been marked as a duplicate of this bug. ***

Created attachment 1191816 [details]
virt-v2v-conversion-log.txt from a failed RHEL 6.8 UEFI conversion

zhoujunqin, mxie:

can you please attach the output of `ls -lR /boot`, executed on the guests that cannot be currently converted with v2v?

Thanks in advance.

Hi Pino, 

I check the output of `ls -lR /boot` on rhel6.8-UEFI host for your reference

# ls -lR /boot
/boot:
total 41216
-rw-r--r--. 1 root root   108103 Apr 13 00:55 config-2.6.32-642.el6.x86_64
drwx------. 3 root root     4096 Dec 31  1969 efi
-rw-r--r--. 1 root root   184688 Feb 12  2016 elf-memtest86+-5.01
drwxr-xr-x. 2 root root     4096 Aug 18 03:03 grub
-rw-------. 1 root root 25793466 Aug 17 08:19 initramfs-2.6.32-642.el6.x86_64.img
-rw-------. 1 root root  8812066 Aug 17 22:27 initrd-2.6.32-642.el6.x86_64kdump.img
-rw-r--r--. 1 root root   183012 Feb 12  2016 memtest86+-5.01
-rw-r--r--. 1 root root   215559 Apr 13 00:55 symvers-2.6.32-642.el6.x86_64.gz
-rw-r--r--. 1 root root  2615003 Apr 13 00:55 System.map-2.6.32-642.el6.x86_64
-rwxr-xr-x. 1 root root  4265904 Apr 13 00:55 vmlinuz-2.6.32-642.el6.x86_64

/boot/efi:
total 4
drwx------. 3 root root 4096 Aug 17 07:56 EFI

/boot/efi/EFI:
total 4
drwx------. 2 root root 4096 Aug 17 22:24 redhat

/boot/efi/EFI/redhat:
total 256
-rwx------. 1 root root    884 Aug 17 22:24 grub.conf
-rwx------. 1 root root 254279 Feb 24 07:45 grub.efi

/boot/grub:
total 8
-rw-r--r--. 1 root root   63 Aug 17 08:23 device.map
-rw-r--r--. 1 root root 1341 May  6  2010 splash.xpm.gz

Hi mxie:

can you please try a simple test?

a) in the guest, as root do:
  # ln -s /boot/efi/EFI/redhat/grub.conf /boot/grub/grub.conf

b) convert the guest with v2v

If the conversion works (v2v finished successfully, and the guest boots fine), then it's a simple one-liner.

Thanks.

Hi Pino,

After trying your method, the conversion will still be failed with below error：

libguestfs: trace: v2v: aug_match "/files/boot/grub/grub.conf/title/kernel"
guestfsd: main_loop: proc 51 (command_lines) took 0.21 seconds
guestfsd: main_loop: new request, len 0x54
guestfsd: main_loop: proc 24 (aug_match) took 0.00 seconds
libguestfs: trace: v2v: aug_match = []
libguestfs: trace: v2v: aug_get "/files/boot/grub/grub.conf/default"
guestfsd: main_loop: new request, len 0x50
guestfsd: error: no matching node
guestfsd: main_loop: proc 19 (aug_get) took 0.00 seconds
libguestfs: trace: v2v: aug_get = NULL (error)
grub kernels in this guest (first in list is default):
virt-v2v: error: no kernels were found in the grub configuration.

This probably indicates that virt-v2v was unable to parse the grub 
configuration of this guest.

Thanks for the hints, mxie.

Hopefully fixed by upstream commits
https://github.com/libguestfs/libguestfs/commit/cf5915aee3b33a7889d34901be08608deab5c179
https://github.com/libguestfs/libguestfs/commit/035533d67a922e7690e340fb95fb1981f4c966a6
which are in libguestfs >= 1.35.2.

(In reply to Pino Toscano from comment #23)
> Hi mxie:
> 
> can you please try a simple test?
> 
> a) in the guest, as root do:
>   # ln -s /boot/efi/EFI/redhat/grub.conf /boot/grub/grub.conf

FWIW, I found something similar fixed my problem for me, or at least allowed me to bypass the error and get a converted image to work with.

cp -R EFI/* efi/
ln -s ../efi/EFI/redhat/grub.conf grub.conf

I imagine I may have some UEFI hell/grub rebuild to get through but perhaps this will help.

Verify the bug with builds :

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

Verify steps:
1:Convert a guest with uefi to libvirt.
#  virt-v2v  -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 --password-file /tmp/passwd  rhel73-efi  -on test
[   0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 rhel73-efi
[   1.1] Creating an overlay to protect the source from being modified
[   1.7] Initializing the target -o libvirt -os default
[   1.7] Opening the overlay
[  25.9] Inspecting the overlay
[ 179.1] Checking for sufficient free disk space in the guest
[ 179.1] Estimating space required on target for each disk
[ 179.1] Converting Red Hat Enterprise Linux Server 7.2 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 910.9] Mapping filesystem data to avoid copying unused and blank areas
virt-v2v: warning: fstrim on guest filesystem /dev/sda1 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
[ 936.9] Closing the overlay
[ 937.1] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 937.1] Assigning disks to buses
[ 937.1] Copying disk 1/1 to /var/lib/libvirt/images/test-sda (raw)
    (100.00/100%)
[1059.7] Creating output metadata
Pool default refreshed

Domain test defined from /tmp/v2vlibvirtd10f87.xml

[1059.8] Finishing off


HI,ptoscano.As above command we can see there is no error about "virt-v2v: error: no grub1/grub-legacy or grub2 configuration file was found
" ,but when convert windwos guest to libvirt has a problem.And i has file a new bug: Bug 1431579 - Can't boot os normally after converting windows uefi guest from vmware to kvm by virt-v2.

(In reply to kuwei from comment #28)
> HI,ptoscano.As above command we can see there is no error about "virt-v2v:
> error: no grub1/grub-legacy or grub2 configuration file was found
> " ,but when convert windwos guest to libvirt has a problem.And i has file a
> new bug: Bug 1431579 - Can't boot os normally after converting windows uefi
> guest from vmware to kvm by virt-v2.

So RHEL guests work fine, but Windows guests not (bug 1431579)?
This bug was about RHEL guests, so I'd consider this done if the conversion of RHEL UEFI guests works.

Not a customer bug, failed QA, hellishly tricky to fix, so
moving to RHEL 7.5.

Hi rjones,

    For this bug, the current test result: can convert rhel6+uefi guest on both rhel7 host and rhel8 host by virt-v2v successfully, but the converted guest can't boot into os after v2v conversion on rhel7 and rhel8.
    I want to confirm that if rhel6+uefi is supported on Q35? If not support, I think this bug could be closed as NOTBUG

(1)On rhel7 with below builds, the conversion could be finished without error,but guest can't boot into os after conversion
virt-v2v-1.38.2-12.el7_6.1.x86_64
libguestfs-1.38.2-12.el7_6.1.x86_64
libvirt-4.5.0-10.el7_6.2.x86_64
qemu-kvm-rhev-2.12.0-18.el7_6.1.x86_64
kernel-3.10.0-957.el7.x86_64


(2)On rhel8 with below builds, the conversion could be finished without error,but guest can't boot into os after conversion

virt-v2v-1.38.4-5.el8+2078+2754d2d2.x86_64
libguestfs-1.38.4-5.el8+2078+2754d2d2.x86_64
libvirt-4.5.0-12.el8+2115+e415383f.x86_64
qemu-kvm-2.12.0-41.el8+2104+3e32e6f8.x86_64
kernel-4.18.0-27.el8.x86_64

# virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA --password-file /tmp/passwd esx6.7-rhel6.10-x86_64-efi
[   0.2] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel6.10-x86_64-efi -it vddk  -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA
[   2.9] Creating an overlay to protect the source from being modified
[   6.7] Initializing the target -o libvirt -os default
[   6.8] Opening the overlay
[  77.7] Inspecting the overlay
[  97.9] Checking for sufficient free disk space in the guest
[  97.9] Estimating space required on target for each disk
[  97.9] Converting Red Hat Enterprise Linux Server release 6.10 (Santiago) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 190.3] Mapping filesystem data to avoid copying unused and blank areas
virt-v2v: warning: fstrim on guest filesystem /dev/sda1 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
[ 191.2] Closing the overlay
[ 192.0] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 192.0] Assigning disks to buses
[ 192.0] Copying disk 1/1 to /var/lib/libvirt/images/esx6.7-rhel6.10-x86_64-efi-sda (raw)
    (100.00/100%)
[ 376.3] Creating output metadata
Pool default refreshed

Domain esx6.7-rhel6.10-x86_64-efi defined from /tmp/v2vlibvirt1d3d58.xml

[ 378.1] Finishing off

> I want to confirm that if rhel6+uefi is supported on Q35? If not
> support, I think this bug could be closed as NOTBUG

Yes we recently found out that RHEL 6 will *not* work on Q35
chipset (don't know if this has anything to do with UEFI though).

The reason for this is because qemu's Q35 chipset does not emulate
"virtio legacy" drivers (only "virtio modern") and RHEL 6 only supports
virtio legacy.

Side comment:

(In reply to Richard W.M. Jones from comment #38)
> > I want to confirm that if rhel6+uefi is supported on Q35? If not
> > support, I think this bug could be closed as NOTBUG
> 
> Yes we recently found out that RHEL 6 will *not* work on Q35
> chipset (don't know if this has anything to do with UEFI though).

UEFI should be unrelated. RHEL6 has basic UEFI support (as long as the Secure Boot operational mode is not enabled).

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/sect-uefi-support-x86

> The reason for this is because qemu's Q35 chipset does not emulate
> "virtio legacy" drivers (only "virtio modern") and RHEL 6 only supports
> virtio legacy.

That's not entirely correct.

- The RHEL-6 guest indeed only supports legacy virtio devices (where "legacy" means the 0.9.5 version of the virtio spec).

The statement about Q35 is a bit more subtle. The virtio devices on a Q35 board are capable of offering legacy support. However, if they are plugged into PCI Express Root Ports or Downstream Ports, then they don't, by default. And, by default, that's exactly where libvirt places those devices. So the end result is the same -- the "sum" of the libvirt domain configuration (= PCIe topology) and the dependent virtio device behavior means that in practice only modern (1.0.0) virtio will be offered from the QEMU side.

> So the end result is the same -- the "sum" of the libvirt domain
> configuration (= PCIe topology) and the dependent virtio device behavior
> means that in practice only modern (1.0.0) virtio will be offered from the
> QEMU side.

Thanks for Richard and Laszlo's confirmation.

Hi,Richard, as comment37 shown, v2v conversion will not be failed during converting rhel6-efi guest on both rhel7 and rhel8 now，could we change this bug description to make the rhel6-efi conversion failed directly with correct error ?

This bug was filed 4 years ago on what is likely to be a completely
different topic.  Let's do two things:

(1) close this bug per comment 37/38.

(2) if there are other issue(s) which need to be fixed, please
file new bugs with a clear description of what needs to be done.