Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1601824

Summary: RFE: Fail earlier if conflicting resources would be used by guest on RHV
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: mxie <mxie>
Component: virt-v2vAssignee: Richard W.M. Jones <rjones>
Status: CLOSED CURRENTRELEASE QA Contact: tingting zheng <tzheng>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: jsuchane, juzhou, mkalinin, mzhan, ptoscano, rjones, tzheng, xiaodwan, xinyli
Target Milestone: rcKeywords: FutureFeature, Reopened
Target Release: 8.1Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Unspecified   
Whiteboard: V2V
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-04-27 16:05:26 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1649160    
Attachments:
Description Flags
rhv-upload-MAC.log
none
rhv-upload-cluster.log none

Description mxie@redhat.com 2018-07-17 10:03:30 UTC
Created attachment 1459380 [details]
rhv-upload-MAC.log

Description of problem:
Virt-v2v should create the guest firstly then uploads the disks secondly during rhv-upload conversion

Version-Release number of selected component (if applicable):
virt-v2v-1.38.2-8.el7.x86_64
libguestfs-1.38.2-8.el7.x86_64
libvirt-4.5.0-3.el7.x86_64
qemu-kvm-rhev-2.12.0-7.el7.x86_64
virtio-win-1.9.4-2.el7.noarch
libguestfs-winsupport-7.2-2.el7.x86_64
ovirt-imageio-daemon-1.4.1-0.el7ev.noarch
rhv:4.2.5-0.1.el7ev

How reproducible:
100%

Steps to Reproduce:
1. Convert the guest (rhv4.2 already has same one) from vmware to rhv4.2 using --rhv-upload and rename guest before conversion, the conversion will be failed due to MAC duplicates,details pls refer to log"rhv-upload-MAC"
# virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1  esx6.7-rhel7.5-x86_64 -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 -of raw --password-file /tmp/passwd -on mac-duplicates
[   0.3] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64
[   2.5] Creating an overlay to protect the source from being modified
[   3.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
[   5.1] Opening the overlay
[  24.9] Inspecting the overlay
[ 221.4] Checking for sufficient free disk space in the guest
[ 221.4] Estimating space required on target for each disk
[ 221.4] Converting Red Hat Enterprise Linux Server 7.5 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[1500.3] Mapping filesystem data to avoid copying unused and blank areas
[1503.6] Closing the overlay
[1504.5] Checking if the guest needs BIOS or UEFI to boot
[1504.5] Assigning disks to buses
[1504.5] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.yclduX/nbdkit1.sock", "file.export": "/" } (raw)
    (100.00/100%)
[2695.7] Creating output metadata
Traceback (most recent call last):
  File "/var/tmp/rhvupload.yclduX/rhv-upload-createvm.py", line 95, in <module>
    data = ovf,
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 33829, in add
    return self._internal_add(vm, headers, query, wait)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 232, in _internal_add
    return future.wait() if wait else future
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait
    return self._code(response)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 229, in callback
    self._check_fault(response)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault
    self._raise_error(response, body)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error
    raise error
ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Cannot import Virtual Machine, because that action would create duplicates in target MAC pool, which are not allowed. Either allow duplicate MACs in MAC Pool, or allow reassignment of bad MACs during import. Problematic NICs are 	VmNetworkInterface:{id='b8668d83-285f-415f-a8fb-9079568ef642', name='eth0', networkName='VM Network', vnicProfileName='null', vnicProfileId='null', speed='10000', type='3', macAddress='00:50:56:ac:1e:2e', active='true', linked='true', portMirroring='false', vmId='568b41f1-39f6-4e42-9048-29eced0e625c', vmName='null', vmTemplateId='null', QoSName='null', remoteNetworkName='VM Network'}]". HTTP response code is 409.
virt-v2v: error: failed to create virtual machine, see earlier errors

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

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


