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).