Description of problem:
Would be good to allow choosing the network interface, so that the faster network interface will be used, to allow a faster data transfer.

Otherwise, data transfer, may be done via the default route, that might be configured with 1GB, or 100MB, and case poor data transfer performance. 

Here's Fabien D. input regarding this:
"Data transfer between will ESX and conversion host (independently of provider) will occur accordingly to the routes defined on the conversion hosts. If a static route is set to reach the ESX hosts, it will be used. If the ESX host interface is in the same network as the conversion host, there's no need to set a static as one is automatically create to access peers on the same subnet. The main issue here is that the IP address of the ESX host is the admin interface: that's how the migration code is implemented today. And this is due to the fact that we cannot know which interface we should use among all the NIC of the host, so we use the default one which is the one that is used to communicate with vCenter, and that is also most probably a 1Gbps link.

I checked on our infrastructure (vSphere 6.5) and the ESXi hosts listen on port 902/tcp (VDDK) on all interfaces, so in theory, we could specify a different NIC than the one used for admin. This would though require an action from the user to "tag" the NICs on all the ESXi hosts, so that we could pick the correct one when generate the URI for ESXi link. This would require adding the "acts_as_miq_taggable" extension to the GuestDevice class, and it could be pretty long to do. Another possibility would be tag a specific virtual switch, i.e. Switch class, as it is already taggable and we can get the IP address of each host on a specific switch.

Following this idea, we could use the switch tag to retrieve the IP address of the host. If no switch is tagged as migration or if the host has no IP address on the switch (acts as a bridge), then we would default to the admin IP address.
This would though require some UI work, because the HostVirtualSwitch are exposed in a limited way in CloudForms UI, and most of the time the storage network (most probable choice) is based on HostVirtualSwitch, not DistributedVirtualSwitch.
Assuming that the switch names are consistent across ESXi hosts, we could expose them as a smaller list and allow selection. But assuming is dangerous... So, we could also have a table widget where all hosts would be displayed, with a dropdown to select the switch."

Version-Release number of selected component (if applicable):
CFME-5.11.0.22


Additional info:
We encountered in QE lab, a case where VM with 100GB disk vddk migration took 35 minutes, because the data path, was going through RHV management interface, that was configured to 1GB. Moving to 10GB, by changing host routes, improved the migration to ~17 minutes.