2.Convert a guest from vmware to rhv4.2 using --rhv-upload and set wrong cluster, the conversion will be failed due to wrong cluster name,details pls refer to log "rhv-upload-cluster"
# virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1  esx6.7-win8.1-x86_64  -o rhv-upload -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -os iscsi_data -op /tmp/rhvpasswd -oo rhv-cafile=/root/ca.pem  -oo rhv-direct -of raw --password-file /tmp/passwd -b ovirtmgmt -oa preallocated
[   0.8] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win8.1-x86_64
[   3.5] Creating an overlay to protect the source from being modified
[   4.6] Initializing the target -o rhv-upload -oa preallocated -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os iscsi_data
[   6.2] Opening the overlay
[  24.9] Inspecting the overlay
[ 161.9] Checking for sufficient free disk space in the guest
[ 161.9] Estimating space required on target for each disk
[ 161.9] Converting Windows 8.1 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 (6.3 
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.
[ 199.8] Mapping filesystem data to avoid copying unused and blank areas
[ 201.9] Closing the overlay
[ 202.6] Checking if the guest needs BIOS or UEFI to boot
[ 202.7] Assigning disks to buses
[ 202.7] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.0jrkqF/nbdkit1.sock", "file.export": "/" } (raw)
    (100.00/100%)
[3028.7] Creating output metadata
Traceback (most recent call last):
  File "/var/tmp/rhvupload.0jrkqF/rhv-upload-createvm.py", line 95, in <module>
    data = ovf,
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 33829, in add
    return self._internal_add(vm, headers, query, wait)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 232, in _internal_add
    return future.wait() if wait else future
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait
    return self._code(response)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 229, in callback
    self._check_fault(response)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault
    self._raise_error(response, body)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error
    raise error
ovirtsdk4.NotFoundError: Fault reason is "Operation Failed". Fault detail is "Entity not found: Cluster: name=Default". HTTP response code is 404.
virt-v2v: error: failed to create virtual machine, see earlier errors

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

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


Actual results:
1.Virt-v2v report MAC address problem after copying during rhv-upload conversion
2.Virt-v2v report cluster problem after copying during rhv-upload conversion

Expected results:
1.Virt-v2v report MAC address problem before copying during rhv-upload conversion
2.Virt-v2v report cluster problem before copying during rhv-upload conversion

Additional info:

Comment 2 mxie@redhat.com 2018-07-17 10:07:34 UTC
Created attachment 1459381 [details]
rhv-upload-cluster.log

Comment 4 Pino Toscano 2019-09-23 16:41:00 UTC
BTW, the issues related to the wrong cluster (or not belonging to the specified data center) were solved as part of the fixes for bug 1612653.

Comment 7 RHEL Program Management 2021-02-15 07:40:42 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 8 Richard W.M. Jones 2021-02-15 09:08:29 UTC
I'm sorry, this bug was closed in error by the "stale bugs" process.

Comment 9 Richard W.M. Jones 2021-04-27 16:05:26 UTC
Most of this is fixed upstream since virt-v2v 1.40, and the rest is
unfixable without deep architectural changes to virt-v2v and/or RHV.
Since there is still an error message produced, albeit at a late
stage in the conversion process, I am closing this.

Comment 10 xinyli 2021-05-13 01:58:32 UTC
Test the bug with below builds:

virt-v2v-1.44.0-1.el9.1.x86_64

libguestfs-1.45.5-1.el9.x86_64

libvirt-7.0.0-6.el9.x86_64

qemu-kvm-6.0.0-1.el9.x86_64

nbdkit-1.25.4-2.el9.x86_64

scenarios 1. Convert the guest (rhv4.4 already has same one) from vmware to rhv4.4 using --rhv-upload and rename guest before conversion, the conversion will be failed due to MAC duplicates,details pls refer to log"rhv-upload-MAC"
# virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1  esx6.7-rhel7.5-x86_64 -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -ip /home/passwd -op /home/rhvpasswd -os nfs_data -b ovirtmgmt -on mac-duplicates
[   0.7] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64
[   6.3] Creating an overlay to protect the source from being modified
[   9.4] Opening the overlay
[  51.6] Inspecting the overlay
[ 775.6] Checking for sufficient free disk space in the guest
[ 775.6] Estimating space required on target for each disk
[ 775.6] Converting Red Hat Enterprise Linux Server 7.5 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[2754.7] Mapping filesystem data to avoid copying unused and blank areas
[2757.4] Closing the overlay
[2757.7] Assigning disks to buses
[2757.7] Checking if the guest needs BIOS or UEFI to boot
[2757.7] Initializing the target -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data
[2761.1] Copying disk 1/3 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.WMeU9Q/nbdkit6.sock", "file.export": "/" } (qcow2)
    (100.00/100%)
[3061.4] Copying disk 2/3 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.ZdQQn3/nbdkit7.sock", "file.export": "/" } (qcow2)
    (100.00/100%)
[6714.4] Copying disk 3/3 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.6ekCRX/nbdkit8.sock", "file.export": "/" } (qcow2)
    (100.00/100%)
[7345.7] Creating output metadata
Traceback (most recent call last):
  File "/tmp/v2v.gaoSdh/rhv-upload-createvm.py", line 72, in <module>
    vm = vms_service.add(
  File "/usr/lib64/python3.9/site-packages/ovirtsdk4/services.py", line 37679, in add
    return self._internal_add(vm, headers, query, wait)
  File "/usr/lib64/python3.9/site-packages/ovirtsdk4/service.py", line 232, in _internal_add
    return future.wait() if wait else future
  File "/usr/lib64/python3.9/site-packages/ovirtsdk4/service.py", line 55, in wait
    return self._code(response)
  File "/usr/lib64/python3.9/site-packages/ovirtsdk4/service.py", line 229, in callback
    self._check_fault(response)
  File "/usr/lib64/python3.9/site-packages/ovirtsdk4/service.py", line 132, in _check_fault
    self._raise_error(response, body)
  File "/usr/lib64/python3.9/site-packages/ovirtsdk4/service.py", line 118, in _raise_error
    raise error
ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Cannot import Virtual Machine, because that action would create duplicates in target MAC pool, which are not allowed. Either allow duplicate MACs in MAC Pool, or allow reassignment of bad MACs during import. Problematic NICs are ${ACTION_TYPE_FAILED_CANNOT_ADD_IFACE_DUE_TO_MAC_DUPLICATES_LIST}, $action type failed cannot add iface due to mac duplicates list 	eth0,
	eth1]". HTTP response code is 409.
virt-v2v: error: failed to create virtual machine, see earlier errors

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

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


scenarios: 2.Convert a guest from vmware to rhv4.4 using --rhv-upload and set wrong cluster, the conversion will be failed due to wrong cluster name,details pls refer to log "rhv-upload-cluster"

# virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1  esx6.7-win8.1-x86_64 -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -ip /home/passwd -op /home/rhvpasswd -os nfs_data -oo rhv-cluster=test  -b ovirtmgmt 
Traceback (most recent call last):
  File "/tmp/v2v.F0lIjl/rhv-upload-precheck.py", line 91, in <module>
    raise RuntimeError("The cluster ‘%s’ is not part of the DC ‘%s’, "
RuntimeError: The cluster ‘test’ is not part of the DC ‘Default’, where the storage domain ‘nfs_data’ is
virt-v2v: error: failed server prechecks, see earlier errors

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

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

conclusion:
1: During rhv-upload conversion, Virt-v2v will report MAC address problems after copying, so the problem has not been fixed.
2: The problem has been fixed

Comment 11 Richard W.M. Jones 2021-05-13 07:30:26 UTC
Correct, we're not able to fully fix this without architectural changes
to virt-v2v (and indeed RHV), so it's not really possible to fix it fully.

As long as an error message is produced, even if it's late, that's the
best we can do.  In the comment above I can see a reasonably clear error
message.