Bug 1503947

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.