VMware HCX for VM Migration - Extra

• 1: Task 14
• 2: Task 15
• 3: Task 16

1 - Task 14

HCX Replication Assisted vMotion (RAV) uses the HCX along with replication and vMotion technologies to provide large scale, parallel migrations with zero downtime.

HCX RAV provides the following benefits:

• Large-scale live mobility: Administrators can submit large sets of VMs for a live migration.
• Switchover window: With RAV, administrators can specify a switchover window.
• Continuous replication: Once a set of VMs is selected for migration, RAV does the initial syncing, and continues to replicate the delta changes until the switchover window is reached.
• Concurrency: With RAV, multiple VMs are replicated simultaneously. When the replication phase reaches the switchover window, a delta vMotion cycle is initiated to do a quick, live switchover. Live switchover happens serially.
• Resiliency: RAV migrations are resilient to latency and varied network and service conditions during the initial sync and continuous replication sync.
• Switchover larger sets of VMs with a smaller maintenance window: Large chunks of data synchronization by way of replication allow for smaller delta vMotion cycles, paving way for large numbers of VMs switching over in a maintenance window.

HCX RAV Documentation

Migrate a VM using HCX vMotion

As you are more comfortable now with HCX components, some steps will be less documented to provide you with the opportunity to discover new side of this tool by yourself.

Prerequisites

First thing, we need to check that Replication Assisted vMotion Migration feature is enabled on each of the following:

• AVS HCX Manager Compute Profile
• On premises Compute Profile
• On premises Service Mesh

For example:

If not enabled on one of the previous items, you need to:

1. Edit the component
2. Enable the Replication Assisted vMotion Migration capability
3. Continue the wizard up to the Finish button (no other change is required)
4. Click on Finish button to validate.

Note: Changes to the service mesh will require a few minutes to complete. You can look at Tasks tab to monitor the progress.

Exercise 1: Migrate VMs to AVS

Step 1: Initiate VMs migration

1. From the HCX interface click Migration in the left pane.
2. Click MIGRATE.

Step 2: Select VMs for Migration

1. Search for the location of your VM.
2. Click the checkbox to select your VM named Workload-X-Y-1 and Workload-X-Y-2.
3. Click ADD.

Step 3: Transfer and Placement of VM on Destination Site

Use the following values for these options:

Click either GO or VALIDATE button. Clicking VALIDATE will validate that the VM can be migrated (This will not migrate the VM). Clicking GO will both validate and migrate the VM.

Step 4: Monitor VM Migration

As you monitor the migration of your VM, keep an eye on the following areas:

1. Percentage status of VM migration.
2. Sequence of events as the migration occurs.
3. Cancel Migration button (do not use).

Step 5: Verify completion of VM Migration

Ensure your VM was successfully migrated. You can also check for the VM in your AVS vCenter to Ensure it was migrated.

Exercice 2: Migration rollback

Step 1: Reverse Migration with switchover scheduling

VMware HCX also supports Reverse Migration, migrating from AVS back to on-premises.

1. Click Reverse Migration checkbox.
2. Select the Discovered virtual machine folder.
3. Select your same virtual machines to migrate back to on-premises.
4. Click ADD.

Use the following values for these options:

The rest of the steps are similar to what you did on Step 5.

Step 2: Monitor a scheduled VM migration

After few minutes, Replication-assisted vMotion will start replicating virtual disks of the virtual machines to the destination.

When ready, the switchover will not happen before entering the maintenance window timeframe provided in the migration wizard. VM is still running on the source side. In the interval, replication will continue to synchronize disk changes to the target side.

When the switchover scheduling is reached, the VM computation runtime, storage and network attachments will switch to the destination and the migration will complete with no downtime for the VM.

Note: The switchover may not happen as soon as we reach the maintenance window timeframe: it may take a few minutes to start.

After the switchover is completed, VM should be running in the destination.

2 - Task 15

HCX L2 extended networks are virtual networks that span across different sites, allowing VMs to keep their IP addresses and network configuration when migrated or failed over.

HCX provides:

• HCX Network Extension: This service creates an overlay tunnel between the sites and bridges the L2 domains, enabling seamless communication and mobility of VMs.
• HCX Mobility Optimized Networking (MON): Improves network performance and reduces latency for virtual machines that have been migrated to the cloud on an extended L2 segment. MON provides these improvements by allowing more granular control of routing to and from those virtual machines in the cloud.

Observe the effects of extended L2 networks with and without MON

Prerequisites

Please migrate one of the workload VM to AVS side. You can select the migration method of your choice.

The VM needs to be migrated and powered-on to continue the Lab Task.

Assess the current routing path

From workstation, run a traceroute to get a view on current routing path.

From a windows command line, run: tracert IP_OF_MIGRATED_VM

Last network hop before the VM should be the On Prem routing device: 10.X.1Y.8.
Tracing route to 10.1.11.130 over a maximum of 30 hops
  1    23 ms    23 ms    22 ms  10.100.199.5
  2     *        *        *     Request timed out.
  3    23 ms    23 ms    23 ms  10.100.100.65
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     10.1.1.8    # <------- On Premises router
  7    25 ms    24 ms    24 ms  10.1.11.130 # <------- Migrated VM

