VMware Migration Network Flows

[dominicb]

Hello

We have an environment where we have a global HA vCenter which manages a number of regional clusters across APAC, NA and EMEA.  

It appears the migration feature in VM Essentials uses the vCenter to create an OVF export of a VM, which is streamed from the vCenter to the destination hypervisor (this is looking at our firewall logs).  This is creating a considerable performance bottleneck during migration between global regions as opposed to a direct hypervisor to hypervisor transfer.

For instance migration of VM from a vmWare  cluster in EMEA to a HVM host in the same local network, is using the vCenter in North America to create the OVF export. 

Can you please clarify if migration network flows solely rely on OVF export via the vCenter?  If this is the case, the migration tool in Morpheus is somewhat limited in scope.

Other solutions we have used, including Commvault (for backup), query the vCenter to obtain topology of the environment, the ESXi host of a VM, then stream directly from the ESXi host and as such do not suffer from performance issues of sending data across the WAN.

A work around may be to use Commvault to undertake the VM migration.  However this feaure appears in the pipeline at present: https://community.commvault.com/virtualization-and-containers-48/vmware-conversion-to-hpe-vme-11704

I assume Veam works in a similar fashion.

Kind Regards

[DiegoDelgado]

I recommend you do a TCP dump during a migration just to make sure. I'm saying this because I just tried it to make sure and a TCP dump showed this as the traffic:

20:22:05.262340 IP esxi.https > hvm.52562: Flags [P.], seq 239783121:239799534, ack 1, win 130, options [nop,nop,TS val 80713761 ecr 3603803199], length 16413
20:22:05.262365 IP esxi.https > hvm.52562: Flags [P.], seq 239799534:239814123, ack 1, win 130, options [nop,nop,TS val 80713761 ecr 3603803199], length 14589
20:22:05.262560 IP hvm.52562 > esxi.https: Flags [.], ack 239793257, win 18198, options [nop,nop,TS val 3603803202 ecr 80713761], length 0
20:22:05.262588 IP hvm.52562 > esxi.https: Flags [.], ack 239799534, win 18240, options [nop,nop,TS val 3603803202 ecr 80713761], length 0
20:22:05.263674 IP hvm.52562 > esxi.https: Flags [.], ack 239814123, win 18174, options [nop,nop,TS val 3603803203 ecr 80713761], length 0

(changed IPs for hvm and esxi respectively)

[browned]

We used Veeam and the VME Plugin, with a few tweaks from Veeam support. No issues with network traffic. Local vCenter and VME Manager and Veeam B&R server. Restored to VME SimpliVity hosts on a remote network using a remote proxy and remote repository. Once the migration is underway it is all local.

The migration did as you say, save the OVF through Vcenter, upload it as an image to the VME Manager, then push it to the host for deployment. Not the best approach but this seems limited by the vCenter and VME Manager capabilities.