This was me when I saw the Spotlight on the Move-VM Cmdlet including PowerCLI 6.5 Enhancements article as I spotted the new Move-VM native capabilities a couple months back.
Well, not a big loss, but I could have published my script and this article a few weeks back. ¯\_(ツ)_/¯
Cross-vCenter vMotion
So, what’s the big deal here? vSphere environments are typically organized into data centers and clusters. The datacenter object is the highest building block of a vCenter hierarchy, and the highest-level logical boundary representing a vMotion domain. Architects and engineers had to respect those vMotion domains to design their infrastructures before vSphere 6.0.
With vSphere 6.0, this limitation of restricting vMotion within a single vCenter was removed with the Cross vCenter vMotion feature. What was not very well known was that the same feature allows to vMotion a running VM between 2 different vCenters which do not belong to the same SSO domain. However, this is something not available with the GUI: William was the 1st to release a script allowing you to vMotion a VM between SSO domains, and his script was using the API.
PowerCLI Move-VM cmdlet
Starting from PowerCLI 6.5, the Move-VM cmdlet now supports natively Cross vCenter vMotion and the ability to vMotion VMs between vCenters (even if they are not part of the same SSO domain).
I created a simple PowerCLI script to demonstrate this new capability: Cross-SSO-vMotion-between-vCenters.ps1.
The script use the native Move-VM cmdlet capabilities to vMotion a running Virtual Machine between 2 vCenter Servers, independently if they belong to the same SSO domain or not. Also, a function determine the port group type and return the correct network object (removing the need to know if the distant port group is standard or distributed).
In the screenshot below, you can see the vMotion initiated from the script, migrating the web01 VM from my vc01-dc-a vCenter to the vc01-dc-b vCenter: vc01-dc-a belongs to ssodomain-a.local SSO domain, while vc01-dc-b belongs to ssodomain-b.local.
Here is the output of the script:
I have uploaded my script on GitHub with all associated information: Cross-SSO_vMotion.
Description
PowerCLI script to vMotion a running VM between two vCenters, even if they are not in the same SSO domain. The script will use the GetPortGroupObject() function to determine the portgroup type (standard or distributed) and return the correct object.
Enjoy!
Is this right:
At the Source the VM can be connected to a distributed vSwitch and at the destination the VM will connected to a standard vSwitch.
Because a vMotion from vDS -> vSS is not possible with the GUI.
Is this also within SSO Domains / single vCenter possible?
Hi Christian,
where did you get this sentence from? 🙂
VDS > VSS vMotion is indeed not supported, so not implemented in the GUI.
However, you should be able to do it with PowerCLI and the script I created, although still not supported.
And yes, you can do it even if it’s the same SSO domain. I haven’t tested it within the same vCenter but it should be working as the Move-VM cmdlet is not really ‘aware’ of vCenters, only for objects (vm, hosts, datastores, port groups).
Hello,
Just one question if I may, about EVC, does the vmotion can be done with the source cluster on a higher level of evc over the destination one?
Same requirements apply for a Cross-vCenter vMotion in terms of CPU feature set exposed to the VM.
So, you will have have to think about EVC baseline configuration for both source and destination.
Do you drop any pings while vmotioning between sso domains?
Hi Jammy.
The underlying task is still a regular vMotion, so expect to loose 1 or 2 pings during the vMotion (when the reverse ARP is sent).
Many thanks to you and William Lam for putting things like this together – the time and frustration is saves us minions is immeasurable! One thing I would like to mention is that, when the source and destination objects are named the same, the target vCenter to be specified when retrieving the objects from there so that script isn’t pulling the wrong (Source) information.
I had to add ‘-Server $DstvCenter’ (without ticks) to each Get* line that referenced the destination so that the script understood which object I was targeting. Without it, it kept erroring with:
Move-VM : 8/16/2017 8:52:32 AM Move-VM Different number of network adapters and portgroups specified. Please specify either a single portgroup to migrate all the network adapters to or the same number of network adapters and portgroups
At P:\PowerCLI\Complete\xMove-VM.ps1:71 char:7
+ $vm | Move-VM -Destination $destination -NetworkAdapter $networkAdapt …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (System.Collecti…oupBaseInterop]:List`1) [Move-VM], VimException
+ FullyQualifiedErrorId : Client20_VmHostServiceImpl_CheckMoveVmParameters_DifferentNumberNetworkAdaptersAndPortGr
oups,VMware.VimAutomation.ViCore.Cmdlets.Commands.MoveVM
Thx for you comment and feedback Alan! I will correct my script as soon as I find some quiet time.
So… different vCenters, different SSO domains. Does that still mean common vMotion network between both? Or can they be separate vMotion networks so long as they’re routable?
Nope, this is solved since vSphere 6.0 (as far as I remember): you can have routed vMotion.
i have error
Move-VM : Cannot convert ‘System.Object[]’ to the type
‘VMware.VimAutomation.ViCore.Types.V1.DatastoreManagement.StorageResource’
required by parameter ‘Datastore’. Specified method is not supported.
Hi there,
i have the same error msg, does anyone know why?. We are using VSAN in both sites A and B , is this compatible?
thank you.
Hey, Alan, can you tell me what lines you had to add -Server $DstvCenter to to get the script to not throw that error? I’ve been struggling for hours and cannot figure that out.
Thanks!
When i run the script, the migration fails at 39% with the error below
‘failed to migrate’ Cannot connect to host’
Quite strange since I have authenticated to both vCenter servers with full permissions
Is it possible to migrate VM from 6.0 to 6.5 with different SSO domain?
Yes, it’s possible. You can check the supported source and destination versions here: https://kb.vmware.com/s/article/2106952
Hi Romain
i read your script, but i have a couple of question:
– the variable $DstDatastore is needed only to check the availability of the datastore on second vCenter or this parameter permit the storage vMotion to the destination datastore?
I know this is a stupid question but actually i don’t need to relocate the storage but only migrate the compute resources of a VM.
– the VM ID of the virtual machine change after moving the VM to new vCenter or remain the same ID that exist on source vCenter? this is imporant because a full backup is required by Veeam if VMID change.
Many Thanks
Hi Alan Garner,
Can you share your piece of code which worked – with adding the -Server $DstvCenter ?
This is the script I use.
$srcVC =
$tarVC =
$vList = Get-Content -LiteralPath
$tarCluster =
$srcCon = Connect-VIServer -Server $srcVC -Credential $(Get-Credential)
$tarCon = Connect-VIServer -Server $tarVC -Credential $(Get-Credential)
$srcVDS = Get-VDSwitch -Server $srcCon
$tarVDS = Get-VDSwitch -Server $tarCon
ForEach ($vmname in $vList){
$vm = Get-VM $vmname -Server $srcCon
$vm | Get-CDDrive | Set-CDDrive -NoMedia -Confirm:$False | Out-Null
$vNic = Get-NetworkAdapter -VM $vm -Server $srcCon
$srcData = $vm | Get-Datastore
$tarData = Get-Datastore -Name $srcData.Name -Server $tarCon
$tarPG = Get-VDPortgroup -VDSwitch $tarVDS -Name $vNic.NetworkName -Server $tarCon
$tarHost = Get-Cluster -Name $tarCluster -Server $tarCon | Get-VMHost | Get-Random
Move-VM -VM $vm -Destination $tarHost -NetworkAdapter $vNic -PortGroup $tarPG -Datastore $tarData -VMotionPriority High -Confirm:$false -RunAsync
}
Some Caveats I have found include:
* Move-VM cmdlet can only target 1 datastore. VMs that spread across multiple datastores will fail. Ensure the target datastore has enough space for the entire VM.
* Using my code, the network names must be named the same on both source and destination vCenters. If they are not, modify the $tarPG accordingly.
* Using -RunAsync makes the migration go a whole lot faster
Hello Romain,
when I try to start the vmotion I get the following error:
The operation for the entity “xxx” failed with the following message: “The input arguments had entities that did not belong to the same
datacenter.
I need to migrate a VM to a different vCenter and also perform storage vmotion at the same time.