Automating Cross vCenter vMotion with PowerCLI (updated)

Recently the need to use Cross vCenter vMotion has become an everyday task. Moving clients into a cloud environment can be a exhausting task. Normally using VMware Converter does the trick, I still use this method for all Hyper-V to VMware conversions. As I learned more about the newer tools available to accomplish this task I decided to give them a shot.

First before we get too far in the weeds with the process, lets discuss the requirements for Cross vCenter vMotion;

To enable migration across vCenter Server instances, your environment must meet these requirements:

  • The source and destination vCenter Server instances and ESXi hosts must be running version 6.0 or later.
  • The cross vCenter Server and long distance vMotion features require an Enterprise Plus license.
  • When using the vSphere Web Client, both vCenter Server instances must be in Enhanced Linked Mode and must be in the same vCenter Single Sign-On domain so that the source vCenter Server can authenticate to the destination vCenter Server.
  • Both vCenter Server instances must be time-synchronized with each other for correct vCenter Single Sign-On token verification.
  • For migration of compute resources only, both vCenter Server instances must be connected to the shared virtual machine storage.
  • When using the vSphere APIs/SDK, both vCenter Server instances may exist in separate vSphere Single Sign-On domains. Additional parameters are required when performing a non-federated cross vCenter Server vMotion. The Move-VM cmdlet as of PowerCLI 6.5 supports both federated and non-federated Cross vCenter Server vMotion.

Here is a link to the VMware KB for more information.

Now that we have the requirements out of the way, lets dig in. After doing some research online I found a great tool on VMware code's website called PSxVCvMotion. I highly recommend this tool as I have used it several times. Here is a link to the download page.

I had a few issues with the way it works. I really didn't like the idea of putting my vCenter user and passwords in a config script along with all the details on the move. I decided to rewrite the script and make it a little more user friendly. First, be sure to have the powershell module Pester installed.

Install-Module Pester from powershell with administrator creds.

Instead of a config file to complete, the revised script will ask questions along the way to get the info it needs.

Once all the questions have been answered the script moves on to connecting to both vCenters. Next step it will complete a compatibility checks as the original script does. After the compatibility checks are complete and passed the next phase is to power off the VM that will be moving. For the moves that I have been doing the vCenters are not in the same SSO domain nor in Enhanced Linked Mode. With this condition the VM's will have to be powered off in order to move. Once powered off the move process begins. We are leveraging the Move-VM command to do the work for us. Here is the command used to accomplish the task:

Once the move is complete the VM is powered back on, there is a timer built into the script to give you the total migration time for the move. There is one final check to be sure that the VM comes back up, this is done by checking to be sure that vmtools comes back online. When that is complete and there are not any other VM's to move the script will disconnect from both vCenters.

I hope you find this revision of the PSxVCvMotion from VMware Code to be useful. I plan to add a few more features to this script. Want to add a tools version check and update to start with. I have the entire script out on my github to download if you want to give it a try. Check back for updates..

Update! -- I went ahead and updated the script and added the ability to update vmware tools and VM compatibility after the migration. then turned the script into a function. The github link above has the latest updates.