Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1509931 - [RFE] v2v: UEFI support in RHV export
Summary: [RFE] v2v: UEFI support in RHV export
Keywords:
Status: ON_QA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard: V2V
Depends On: 1327846 1532969 1613496 1621895
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-06 11:23 UTC by Pino Toscano
Modified: 2019-03-29 06:52 UTC (History)
13 users (show)

Fixed In Version: libguestfs-1.40.1-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
Screenshot for boot up failure (deleted)
2019-03-27 12:54 UTC, zhoujunqin
no flags Details
import log (deleted)
2019-03-27 12:59 UTC, zhoujunqin
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1112275 None None None 2019-04-11 02:32:26 UTC

Description Pino Toscano 2017-11-06 11:23:54 UTC
virt-v2v should support exporting UEFI guests to RHV.

Enabling it in v2v is a simple patch:

diff --git a/v2v/output_rhv.ml b/v2v/output_rhv.ml
index ce2d75c1d..bbb15e36b 100644
--- a/v2v/output_rhv.ml
+++ b/v2v/output_rhv.ml
@@ -115,7 +115,7 @@ object
 
   method as_options = sprintf "-o rhv -os %s" os
 
-  method supported_firmware = [ TargetBIOS ]
+  method supported_firmware = [ TargetBIOS; TargetUEFI ]
 
   (* RHV doesn't support serial consoles.  This causes the conversion
    * step to remove it.

OTOH we need to check:
a) what is the status of RHV wrt UEFI guests
b) whether additional/different metadata is needed in the OVF that v2v creates for RHV (most probably yes)

Comment 10 Michal Skrivanek 2018-12-12 10:49:25 UTC
in 4.3 OVF there's now BiosType parameter taking enum values from https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/BiosType.java#L10

<BiosType>0</BiosType> in VirtualSystem section

Comment 11 Pino Toscano 2018-12-13 15:35:55 UTC
There were two recent commits dealing with this:
a878b3011ba80dc2ddaf44bf575f490847c66540
d76acb13ae1d4ee5a86ca233bd89eeaebccf7771
which are both in libguestfs >= 1.39.12.

Comment 12 Pino Toscano 2019-01-17 18:27:47 UTC
Hopefully all the pieces for this should be in place in libguestfs 1.40.
Hence, mark this bug as fixed by the rebase scheduled for RHEL 7.7, see bug 1621895.

Comment 14 zhoujunqin 2019-03-25 10:04:04 UTC
Testing this bug with build:
libvirt-4.5.0-10.el7.x86_64
libguestfs-1.40.2-1.el7.x86_64
virt-v2v-1.40.2-1.el7.x86_64
qemu-kvm-rhev-2.12.0-24.el7.x86_64
kernel-3.10.0-957.el7.x86_64
python-ovirt-engine-sdk4-4.3.0-1.el7ev.x86_64
rhv-guest-tools-iso-4.3-3.el7ev.noarch

rhv:4.3.0.1-0.1.el7

Steps:
Background: Since Q35 is fully supported from RHEL7.3, I tested with following linux guest: rhel7.2/rhel7.3/rhel7.4/rhel7.5/rhel7.6

1. Convert a rhel7.6 guest from esxi server to rhv by virt-v2v command.
# virt-v2v -ic vpx://root@10.73.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.6-uefi-without-agent --password-file /tmp/passwd -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem  -oo rhv-direct=true -oo rhv-cluster=nfs -of raw 
Exception AttributeError: "'module' object has no attribute 'dump_plugin'" in <module 'threading' from '/usr/lib64/python2.7/threading.pyc'> ignored
[   0.2] Opening the source -i libvirt -ic vpx://root@10.73.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.6-uefi-without-agent
[   2.4] Creating an overlay to protect the source from being modified
[   3.1] Opening the overlay
[  25.8] Inspecting the overlay
[ 190.9] Checking for sufficient free disk space in the guest
[ 190.9] Estimating space required on target for each disk
[ 190.9] Converting Red Hat Enterprise Linux Server 7.6 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[1778.2] 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
[1781.1] Closing the overlay
[1781.3] Assigning disks to buses
[1781.3] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[1781.3] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os nfs_data
[1782.6] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.HPztQp/nbdkit0.sock", "file.export": "/" } (raw)
    (100.00/100%)
[2854.6] Creating output metadata
[2870.1] Finishing off

2. Power on the guest on rhv4.3 and check.
Result: 
2.1 Guest can start successfully, and network works well.
2.2 Based on uefi I checked:
BIOS Type: Q35 Chipset with UEFI BIOS
Vm Devices: The USB controller is qemu-xhci.

