vSphere 7 U1c – Advanced Cross vCenter vMotion
Just before the new year, VMware released an update to vSphere 7 Update 1 with the Update 1c variant. Usually these types of updates are released to address security concerns or to fix bugs and there isn’t usually any new features that could get you excited. This time, though, it is slightly different with the release of the Advanced Cross vCenter vMotion capability into the vCenter interface.
There is a great blog post on Advanced Cross vCenter vMotion available here: https://core.vmware.com/resource/introducing-advanced-cross-vcenter-server-vmotion-capability#section1
If you don’t want to go through that blog post, I’ve put together some of my own information below, along with some screenshots from the operation within my lab environment.
So, let’s talk about Advanced Cross vCenter vMotion (XVM) and what it is… well, this started its life as a fling but has now been embedded into the vSphere client with vSphere 7 U1c. The idea behind XVM is to help perform vMotion migrations of VMs without needing to utilise Enhanced Linked Mode or Hybrid Linked Mode… this means that you could save a lot of time and effort utilising this method to migrate VMs between vCenters without having to get them joined to the same Single Sign-On (SSO) domain. This tool also doesn’t just help with doing this on-prem, but can be used to migrate from on-prem to VMC on AWS for example.
You will notice that with the vSphere 7 U1c release, there is a release of both vCenter Server and ESXi… in my lab, I installed the updated vCenter Server element to take my first vCenter up to U1c but left my destination hosts sitting on vSphere 7 U1. From my source environment, this was configured with a vSphere 6.7 U3 environment… and, yes, this does allow for migrating from earlier versions of vSphere (from vSphere 6 upwards) to vSphere 7.
When you look into the XVM usage, there are actually two ways to utilise the capability… you can use the Migrate menu option as you would for a normal vMotion which would present you with a ‘Cross vCenter Server export’ option in the migration type menu. This is useful if you are migrating from an environment that is already running vSphere 7 U1c to another vCenter running the same version or later without having to join them to the same SSO domain.
The second option is to utilise the ‘Import VMs’ option in the menu from the destination vCenter – this vCenter must be running vSphere 7 U1c. Once you select this option, you can then enter the credentials of the source vCenter, and then select the VMs, networking, compute, storage, folder etc. that you would normally do when performing a vMotion of a VM to a different host and storage. Once you go through this wizard, you’ll see a migration bar appear on both of the vCenters as the VM is migrated. Please make sure that you already have vMotion working locally prior to attempting a XVM migration, as this will help to understand where issues may be if you have an XVM migration fail. The Import VMs option is what I have based my screenshots on below.
This is the source vCenter environment, just a single host running the vCenter server and a Windows 10 VM which will be the VM that is migrated. This vCenter environment is running vSpjhere 6.7 Update 3.
This is the destination vCenter environment. This has three hosts running vSAN and only has a single appliance VM running on it. This vCenter environment is running vSphere 7 Update 1c. It is from this destination vCenter environment that we’ll be performing the most of the migration process.
If we go to the context menu on the vCenter, we see the new option ‘Import VMs’, click this to start the migration process.
The first screen asks us to enter our source vCenter details, this must be a vCenter but you can save the vCenter details for later, if you wish. Click the Login button to confirm access to the vCenter and allow you to move onto the next screen.
If the vCenter hasn’t been seen before, you may be presented with this screenshot to confirm that you are connecting to the correct vCenter.
If you have connected successfully you should see something similar to above.
It’s now time to select the VM to migrate. On this occasion, I was only looking to migrate a single Windows 10 VM but you could migrate multiple VMs.
Select the compute location
Select the storage location
Select the folder to place the VM in.
Next select the network to connect the VM to.
Next select the migration priority.
Confirm your settings and click Finish to start the migration.
On the source environment, you’ll see the VM migrating.
On the destination environment, you’ll also see the VM migrating.
Once the migration completes, you’ll see the VM appear in the destination environment, and it will be removed from the source destination. During my test in my lab, I received one ping drop and one slightly longer ping response during the cutover of the VM to the destination… which wasn’t too bad considering the environments didn’t know anything about each other until I start this process.
I hope that this helps with your understanding of the new option.