Created attachment 1411229 [details] Debug logs Description of problem: When using -o rhv-upload to migrate VMs from VMware to RHEVM, the specified network settings are not being honored by virt-v2v. Sample cmdline for migration : virt-v2v -v -x -ic vpx://vsphere.local%5cadministrator.2.21/V2V_Datacenter/V2V%20Cluster/esx01.v2v.example.com?no_verify=1 test_migration --password-file ./vcenter-password -o rhv-upload -oc https://rhvm.v2v.bos.redhat.com/ovirt-engine/api -os V2V-Data1 -op ./ovirt-admin-password --rhv-cafile ./ca.pem --rhv-direct --network VM_Network --rhv-cluster V2V |& tee /tmp/virt-v2v-mig.log At very end of the debug output is the OVF data as follows : <Item> <rasd:InstanceId>804f5e8a-9c90-4a21-8f35-95f3d5e48d4e</rasd:InstanceId> <rasd:Caption>Ethernet adapter on VM Network</rasd:Caption> <rasd:ResourceType>10</rasd:ResourceType> <rasd:ResourceSubType>3</rasd:ResourceSubType> <Type>interface</Type> <rasd:Connection>VM Network</rasd:Connection> <rasd:Name>eth0</rasd:Name> <rasd:MACAddress>00:50:56:9d:11:5d</rasd:MACAddress> </Item> The desired network on Ovirt is actually VM_Network, ovirt engine logs also show a warning while importing the VM since the supplied logical network does not exist with that name : --- engine.log:2018-03-21 09:26:28,569-04 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-20) [a8988d23-0f7d-44cd-b838-f9af33d62532] EVENT_ID: IMPORTEXPORT_IMPORT_VM_INVALID_INTERFACES(9,600), While importing VM test_migration, the Network/s VM Network were found to be Non-VM Networks or do not exist in Cluster or are missing a suitable VM network interface profile. Network Name was not set in the Interface/s eth0. --- Version-Release number of selected component (if applicable): RHEL7.5Beta virt-v2v-1.36.10-6.2.rhvpreview.el7.x86_64 libguestfs-tools-c-1.36.10-6.2.rhvpreview.el7.x86_64 libguestfs-1.36.10-6.2.rhvpreview.el7.x86_64 libguestfs-winsupport-7.2-2.el7.x86_64 qemu-kvm-common-rhev-2.10.0-21.el7_5.1.x86_64 qemu-kvm-rhev-2.10.0-21.el7_5.1.x86_64 How reproducible: Steps to Reproduce: 1. Use -o rhv-upload and request a --network different from the source 2. 3. Actual results: Network name is not set properly Expected results: --network should be honored Additional info:
Using --bridge instead of --network has actually the intended effect and maps the network interfaces correctly when migrating from VMware source to RHV. This can be seen at the very end of virt-v2v debug output : <Item> <rasd:InstanceId>ff411843-5c94-40cf-97b9-adbab3a11df7</rasd:InstanceId> <rasd:Caption>Ethernet adapter on VM_Network</rasd:Caption> <rasd:ResourceType>10</rasd:ResourceType> <rasd:ResourceSubType>3</rasd:ResourceSubType> <Type>interface</Type> <rasd:Connection>VM_Network</rasd:Connection> <rasd:Name>eth0</rasd:Name> <rasd:MACAddress>00:50:56:9d:11:5d</rasd:MACAddress> </Item> Perhaps a note could be added regarding network mappings when migrating from VMware sources to RHV output. This could avoid confusion when --network is ignored.
It all becomes a bit clearer when I look at the source (use ‘--print-source’ to print this): source name: test_migration hypervisor type: vmware memory: 2147483648 (bytes) nr vCPUs: 1 CPU features: firmware: unknown display: video: vmvga sound: disks: [...] removable media: NICs: Bridge "VM Network" mac: 00:50:56:9d:11:5d [vmxnet3] ^^^^^^^^^^^^^^^^^^^ NICs can be of two types, either "Bridge" or "Network": https://github.com/libguestfs/libguestfs/blob/2bf88b102c24224d6a1d54c267ec55050175dc85/v2v/types.mli#L135 which is supposed to correspond to whether they are connected to a bridge or a network (whatever that even means), but in practice it just means whether the libvirt XML that libvirt's VMware driver is giving us contains <interface type='bridge'> or 'network'. In this case as we can see from the debug logs: <interface type='bridge'> <mac address='00:50:56:9d:11:5d'/> <source bridge='VM Network'/> <model type='vmxnet3'/> </interface> So that "explains" why you have to use --bridge instead of --network here. Unfortunately this just demonstrates how the virt-v2v --bridge/ --network mapping stuff which was copied from old virt-v2v is pretty fundamentally broken. For example, if you were to import the exact same guest from an OVA file, you'd use a different parser (not using libvirt) and that parser always creates Network-type NICs: https://github.com/libguestfs/libguestfs/blob/2bf88b102c24224d6a1d54c267ec55050175dc85/v2v/parse_ovf_from_ova.ml#L242 But if you parsed the exact same guest again from a .vmx file, which uses a third parser, it would roughly do the right thing: https://github.com/libguestfs/libguestfs/blob/2bf88b102c24224d6a1d54c267ec55050175dc85/v2v/input_vmx.ml#L370 (I suspect this is where libvirt is getting Bridge from as well because libvirt has its own vmx parser). The documentation is definitely wrong and the OVA parser is probably wrong too.
Patch posted: https://www.redhat.com/archives/libguestfs/2018-March/msg00150.html
Fixed in https://github.com/libguestfs/libguestfs/commit/992f835258221b240d4ca73ed32002c5e2b8a8b7 >= 1.39.2 / 1.38.1