3. Do above testing with rhel7.5/rhel7.4/rhel7.3 guests, all passed.

@rjones, do you think our checkpoints is enough to test this feature, thanks.

Comment 15 Richard W.M. Jones 2019-03-25 12:50:19 UTC
> BIOS Type: Q35 Chipset with UEFI BIOS

Yes that should be enough proof I think.

Comment 16 zhoujunqin 2019-03-27 09:54:54 UTC
Based on Comment 14, i tested with windows guests: win10-x64 and win2019, they are all working well.

1. Convert a win10 guest from esxi server to rhv by virt-v2v command.

# virt-v2v -ic vpx://root@10.73.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win10-x86_64-efi --password-file /tmp/passwd -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem  -oo rhv-direct=true -oo rhv-cluster=nfs -of raw -b ovirtmgmt
Exception AttributeError: "'module' object has no attribute 'dump_plugin'" in <module 'threading' from '/usr/lib64/python2.7/threading.pyc'> ignored
[   0.2] Opening the source -i libvirt -ic vpx://root@10.73.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win10-x86_64-efi
[   2.1] Creating an overlay to protect the source from being modified
[   2.7] Opening the overlay
[  17.3] Inspecting the overlay
[ 149.7] Checking for sufficient free disk space in the guest
[ 149.7] Estimating space required on target for each disk
[ 149.7] Converting Windows 10 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 (10.0 
x86_64).  virt-v2v looks for this driver in 
/usr/share/virtio-win/virtio-win.iso

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[ 181.4] 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
[ 182.3] Closing the overlay
[ 182.5] Assigning disks to buses
[ 182.5] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 182.5] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os nfs_data
[ 184.3] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.1HQqSy/nbdkit0.sock", "file.export": "/" } (raw)
    (100.00/100%)
[1573.9] Creating output metadata
[1592.4] Finishing off

2. Power on the guest on rhv4.3 and check.
Result: 
2.1 Guest can start successfully, and network works well.
2.2 Based on uefi I checked:
BIOS Type: Q35 Chipset with UEFI BIOS

Result: virt-v2v can convert a windows uefi guest from esxi server to rhv successfully.

Comment 17 zhoujunqin 2019-03-27 12:54:52 UTC
Created attachment 1548574 [details]
Screenshot for boot up failure

Comment 18 zhoujunqin 2019-03-27 12:58:28 UTC
Hi rjones,
I also do more testing about import vm on rhv UI, but it failed to boot up, for the BIOS type is set as 'default', i don't find anywhere to set BIOS type during importing.

Steps:
1. Login with administration portal, System->Virtual Machines. 
2. Click "Import" button, then "Import Virtual Machine(s)" window pop up. Then you can choose "Data Center" and "Soure" which you want to use.
Data Center
Source:Export Domain
            Virtual Appliance (OVA)           
            XEN (Via RHEL)
            KVM (Via Libvirt)
            VMware
3. Select VMware as source  and complete details for my vCenter environment, then click "Load" button
4. After load, then select guest name list in "Virtual Machines on Source" to import, then click "Next" , then click "OK" in next page, then guest import start.

Result:
4.1 Import vm from VMware finished successfully.
4.2 Guest failed to boot up, please see screenshot.

Please help me have a look, thanks.

Comment 19 zhoujunqin 2019-03-27 12:59:02 UTC
Created attachment 1548575 [details]
import log

Comment 20 Richard W.M. Jones 2019-03-27 13:37:10 UTC
There's not much information to do on here.  I suggest opening a new bug against
ovirt-engine and we can collect the extra information there.  We'll probably need
to see the oVirt logs from when the guest was booted and the full qemu command line.

However from the virt-v2v point of view:

- It's a UEFI guest.
- We are setting the correct <BiosType> (UEFI = 2) in the output OVF.

Comment 21 zhoujunqin 2019-03-28 08:42:47 UTC
(In reply to Richard W.M. Jones from comment #20)
> There's not much information to do on here.  I suggest opening a new bug
> against
> ovirt-engine and we can collect the extra information there.  We'll probably
> need
> to see the oVirt logs from when the guest was booted and the full qemu
> command line.
> 
> However from the virt-v2v point of view:
> 
> - It's a UEFI guest.
> - We are setting the correct <BiosType> (UEFI = 2) in the output OVF.

Thanks for your reply, rjones.
I filed a new Bug 1693571 - UEFI-vm failed to boot up after importing from VMware against Comment 18 issue, thanks.

Comment 22 Michal Skrivanek 2019-03-29 06:52:01 UTC
yes, that's specific to the RHV intergrated import, shouldn't block validation of this RFE


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