5 Core Requirements for Cross vCenter Migrations

For this post, I wanted to put together a few tips on cross vCenter migrations. We’ve got a few posts on vMotion already but none on cross vCenter migrations. Cross vCenter migrations were introduced in vSphere 6.0 and they allow virtual machines to be moved from one vCenter Server instance to another. You can change compute, network, storage, and management all in one concurrent move. Now, we also have to keep in mind that the hosts must meet the same CPU compatibility standards. So AMD to Intel chips are a no-go. All of the old boundaries we used to have are no longer an issue. The days of being locked into one vCenter are long gone. You might consider these types of migrations for things like disaster recovery, VMware Site Recovery Manager, Multisite load balancing or follow the sun scenario support.

There are some requirements for long-distance vMotion as well that we need to address first.

• Virtual machine network:
  • L2 connection.
  • Same virtual machine IP address available at the destination.

• vSphere vMotion network:
  • L3 connection.
  • Secure (recommended if not using vSphere 6.5 or later encrypted vSphere vMotion).
  • 250 Mbps per vSphere vMotion operation.
  • The round-trip time between hosts can take up to 150 milliseconds.

Let’s outline a few tips for a successful cross vCenter migration.

Tip #1

The source and destination vCenter and ESXi hosts must be running at least vSphere 6.0 or later. vSphere 5.5 is not supported. Prior to 6.0, you had to shut VMs down and export/re-import manually. All of your environments must be upgraded to at least 6.0. It’s also recommended that if you upgrade from 6.0 to 6.5, or 6.5 to 6.7, that you upgrade the other side of the environment to that same version as well.

Tip #2

Use an Enterprise Plus license. It’s not going to work without it. The cross vCenter Server and long-distance vMotion features require an Enterprise Plus license, so be sure both source and destination environments are licensed properly. If you’re in the process of upgrading your environment, I would highly consider upgrading your licensing scheme to allow for this feature.

Tip #3

Both vCenter Server instances must be in Enhanced Linked Mode and must be in the same vCenter Single Sign-On domain to migrate VMs using the vSphere Web Client. This is because the source vCenter must be able to authenticate to the destination vCenter. For a deep dive on what linked mode, is, I highly recommend you check out this other post we’ve written.

Tip #4

Both vCenter Server instances must be time-synchronized with each other for correct vCenter Single Sign-On token verification. Functional NTP is critical for this feature to work! You can check under each host configuration tab or use the Get-VMHostNTPServer PowerCLI cmdlet.

Tip #5

To migrate VMs between vCenter Server instances in separate vSphere Single Sign-On domains, you need to use vSphere APIs/SDK to migration. However, if you are using PowerCLI 6.5 or newer, the Move-VM cmdlet will support both federated and non-federated cross vCenter migrations.

You can check out our PowerCLI video, hosted by Andy Syrewicze below. If you’ve got some extra time, our YouTube channel is full of great videos.

Network compatibility checks:

When you do decide to kick off across vCenter migration, vCenter Server performs network compatibility checks to prevent the following configuration problems:

Network Checks performed:

• MAC address compatibility on the destination host. vCenter randomly generates MAC addresses so there is a slight chance you might run into a duplicate. It verifies this first.
• vMotion from a distributed switch to a standard switch. There are different features and moving from one to the other might remove some of those features.
• vMotion between distributed switches of different versions. Similar to above, different dvSwitch versions have different features, so a check is needed.
• vMotion to an internal network, for example, a network without a physical NIC. This is mostly a facepalm moment. It checks to make sure you are not taking a functional network adapter and moving it to a destination network that will force the virtual machine offline.
• vMotion to a distributed switch that is not working properly.

Check out the Cross vCenter Workload Migration Utility

First and foremost, this is a VMware Fling, so it’s not officially supported. Tread lightly if your environment is picky about that stuff. Now with that out of the way, this is a nice GUI front end that allows you to easily migrate machines in bulk. They have a demo video out on YouTube that I’ve embedded. It demonstrates the functionality.

Supported Operations

• Perform live/cold migration as well as relocate/clone operations
• Works for migration tasks within and across vCenter servers
• Select host/cluster/folder/resource pool as placement target
• Supports both storage vMotion and shared datastore migration
• Flexible configuration for VMs with multiple network interfaces

Wrap Up

This function is something we’ve all been waiting for but you do have to meet the above requirements in order to be successful with it. The above migration Fling does make life easier but it’s not required. I honestly don’t get the chance to do cross vCenter migrations daily, so it’s more of a novelty for me, but the more and more we move into cloud situations this will become all the more useful.