Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
virt-v2v should give warning or error info when the --mac address rule is not been used
Version-Release number of selected component (if applicable):
libguestfs-1.40.2-1.el7.x86_64
virt-v2v-1.40.2-1.el7.x86_64
libvirt-4.5.0-10.el7_6.4.x86_64
How reproducible:
100%
Steps to Reproduce:
1.Prepare a guest and check the guest's mac address.
# virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 --password-file /tmp/passwd --print-source
[ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64
Source guest information (--print-source option):
source name: esx6.7-rhel7.5-x86_64
hypervisor type: vmware
memory: 2147483648 (bytes)
nr vCPUs: 4
[...]
NICs:
Bridge "VM Network" mac: 00:50:56:ac:1e:2e [vmxnet3]
Bridge "VM Network" mac: 00:50:56:ac:bc:a7 [e1000e]
2.Convert the guest to rhv and use wrong mac address to map NIC to bridge.
# virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 --mac 00:50:56:ac:6a:23:network:ovirtmgmt --mac 00:50:56:ac:7f:61:network:ovirtmgmt --password-file /tmp/passwd -on rhel7.5-mac -o rhv -os 10.66.144.40:/home/nfs_export
[ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64
[ 2.3] Creating an overlay to protect the source from being modified
[ 3.2] Opening the overlay
[ 25.4] Inspecting the overlay
[ 299.9] Checking for sufficient free disk space in the guest
[ 299.9] Estimating space required on target for each disk
[ 299.9] Converting Red Hat Enterprise Linux Server 7.5 (Maipo) to run on KVM
virt-v2v: warning: guest tools directory ‘linux/el7’ is missing from
the virtio-win directory or ISO.
Guest tools are only provided in the RHV Guest Tools ISO, so this can
happen if you are using the version of virtio-win which contains just the
virtio drivers. In this case only virtio drivers can be installed in the
guest, and installation of Guest Tools will be skipped.
virt-v2v: This guest has virtio drivers installed.
[1706.1] Mapping filesystem data to avoid copying unused and blank areas
[1710.3] Closing the overlay
[1711.7] Assigning disks to buses
[1711.7] Checking if the guest needs BIOS or UEFI to boot
[1711.7] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export
[1712.4] Copying disk 1/1 to /tmp/v2v.X966iW/c980b640-cb59-47f7-a0fe-90312d33deae/images/b3292da3-37c6-4faa-9fcf-62e1db4503c0/3b4dab1d-b31e-48b5-bd2d-581c95cac96d (raw)
(100.00/100%)
[2163.7] Creating output metadata
[2163.8] Finishing off
You have mail in /var/spool/mail/root
Actual results:
The conversion can be finished successfully with no warning info about wrong mac address.
Expected results:
Virt-v2v can give warning or error info when the --mac address rule is not been used caused by the wrong mac address in command
Additional info:
Comment 2Richard W.M. Jones
2020-02-04 15:16:19 UTC
As this is tricky to fix and an RFC, leaving it on the backlog.
Comment 5RHEL Program Management
2021-03-15 07:33:57 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 6Richard W.M. Jones
2021-03-15 10:28:13 UTC
My apologies, this bug was closed by an automated process that we have no control
over, and it should not have been. I am reopening it.
Comment 7Klaus Heinrich Kiwi
2021-08-16 20:57:25 UTC
(In reply to liuzi from comment #0)
> Description of problem:
> virt-v2v should give warning or error info when the --mac address rule is
> not been used
>
<...snip...>
>
> Expected results:
> Virt-v2v can give warning or error info when the --mac address rule is not
> been used caused by the wrong mac address in command
I'm wondering if there are scenarios where we *want* to have the bridge mapping set to an interface that, at the time of the migration, does not exists (or is not connected) - i.e., hotplug, spare devices etc..
I'm setting to low severity since I guess most users will not realistically get bitten by this.
Comment 10RHEL Program Management
2021-12-31 07:27:01 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 11Richard W.M. Jones
2021-12-31 09:18:28 UTC
I have to apologise - this bug was closed in error by a process we have no
control over which closes bugs claiming they are "stale" when they are not.
We have tried to have this process removed, with no success. I am reopening
it and setting the "stale" date far into the future.
The patch has been accepted (lukewarmly) upstream per se, but Rich and I agree that this BZ is mostly without merit. (Please follow the link in comment 12 for the upstream discussion thread.) Closing as NOTABUG.