In last post of this series we deployed the Cloud Gateway and the Layer 2 Concentrator virtual appliances. Next is to explore various migration methods to migrate workloads from on-prem datacenter to the cloud.
If you are not following along this series, then I recommend reading earlier posts of this series from below links:
2: HCX Enterprise Deployment & Configuration
3: HCX Cloud Deployment & Configuration
5: Configuring Interconnect Networks
HCX enables bidirectional virtual machine mobility. Virtual Machines can be migrated to/from an HCX-enabled target site. The migration capability for both live (Powered-on) and cold (Powered-off) virtual machines. Following are the migration methods supported by HCX:
HCX No-Downtime aka Cross-Cloud vMotion
In HCX No-Downtime method, running VM’s are migrated from on-premise to cloud datacenter with absolutely no downtime. This migration is very similar to native vSphere vMotion migration.
If you are like me, you may be thinking that vMotion is performed between 2 hosts in same cluster or across cluster, but with HCX we have on-prem and cloud and there is no connection between Esxi hosts of on-prem and Esxi hosts running in cloud, then how are we able to vMotion to cloud?
That’s the beauty of HCX. If you remember then in very first post of this series we discussed about this. When Cross-cloud vMotion is triggered from HCX, the migration traffic is proxied to the Mobility Agent (MA) host (which gets added to cluster automatically when we deploy CGW). Since Mobility agent appear as another Esxi host in vSphere inventory, migration data lands there.
This migration data is then sent via the encrypted tunnel to the CGW in cloud side and once it reaches there, its proxied back to real Esxi host that is running in cloud. So in actual we are impersonating the MA hosts in both side as a real Esxi host and thus fooling the actual Esxi hosts.
HCX Cold Migration
Cold migration migrates the VM’s to cloud with the same logic as No-downtime migration. The only difference is that VM’s needs to be powered-off to use this migration method. Again you can compare this method to vSphere cold migration method.
Both of these migration methods consumes as much network bandwidth as it can to migrate the VMs. However you can set limits for bandwidth which HCX can consume during migration.
HCX Bulk Migration aka Low Downtime Migration
The main limitation with No-Downtime and Cold migration method is that in both method we can’t migrate VM’s in bulk. But don’t be disheartened because HCX Bulk Migration method gives you the ability to concurrently migrate multiple VMs to cloud.
Bulk migration method uses vSphere Replication host based replication. In this method, the running VM’s which you select for bulk migration are first replicated to cloud and initial sync is completed.
When full synchronization finishes, a delta synchronization occurs. Also in this method you specify a switch over time (to complete the replication process). When the delta synchronization finishes, a switch over is triggered and the on-premise VM’s are powered-off by HCX and the replicated VMs in cloud side are powered-on.
Although Bulk migration uses concepts of vSphere Replication, it’s not the regular DR replication. The main purpose here is to migrate VM’s to cloud and not replicate.
HCX Reverse Migration
Reverse Migration feature provides you the ability to migrate VMs from your cloud instance to your on-prem environment using the 3 migration methods which we discussed above.
And that’s it for this post. In next posts of this series, we will do a hands on the migration methods which we discussed in this post.
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.