Step 1: Enable Mobility Optimized Networking on existing network extension

From HCX console, select the Network Extension menu and expand the existing extended network.

Then activate the Mobility Optimized Networking button.

Accept the change by clicking on Enable when prompted for.

The change will take a few minutes to complete.

Step 4: Assess the current routing path after MON enablement

You can re-run a traceroute from jump server but no change to the routing path should be effective yet.

Step 5: Enable MON for the migrated VM

MON is effective at VM level, and so should be activated per VM (in an extended network where MON is already setup).

1. From the Network Extension, and the expanded MON-enabled network, select the migrated VM.
2. Select AVS side router location.
3. Click on Submit.

Step 6: Configure MON Policy routes

By default, MON redirect all the flow from the migrated VM to On Prem if they are matching RFC1918 subnets.

• In the Lab setup, this is also a reason for the migrated VM to be unreachable at this stage if we do not customize Policy Routes.
• In a real world scenario, not configuring Policy Routes, is often a reason of asymmetric traffic as incoming and outgoing traffic for/from the migrated VM could be not using the same path.

We will customize the Policy Routes to ensure that traffic for 10.0.0.0/8 will use the AVS side router location.

From the HCX console:

1. Select the Network Extension menu, then the Advanced menu and the Policy Routes item.
2. In the popup, remove the 10.0.0.0/8 network and validate the change.
3. Wait a minute for the change to propagate.

Step 7: Assess the current routing path after MON enablement at VM level

You can re-run a traceroute from workstation and analyze the result:

Tracing route to 10.1.11.130 over a maximum of 30 hops
  1    23 ms    23 ms    22 ms  10.100.199.5
  2     *        *        *     Request timed out.
  3    23 ms    23 ms    23 ms  10.100.100.65
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6    24 ms    23 ms    23 ms  10.1.11.130 # <------- Migrated VM

There should be no 10.X.1Y.8 (as last hop) anymore as flow is directly routed by NSX to the target AVS VM with the help of a /32 static route set by HCX at the NSX-T T1 GW level.

3 - Task 16

In a migration strategy, HCX L2 extended networks can be used to facilitate the transition of workloads from one site to another without changing their IP addresses or disrupting their connectivity. This can reduce the complexity and risks associated with reconfiguring applications, firewalls, DNS, and other network-dependent components.

Once a subnet is free from other resources On Premises, this is important to consider the last phase of the migration project: the network extension cutover.

This operation will provide a direct AVS connectivity for migrated workload, only relying on NSX-T components, and not anymore on the combination of HCX and On Premises network components.

In a large migration project, the cutover can be done network by network, based on the rhythm of workload migrations. When a subnet is free from On Premises resources, and firewall policies effective on AVS side, the cutover operation can be proceeded.

Achieving a migration project milestone by cutting-over network extension

Exercice 1: Perform a network extension cutting-over

Step 1: Migrate remaining workload to AVS

Ensure that all the On Premises workload attached to the extended network are migrated on AVS, except the router VM and the HCX-OnPrem-X-Y-NE-I1 appliance(s).

If not: migrate the VM to AVS.

Note: You can keep or remove MON on the extended network for the current exercice. It should not affect the end result.

Step 2: Start the network extension removal process

From HCX console, select the Network Extension menu. Select the Extended network and click on Unextend network.

In the next wizard, ensure that the Cloud Edge Gateway will be connected at the end of removal operation. Then submit.

You can proceed to the next step while the current operation is running.

Step 3: Shutdown On Premises network connectivity to the subnet

For the current lab setup, the On Premises connectivity to the migrated subnet is handled by a Static Route set on an NSX-T T1 gateway. We will remove this rule to simulate the end of BGP route advertising from On Premises.

On a real-world scenario, the change could be to shutdown a virtual interface on a router or a Firewall device to achieve the end of BGP route advertising for the subnet.

1. Connect to NSX-T Manager console by using credentials from AVS SDDC Azure UI.
2. Click on Networking tab, then Tier-1 Gateways section.
3. Select the TNTXX-T1 gateway and start the edition of the component.

4. From the edit pane, click on the Static Routes link to edit this section (the number will vary depending on the number of effectives routes).
5. Remove the route associated with your Lab based on its name and the target network.

6. Validate the change.
7. Monitor the process of the network extension removal on HCX.

Step 5: Network connectivity checks

When operation is ended, check the network connectivity to one of the migrated VM on the subnet.

You can use a ping from your workstation up to the VM IP address.

The connectivity should be ok.

Exercice 2: Rollback if needed!

Note: The following content is only there to provide guidance in case you need or choose to roll back the network setup to its previous configuration.

Step 1: Roll back changes

Running this step is not part of the Lab, except if you are facing issues.

If needed, network extension can be recreated, with same settings (especially the network prefix), and the route recreated to roll back a change.

To recreate the network extension, refer to the settings of Task 12.

If you need to recreate the static route on NSX-T, specify the following settings:

After the route re-creation, the connectivity via On Premises routing device should be restored to reach your workloads on the extended segment. You can roll back VM to On Premises too if needed.