Created attachment 1340565 [details] error-picture Description of problem: Failed to import the guest from export domain to data domain with error "General command validation failure" Version-Release number of selected component (if applicable): virt-v2v-1.36.7-1.el7.x86_64 vdsm-4.19.34-1.el7ev.x86_64 rhv4.1.7.3-0.1.el7 How reproducible: 100% Steps to Reproduce: Scenario1: 1.Convert guest from a ova file to rhv by virt-v2v . # virt-v2v -i ova /var/tmp/esx-rhel6.8-ova.tar -o rhv -os 10.73.131.91:/home/nfs_export -of qcow2 [ 0.0] Opening the source -i ova /var/tmp/esx-rhel6.8-ova.tar virt-v2v: warning: making OVA directory public readable to work around libvirt bug https://bugzilla.redhat.com/1045069 [ 1.7] Creating an overlay to protect the source from being modified [ 1.8] Initializing the target -o rhv -os 10.73.131.91:/home/nfs_export [ 2.1] Opening the overlay [ 2.9] Inspecting the overlay [ 10.3] Checking for sufficient free disk space in the guest [ 10.3] Estimating space required on target for each disk [ 10.3] Converting Red Hat Enterprise Linux Server release 6.8 (Santiago) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 49.1] Mapping filesystem data to avoid copying unused and blank areas [ 49.2] Closing the overlay [ 49.4] Checking if the guest needs BIOS or UEFI to boot [ 49.4] Assigning disks to buses [ 49.4] Copying disk 1/1 to /tmp/v2v.BWmUF9/542a4a32-d932-4231-8cfc-6aaf43fb43d7/images/2b9c2589-4244-4e34-9798-4b3146b44206/307ff678-ac97-44a4-a677-7f6bd3302d64 (qcow2) (100.00/100%) [ 104.5] Creating output metadata [ 104.6] Finishing off 2.After conversion successfully , import the guest from export domain to data domain,but failed to import.The error below and as attachment. "Error while executing action: esx5.5-rhel6.8-x86_64: General command validation failure. " 3.We can see engine log with attachment log. Actual results: As above description Expected results: Should import the guest from export domain to data domain successfully Additional info:
Created attachment 1340566 [details] engine-log
Did you miss the exception? Caused by: java.lang.NumberFormatException: For input string: "" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_102] at java.lang.Long.parseLong(Long.java:601) [rt.jar:1.8.0_102] at org.ovirt.engine.core.utils.MacAddressRangeUtils.macToLong(MacAddressRangeUtils.java:124) [utils.jar:] at org.ovirt.engine.core.bll.network.macpool.MacPoolUsingRanges.isMacInUse(MacPoolUsingRanges.java:152) [bll.jar:] Dan - can someone from your team take a look?
Did the same flow succeed on 4.1.6? Could it be a recent regression?
BTW, a separate bug would be to improve the failure message.
Can you attach the offending OVA?
Here was my reply to comment 10 from email: I'm missing a bit of context here, but I will just say that ‘-i disk’ is intended mainly for testing. Because you only have to provide a disk, there is no metadata. Thus virt-v2v has to make it up. In this case it invents a network interface which has no MAC address[1] and so the output OVF would also lack a <MACAddress> field. We could, I suppose, make up a MAC address but I think it's better for RHV to handle the no-MAC case. (I believe the same thing happens if the libvirt or VMware input guest lacks a MAC address in its metadata, but I don't know if such a thing can happen in the real world). https://github.com/libguestfs/libguestfs/blob/0942241395b7faf02fd651a0d7b9962845 8febe4/v2v/input_disk.ml#L72
Created attachment 1343178 [details] engine.log (issue starts at: 2017-10-25 14:14:08,217+03)
Created attachment 1343179 [details] vdsm.log (issue starts at: 2017-10-25 14:13:53,336)
I don't know if it's the bug you are seeing but I notice that the -i ova method does not parse the MAC address from the source VMware OVF (inside the OVA file). See https://github.com/libguestfs/libguestfs/blob/0942241395b7faf02fd651a0d7b99628458febe4/v2v/parse_ovf_from_ova.ml#L236 Please could you file a bug about this against libguestfs. I believe from a brief inspection of the virt-v2v code that only -i disk (unavoidable - see above) and -i ova have this problem.
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1506572
I've succeed to import VMware OVA (With MAC address included) using this bug steps to reproduce with build ovirt-engine-4.2.0-0.0.master.20171029154613.git19686f3.el7.centos. [root@intel-vfio RHEL7_1_with_MAC]# LIBGUESTFS_BACKEND=direct virt-v2v -i ova /home/nisim/RHEL7_1_with_MAC -o rhv -os yellow-vdsb.qa.lab.tlv.redhat.com:/Compute_NFS/nsimsolo_export_40 -of qcow2 [ 0.0] Opening the source -i ova /home/nisim/RHEL7_1_with_MAC virt-v2v: warning: ova disk has an unknown VMware controller type (20), please report this as a bug supplying the *.ovf file extracted from the ova [ 0.8] Creating an overlay to protect the source from being modified [ 0.8] Initializing the target -o rhv -os yellow-vdsb.qa.lab.tlv.redhat.com:/Compute_NFS/nsimsolo_export_40 [ 0.9] Opening the overlay [ 1.7] Inspecting the overlay [ 4.8] Checking for sufficient free disk space in the guest [ 4.8] Estimating space required on target for each disk [ 4.8] Converting Red Hat Enterprise Linux Client 7.0 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 25.7] Mapping filesystem data to avoid copying unused and blank areas [ 27.0] Closing the overlay [ 27.0] Checking if the guest needs BIOS or UEFI to boot [ 27.0] Assigning disks to buses [ 27.0] Copying disk 1/1 to /tmp/v2v.Qh1x1k/bc20e460-d360-4702-9a51-70e87c626a6f/images/193f083f-4a84-47ac-9efd-e701893905e5/3451c786-708a-477d-ae30-d6281b4e3b95 (qcow2) (100.00/100%) [ 49.4] Creating output metadata [ 49.4] Finishing off [root@intel-vfio RHEL7_1_with_MAC]# Browse webadmin -> storage -> domains -> export domain -> VM import tab and select VM to import.
Verification build: rhevm-4.1.7.5-0.1.el7 qemu-kvm-rhev-2.9.0-16.el7_4.8.x86_64 vdsm-4.19.36-1.el7ev.x86_64 libvirt-client-3.2.0-14.el7_4.3.x86_64 sanlock-3.5.0-1.el7.x86_64 Verification scenario: 1. Export ova file to export domain using 'virt-v2v -i ova' command (tried on both OVA with MAC and OVA without MAC address). 2. Browse Webadmin -> storage tab -> select export domain -> VM import sub tab, select uploaded VM and import it. 3. Wait for import progress to end, run VM. 4. Verify VM is running properly with correct configuration.
*** Bug 1378045 has been marked as a duplicate of this bug. ***
(In reply to Nisim Simsolo from comment #20) > I've succeed to import VMware OVA (With MAC address included) using this bug > steps to reproduce with build > ovirt-engine-4.2.0-0.0.master.20171029154613.git19686f3.el7.centos. Can oVirt now make up a MAC address if one is *not* present in the OVF metadata? For some reason bug 1378045 was marked as a duplicate of this one, but that is *not* the correct resolution if oVirt cannot handle the case of no MAC address in metadata.
(In reply to Richard W.M. Jones from comment #23) > (In reply to Nisim Simsolo from comment #20) > > I've succeed to import VMware OVA (With MAC address included) using this bug > > steps to reproduce with build > > ovirt-engine-4.2.0-0.0.master.20171029154613.git19686f3.el7.centos. > > Can oVirt now make up a MAC address if one is *not* present in the OVF > metadata? > > For some reason bug 1378045 was marked as a duplicate of this one, but > that is *not* the correct resolution if oVirt cannot handle the case of > no MAC address in metadata. In case of no mac address in metadata, oVirt will assign a new mac from the mac pool.