When to use Move-VM cmdlet vs xMove.ps1 script for performing Cross vCenter vMotions?

Since publishing my Automating Cross vCenter vMotion between the same and different SSO Domain article back in early 2016, I have had a large number of customers reach out to me and share their success stories of allowing them to perform datacenter migrations to consolidating vCenter Servers all due to this awesome capability that was introduced in vSphere 6.0. In fact, many of the VM migration numbers were in the 4,000 to 8,000+ range which completely blew me away. It was great to hear from customers on how the xMoveVM.ps1 script had enabled them to do things that was simply not possible before, especially without impacting their workloads.

I still get pinged on a regular basis from customers about using my script and one thing that surprises many customers when I mention to them that this functionality has already been ported over to the native Move-VM cmdlet that was introduced with the PowerCLI 6.5 release. This had always been my original intention to provide an example using our vSphere API and enabling our customers in the short term and working with Alan Renouf and the PowerCLI team to get this folded back into the official PowerCLI cmdlets. This means, you no longer have to use my script for basic Cross vCenter vMotions whether that is between the same or different SSO Domain, which is quite nice as the number of user inputs is significantly reduced by using Move-VM cmdlet.

UPDATE (01/01/2018) - One additional option is the recently released Cross vCenter vMotion Utility Fling. For more details, please have a look at the blog post here.

Lets take a look at an example below where I have a VM called TestVM-1 which is residing in vcenter65-1 and I want to vMotion it to vcenter65-3:

With just 5 simple and easy to read lines of PowerCLI, you can perform this operation:

$sourceVC = Connect-VIServer -Server vcenter65-1 -User *protected email* -Password VMware1!
$targetVC = Connect-VIServer -Server vcenter65-3 -User *protected email* -Password VMware1!
$vmhost = "172.30.0.174"
$vm = Get-VM -Server $sourceVC "TestVM-1"

Move-VM -VM $vm -VMotionPriority High -Destination (Get-VMhost -Server $targetVC -Name $vmhost) -Datastore (Get-Datastore -Server $targetVC -Name iSCSI-01)

Now, having said that ... there is one use case in which I would still recommend my xMove-VM.ps1 script over the Move-VM cmdlet, which is a VM that has multiple VMDKs AND you wish to ONLY perform what is known as a Compute-only Cross vCenter vMotion. This is to say, that you are only migrating the running state of the VM between vCenter Servers as the underlying storage is shared and available across both vCenter Servers. Below is a screenshot of a VM called TestVM-2 which has two VMDKs stored respectively on datastore iSCSI-01 and iSCSI-02 running on vcenter65-1 and we wish to relocate it to vcenter65-2 which you can also see has both those datastores available.

Today, there is a limitation with the Move-VM cmdlet for a compute-only Cross vCenter vMotion where VMDKs stored across different datastores will actually be relocated to a single datastore after performing the migration. It is possible to override this behavior via the vSphere API which my xMove-VM.ps1 supports by simply enabling setting the $xvcType property to 1. The script makes use of the granular VirtualMachineRelocateSpecDiskLocator which allows you to specify the location for individual disks which you can have a look here for the specific implementation supporting this use case. Hopefully the PowerCLI team will consider this enhancement in the future and to help with that, I have also filed the following PowerCLI Feature Request here. If you wish to see this functionality get added to Move-VM cmdlet, feel free to vote it up!

In summary, if you are looking for a quick and easy way to automate Cross vCenter vMotions, just update to the latest PowerCLI release and you can simply use the built-in Move-VM cmdlet. Not only is it super easy to use, but its fully supported by VMware. For compute-only Cross vCenter vMotion, you can continue using my script and hopefully we will get this gap closed in the future.

Additional Resources:

• Cross vCenter Server operations (clone / migrate) between versions of vSphere 6.x