RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1509931 - [RFE] v2v: UEFI support in RHV export
Summary: [RFE] v2v: UEFI support in RHV export
Keywords:
Status: CLOSED ERRATA
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
Jiri Herrmann
URL:
Whiteboard: V2V
Depends On: 1327846 1532969 1613496 1621895
Blocks: 1651787
TreeView+ depends on / blocked
 
Reported: 2017-11-06 11:23 UTC by Pino Toscano
Modified: 2019-08-06 12:44 UTC (History)
14 users (show)

Fixed In Version: libguestfs-1.40.1-1.el7
Doc Type: Enhancement
Doc Text:
.`virt-v2v` can convert UEFI guests for RHV Using the `virt-v2v` utility, it is now possible to convert virtual machines that use the UEFI firmware to run in Red Hat Virtualization (RHV).
Clone Of:
Environment:
Last Closed: 2019-08-06 12:44:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Screenshot for boot up failure (92.94 KB, image/png)
2019-03-27 12:54 UTC, zhoujunqin 		no flags Details
import log (1.36 MB, text/plain)
2019-03-27 12:59 UTC, zhoujunqin 		no flags Details
esx6.7-rhel7.7-es-efi conversion log (3.21 MB, text/plain)
2019-06-17 14:32 UTC, zhoujunqin 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1112275 1 None None None 2023-03-24 13:29:13 UTC
Red Hat Product Errata RHEA-2019:2096 0 None None None 2019-08-06 12:44:35 UTC

Internal Links: 1112275

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.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.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.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.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
Comment 23 zhoujunqin 2019-04-19 10:02:17 UTC 
Verify this bug with packages:
libvirt-4.5.0-12.el7.x86_64
libguestfs-1.40.2-3.el7.x86_64
virt-v2v-1.40.2-3.el7.x86_64
qemu-kvm-rhev-2.12.0-26.el7.x86_64
python-ovirt-engine-sdk4-4.3.1-1.el7ev.x86_64
rhv-guest-tools-iso-4.3-6.el7ev.noarch
kernel: 3.10.0-1018.el7.x86_64

rhv:4.3.0.1-0.1.el7

Steps:
Background: Since Q35 is fully supported from RHEL7.3, I test with following linux guests: rhel7.3/rhel7.4/rhel7.5/rhel7.6/rhel7.7

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

# 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 esx6.7-rhel7.7-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.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.7-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.0] Creating an overlay to protect the source from being modified
[   5.2] Opening the overlay
[  12.0] Inspecting the overlay
[  35.4] Checking for sufficient free disk space in the guest
[  35.4] Estimating space required on target for each disk
[  35.4] Converting Red Hat Enterprise Linux Server 7.7 Beta (Maipo) to run on KVM
virt-v2v: warning: failed to install QEMU Guest Agent: command: 	package 
qemu-guest-agent-10:2.12.0-3.el7.x86_64 (which is newer than 
qemu-guest-agent-10:2.12.0-2.el7.x86_64) is already installed
virt-v2v: This guest has virtio drivers installed.
[ 142.4] 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
[ 143.1] Closing the overlay
[ 143.4] Assigning disks to buses
[ 143.4] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 143.4] 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
[ 146.2] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.51vQuK/nbdkit0.sock", "file.export": "/" } (raw)
    (100.00/100%)
[ 643.4] Creating output metadata
[ 662.9] Finishing off

2. After conversion, 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

3. Do loop testing with rhel7.6/rhel7.5/rhel7.4/rhel7.3/rhel7.2 uefi guests installed on Esxi Server, all conversion finish successfully and vms boot up with no error.

4. Convert a windows guest from esxi server to rhv by virt-v2v command.

# 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 esx6.7-win2019-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.3] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win2019-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.2] Creating an overlay to protect the source from being modified
[   3.3] Opening the overlay
[   7.5] Inspecting the overlay
[  11.7] Checking for sufficient free disk space in the guest
[  11.7] Estimating space required on target for each disk
[  11.7] Converting Windows Server 2019 Standard 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/rhv-guest-tools-iso/rhv-tools-setup.iso

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[  15.5] 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
[  17.0] Closing the overlay
[  17.2] Assigning disks to buses
[  17.2] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[  17.2] 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
[  19.0] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.PKqstp/nbdkit0.sock", "file.export": "/" } (raw)
    (100.00/100%)
[1230.4] Creating output metadata
[1245.8] Finishing off

Result: virt-v2v can convert win2019 vm from vmware to rhv successfully, and guest can start, BIOS type shows correctly: "Q35 Chipset with UEFI BIOS"

As a summary, virt-v2v can convert uefi guest from vmware to rhv successfully and guest can boot up on rhv, and I have filed Bug 1693571 to track RHV integrated import issue, I move this bug from ON_QA to VERIFIED status, thanks.
Comment 24 zhoujunqin 2019-06-17 14:30:45 UTC 
Hi Pino,
I test with a EFI rhel7.6 vm and with Security Boot enabled.

Packages:
libvirt-4.5.0-22.el7.x86_64
libguestfs-1.40.2-5.el7.x86_64
virt-v2v-1.40.2-5.el7.x86_64
qemu-kvm-rhev-2.12.0-32.el7.x86_64
python-ovirt-engine-sdk4-4.3.1-1.el7ev.x86_64
kernel-3.10.0-1055.el7.x86_64

Software Version:4.3.0-0.8.rc2.el7

Steps:
1. Convert a rhel7.6 guest from esxi server to rhv by virt-v2v command.

# 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 esx6.7-rhel7.7-es-efi  --password-file /tmp/passwd -o rhv-upload -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.crt  -oo rhv-direct=true -oo rhv-cluster=NFS -of raw  -b ovirtmgmt -v -x |& tee>esx6.7-rhel7.7-es-efi

2. After conversion, 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
Comment 25 zhoujunqin 2019-06-17 14:32:10 UTC 
Created attachment 1581457 [details]
esx6.7-rhel7.7-es-efi conversion log
Comment 26 Pino Toscano 2019-06-17 14:50:12 UTC 
(In reply to zhoujunqin from comment #24)
> Hi Pino,
> I test with a EFI rhel7.6 vm and with Security Boot enabled.
> [...]
> 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

Thanks!
Comment 28 errata-xmlrpc 2019-08-06 12:44:11 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/RHEA-2019:2096
Note You need to log in before you can comment on or make changes to this bug.