VMware HCX Migration Methods

In my last post, I provided a quick component-level overview of VMware Hybrid Cloud Extension (HCX). I also discussed how to deploy each component to securely connect your on-premises vSphere infrastructure to VMware vCenter Server or VMware Cloud Foundation instance within the IBM Cloud. In this post, I explain the three main HCX migration methods that you can use to migrate to–and from–the IBM Cloud.

HCX Migration and Application Connections

HCX No-Downtime & Cold Migration

The first set of migration methods includes No-Downtime (i.e., Cross-cloud vMotion) and Cold migration. As you know, vMotion transfers a live, powered-on virtual machine between datacenters, clusters, or hosts without downtime. Cold migration performs the same function, however, the virtual machine is in a powered-off state. For each of these migration methods, HCX consumes as much network bandwidth as it can to transfer the VMs (you can set limits if needed). Additionally, No-Downtime & Cold migration transfers a single virtual machine at one time. For example, if you plan to transfer 100 VMs, HCX will transfer each of these machines in a serial fashion; one transfer at a time. So while this method gives you the ability to rapidly migrate a VM, it doesn’t provide you with a decent mechanism to migrate VMs in bulk. That brings us to bulk migration…

HCX Bulk Migration

In addition to No-Downtime and Cold migration, HCX gives you the ability to concurrently migrate multiple VMs using replication. When using replication, you select the VMs to migrate in bulk and specify a date and time in which to complete the replication process. When the replication is complete, HCX will power-off the virtual machines on the source side. Subsequently, HCX will power-on the replicated VMs residing on the IBM Cloud. Please note that bulk replication is different from a disaster-recovery-type replication. The purpose is to migrate, not replicate VM deltas to support eventual failover.

There are two important items to note:

HCX will rename the virtual machine on the source side after it has been migrated and powered off. This is done so you can quickly revert to the original VM. This is useful in case the migrated VM isn’t performing well or doesn’t pass user experience tests in the cloud environment.

HCX will designate the migration task as failed if bulk migration does not complete within the allotted time frame. If you wish to retry the migration using replication, you must restart the bulk migration process. One mitigation strategy would be to increase the migration time frame.

HCX Reverse Migration

Before I wrap-up this post, I want to briefly discuss the reverse migration feature available with HCX. This feature provides you the ability to migrate VMs from your cloud environment to your on-premises environment using No-Downtime, Cold, and Bulk migration methods. This could be useful for situations in which you determine a transferred VM–or set of VMs–isn’t suitable for the cloud. As an example, I had a customer migrate a database and encounter higher-than-expected write latency. To mitigate, we simply migrated the database back to on-prem using the reverse migration feature. I’d also argue this feature prevents cloud-vendor lock-in.

Next Up…

That does it for this post. I’ll dedicate my next post to the HCX migration workflows associated with each migration method. I’ll also provide UI screenshots and detail all the options you can select before starting a migration. Thanks for reading!