HCX+ Virtual Machine Migration

If you’ve gone through the steps in my previous HCX+ posts, you should be at a point where you can test a VM migration.

There is a three-tier app running in Site A (Sofia in this example), with VMs whose names all start with “dist”. These VMs are all on NSX-backed segments that have been extended to the Cloud site (Cork in this example). I’m going to migrate one of the VMs in this app.

In the HCX+ UI, navigate to Services Mobility Operations.

Click on the New Mobility Group button.

Set the source and destination sites and give the Mobility Group a meaningful name.

Click the Next button.

Select a VM (or VMs) to be migrated.

Click the Next button.

You can expand each of the sections under Default Migration Options to fine-tune the configuration of the migration.

Theses settings were exactly what I wanted so I did not make any changes.

If you click the Advanced Mode toggle, you will see even more options that can be configured for individual VMs being migrated.

There is a Launch Helper button that you can click to get guidance on which options you might want to change for the migration.

In this example, I’m trying the guidance under the Scheduled, Live Parallel Migration, No Workload Changes option.

Clicking the Select button under the Use the recommended migration settings will result in no changes from what was seen previously. If you click the Select button under Customize migration settings, you will see a wizard that lest you make changes to the migration.

Click the Save button when you’re finished with the helper.

The last step is to configure the migration type and any transfer options.

These were what I wanted so I just clicked the Next button.

If everything looks good, click the Start Migration button. You could also click the Save button and then come back to finish the configuration later.

Click on the Migrations tab here to get more details on the active migration.

You should also be able to see activity around the migration in HSM UI from the Services Migration page.

And you should soon see the migration being started in the vSphere Client as well.

In the HCX+ UI, you can click the Events tab within the migration to see specific events related to the migration.

The progress of the migration should continue to move along.

The VM being migrated, dist-web-01, is still present at the source site.

But there is a fair amount of activity related to it’s migration being seen.

There will be a shadow VM created under the Mobility Agent host at the source site.

And at the destination site, there is a mule VM created that is receiving the replicated data from the source.

You should see activity around this VM in the Recent Tasks at the destination site.

Getting near the end, you’ll see a new VM created under the Mobility Agent host at the destination site.

In the HSM UI, you can see that the base sync is completed and the switchover is happening.

I was running a ping to the VM while this was happening and you can see a momentary spike in latency when the VM is actually switched over.

ping dist-web-01
PING dist-web-01.corp.vmw (172.31.3.2) 56(84) bytes of data.
64 bytes from dist-web-01.corp.vmw (172.31.3.2): icmp_seq=40 ttl=63 time=4.07 ms
64 bytes from dist-web-01.corp.vmw (172.31.3.2): icmp_seq=41 ttl=63 time=4.90 ms
64 bytes from dist-web-01.corp.vmw (172.31.3.2): icmp_seq=46 ttl=63 time=612 ms
64 bytes from dist-web-01.corp.vmw (172.31.3.2): icmp_seq=47 ttl=63 time=10.2 ms
64 bytes from dist-web-01.corp.vmw (172.31.3.2): icmp_seq=48 ttl=63 time=8.92 ms

It is also worth noting that the latency went up from an average of about 4-5ms to 9-12ms. This is due to the extra hops involved with traversing the tunnel created by the NE VMs at each site.

At the destination site, you should see that the VM is up and running under the appropriate cluster.

And at the source site, the VM is no longer present.

The task is almost done in the HCX+ UI.

And in a very short time, it is completed.

The HSM UI shows that the migration is complete as well.

This migration can be reversed by simply flipping the source and destination sites in a new Mobility Group.

Leave a Comment

Your email address will not be published. Required fields are marked *