In 2019 I’ve started a series of articles around HCX. This is part 3 of my series of posts on HCX on VMConAWS. In part 1 I had a first look at HCX, in part 2 I talked about the L2 Network Extension capability of HCX. In part 3, this article, we will have a closer look at the migration capabilities of HCX.

With HCX workloads can be migrated bi-directionally between the on-premises datacenter and VMware Cloud on AWS (VMConAWS). In case you’re using HCX in an on-premises scenario, you can (of course) migrate workloads between the datacenters. I will focus on the VMConAWS use-case in this article.

When it comes to migration there are various scenarios HCX supports:

1. HCX Cold Migration
2. HCX vMotion
3. HCX Bulk Migration
4. HCX Replication Assisted vMotion
5. HCX OS Assisted Migration (OSAM)

The HCX Interconnect Appliance (HCX-IX) is the virtual appliance provides replication and vMotion-based migration capabilities. You can do migrations through internet and private lines. Check out to architecture diagram on the right that provides more information on the HCX-IX appliance and network flows it leverages. Notice that the OSAM migration option requires some extra virtual appliances.

Let’s have a look at the different types of migrations introduced earlier.

HCX Cold Migration and vMotion

From a HCX perspective the Cold Migration option is kind of the same as the vMotion migration option, the only difference is that the VM is either powered-on or off. The same requirements apply for both a vMotion and Cold Migration, the most important requirements are:

• HCX Interconnect Tunnels must be up/active;
• Virtual RDMs can be part of the migration, VMs must be at least version 9 or higher.
• HCX vMotion requires 100 Mbps bandwidth (note: a regular vMotion between on-premises and VMConAWS requires 250 Mbps of bandwidth);

Check out the full list of requirements and restrictions here. A vMotion based migration uses the vMotion protocol, while a cold migration uses the VMware NFC (Network File Copy) protocol.

The HCX Cold Migration and vMotion is under the Migration menu option in the HCX dashboard, and through the context menu of a VM under HCX actions. The default Migrate option in the VM context menu of vSphere is a regular (non HCX) migrate action. A regular migrate action requires a VPN/Direct Connect connection to VMConAWS.

Depending on wether the VM is powered on or off you’re performing a Cold Migration or vMotion action. The HCX migration window allows you to configure different settings:

In the Transfer and Placement pain you set the general settings for the migration, which is (in this case) of type vMotion. You can deviate from these general settings and set a specific migration configuration per VM. By default the VM will be connected to the L2 Extended Network at the other side, but you can select another network if that’s required.

You have the option to configure a couple of Extended Options, including: Retain MAC, upgrade VM hardware/VMware Tools, disable per-VM EVC, upload a personalisation script, DNS customisation and/or Generate a new Security Identifier. Notice that by default with vMotion migration the VM will retain its MAC and IP address.

HCX Bulk Migration

HCX Bulk Migration uses host-based replication (vSphere Replication) to move the VM and its data to another datacenter/VMConAWS. The difference with a vMotion based migration is that there’s some downtime involved here. Key is that a Bulk Migration starts with a full sync of VM data, when this full sync finishes a delta sync occurs. After this delta sync finishes, a switchover is triggered or you have the option to schedule the switchover (until a specific time, e.g. a maintenance window).

During the switchover the original VM is powered off, and the migrated replica is powered on. The original VM is renamed, so in the case there’s a problem with the replicated VM you can always power up the original VM. Removal of the original VM, after a migration, is a manual process. The detailed process is explained here.

Select the VMs you want to migrate:

Click Finish, and your migration is starting:

It’s as easy as that! Notice that there’s no specific order in the migration, and that multiple migrations will run simultaneously. Remember that you remove the copied VMs at the original location after you’ve verified that everything is up and running in the other datacenter, in this case VMConAWS.

HCX Replication Assisted vMotion

The third migration option is a Replication Assisted vMotion, or RAV. With RAV you’re leveraging a combination of vSphere Replication and vMotion technology. vSphere Replication is used to replicate the data to the other side, during the switchover window a vMotion occurs: the VM is seamlessly migrated to the other datacenter.

Just select the option “Replication assisted vMotion” to get started:

After the Finish button is clicked, the migration commences:

First the replication will be completed, after that a continuous synchronisation cycle will start until the (vMotion based) switchover is triggered. You can trigger the switchover immediately following the sync, or schedule a specific switchover window. After the switchover the original VM will be removed and the VM will continue running at the new location.

Full details are enclosed here.

HCX OS Assisted Migration

The last migration option is a HCX OS Assisted Migration (OSAM). In this scenario a Guest OS component is leveraged, the so called Sentinel software. The Sentinel software gathers the system configuration and assists with the data migration.

OSAM also requires a HCX Sentinel Gateway (source site) and Receiver (target site). These two appliances are responsible for the data replication between the sites. Each VM to be migrated requires the Sentinel Guest Agent to be installed. The OSAM migration option allows you to migrate Hyper-V and KVM based virtual machines. The supported OS versions are detailed in the following table:

Currently VMConAWS doesn’t support the OSAM migration option, however it’s something that will be added to the service according to the VMConAWS roadmap:

That’s it for the migration part of HCX. In part 4 of these series we will look at the Disaster Recovery options HCX provides. Stay tuned!