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.
Hi William, can this be used to "consolidate" a vCenter with external PSC to a (new) vCenter with embedded PSC?
My idea is to use a cross-vCenter vMotion to migrate from a Windows based vCenter to a vCenter appliance AND consolidate to an embedded PSC configuration at the same time. Thank you. Matteo
William Lam says
Absolutely. In fact, check our VMworld session we did this year SER2958BU https://github.com/lamw/vmworld2017-session-urls/blob/master/vmworld-us-playback-urls.md for more details 🙂
Thanks for bringing my attention to the Move-VM Cmdlet, I have been using your xMove-VM script/ for a few months now and have been working a treat!
I'm not having much luck with the Move-VM cmdlet though, getting the error "A general system error occurred: Host not found (non-authoritative), try again later". Any ideas as to why it might not be able to find the host? I can get it to work in the GUI and with the xMove-VM script.
Sorry - worked it out. Had to also pass the -Server parameter to the Move-VM cmdlet aswell, even though I was passing it when getting the destination variables. Thanks again for all the content you put out mate!
Can the PowerCLI 6.5 Move-VM commandlet be used to do a xVC-vMotion between two 6.0U3 vCenters (no linked mode)?
William Lam says
I keep getting this error "A general system error occurred: Host not found (authoritative)"
I'm moving a VM from 6.0 U3 to 6.5 U1.
I had the same error, which threw me for a loop because the exact same code worked the day prior. What I found was that specifying the FQDN of the vCenter Server in the objects created by the Connect-VIServer cmdlets allowed Move-VM to successfully migrate the FM to the other vCenter. Using the short hostname of the vCenter Servers resulted in the "Host Not Found (authoritative)" error for me.
Hi, can we point this to a datastore cluster?
William Lam says
No, you need to specify a specific Datastore Cluster as the underlying API does have support for Datastore Cluster. You can always write some additional logic to query a Datastore Cluster and retrieve the recommended Datastore to then feed the xVC-vMotion API (however, I'll leave that as an exercise to the reader). You can refer to this article https://www.williamlam.com/2012/03/vm-provisioning-on-datastore-clusters.html for more details
This is awesome, thanks William. We stood up a new VC and I have to move a ton of VMs that would take advantage of a "compute-only" vmotion. Surprised this hasn't found it's way into the product yet. A checkbox in the migration wizard that says "compute only" sounds fitting. Thanks again!