Introducing the Advanced Cross vCenter Server vMotion Capability
Overview
The Advanced Cross vCenter Server vMotion (XVM) capability was one of the most popular VMware Flings. A lot of customers were anxious to see this capability being an integrated part of vSphere. With the vSphere 7 Update 1c release, the XVM capability is embedded into the vSphere Client!
XVM helps to migrate virtual workloads between vCenter Server instances, without the requirement for Enhanced Linked Mode (ELM) or Hybrid Linked Mode (HLM). This means it’s possible to migrate virtual machines (VMs) between vCenter Servers that are in different Single Sign-On (SSO) domains.
A common scenario of this is workload migrations from an on-prem vSphere infrastructure to VMware Cloud on AWS. Migrating without being constrained by vCenter Server configurations allows for a lot of migration ‘freedom’. XVM can be used for single VMs or bulk migrations.
From within the vSphere Client, two workflows are available to migrate workloads between vCenter Servers. Either using the ‘import VMs’ option in the Hosts and Cluster view to import VMs from a target vCenter Server Appliance (VCSA), or by selecting VMs and opt for ‘Migrate’ in the menu.
Cross vCenter Server Export
Like with a regular manual vMotion operations, you can select the ‘Migrate’ option for one or multiple VMs. Next to the familiar options to change the compute resource, and/or the storage location for that VM, there’s a new option listed. Choose the new ‘Cross vCenter Server export’ option to use the XVM functionality.
The same known options for the live migration operations apply, with an extra configurable that is the target vCenter Server instance.
This is where you configure the target vCenter Server. Either a new vCenter Server is connected, or a saved connection is chosen in the same user-session. Saved vCenter Server entries are not persisted but retained only for the current user session. This is particularly convenient when you need to execute multiple migration operations.
The other wizard options are similar to compute resource and storage vMotion tasks. Selecting the compute resource lists the target vCenter Server datacenters, clusters, and hosts. With XVM integrated into the vSphere Client, the compatibility checks are processed with each step to ensure a successful migration.
During this wizard, you’ll have the ability to select the correct destination storage. It might be necessary to change the VM(s) networks to match the target configuration. Once everything checks out and the appropriate resources are selected, the migration is ready to kick off.
Because the live-migration is happening over multiple vCenter Servers, you’ll see the vMotion in process in the current environment as well as a vMotion receive tasks in the target vCenter Server instance.
The Importing VMs Option
The menu on a cluster or host level provides the new option to ‘Import VMs’. Selecting this option opens a wizard to walk you through the import process.
To import VMs from a remote vCenter Server, the source vCenter Server needs to be connected. The option to save the vCenter Server address helps with future migrations as you can just select previous saved vCenter Server instances.
After successfully logging in to the remote vCenter Server, the migration batch is further configured. Either one VM or multiple VMs can be selected and migrated in one go.
The rest of the wizard is similar to the Migrate option with XVM, as shown in the previous chapter.
Use-cases
The ability to bulk-migrate workloads between vCenter Server instances, without constraints on their configuration from an SSO perspective, is a powerful tool in moving workloads between vSphere environments. When connectivity between the source and destination vCenter Server instances is set up correctly, there are a ton of use-cases where the XVM capability helps! Think about the following use-cases;
- Migrate VMs from an on-prem vSphere environment to VMware Cloud on AWS without the need for Hybrid Linked Mode (HLM) and additional configuration.
- Adoption of new vSphere versions by migrating all workloads from old vCenter Server instances.
- Workload migration as part of the VCF upgrade.
- Datacenter consolidation and colo evacuation.
- Retire legacy hardware which usually would include old vSphere versions.
- Workload re-balance over global VCF environments.
- Migrate to a VMware Cloud offering.