This post is also available in: Italian

As written in a previous post, the new VMware vSphere 6.0 introduce several enhancements in the vMotion by adding more VM mobility. If the long distance vMotion seems the big news, in my opinion the best and most amazing news is the cross vCenter vMotion (that could also be a long distance vMotion, but not necessary).

Moving a VM across vCenters seems a big challenge and bring new level of freedom in the VM… like the vMotion 1.0 it can liberate a VM from its boundaries: in vMotion 1.0 the boundary was the single host, now the boundary it’s potentially an entire datacenter!

As written in the previous post, there are several requirements in this kind of operation, expecially in the minum bandwidth and maxiumum latency. Also there are two different cases:

• Same SSO domain for destination vCenter Server: in this case it’s possible use the Web Client (or the CLI) just because you can see source and destination in the same inventory tree
• Different SSO domains: in this case each vCenter does not know about the other, but is still possible live move a VM, only using using API (see this post for an example with PowerCLI).

From my point of view the vMotion across two different infrastructures without any relationship is the most interesting and impressive (it’s possible in the RC, and I suppose that will be possible also in GA of vSphere 6.0, but I don’t know yet if it will be supported).

According with KB 2106952 (Cross vCenter vMotion requirements in VMware vSphere 6.0) seems that the single SSO domain (and the linked mode) is a requirement in GA!

You can use Willian Lam’s script with the right parameters described in his post: Did you know of an additional cool vMotion capability in vSphere 6.0?

I’ve only modified the script by adding few lines (in red in the relevant code portion) in order to specify also the destination folder (I just use the default one used to put “unknow” VMs), that seems required at least in the RC (and I suppose probably also in the GA):


# Source VM to migrate
$vm = Get-View (Get-VM -Server $sourceVCConn -Name $vmname) -Property Config.Hardware.Device
# Dest Datastore to migrate VM to
$datastore = (Get-Datastore -Server $destVCConn -Name $datastorename)
# Dest Cluster to migrate VM to
$cluster = (Get-Cluster -Server $destVCConn -Name $clustername)
# Dest ESXi host to migrate VM to
$vmhost = (Get-VMHost -Server $destVCConn -Name $vmhostname)
# Dest Folder to migrate VM to
$vmfolder = (Get-Folder -Server $destVCConn -Name "Discoved virtual machine")
...
# Relocate Spec for Migration
$spec = New-Object VMware.Vim.VirtualMachineRelocateSpec
$spec.datastore = $datastore.Id
$spec.host = $vmhost.Id
$spec.folder = $vmfolder.Id
$spec.pool = $cluster.ExtensionData.ResourcePool


I’ve got some curios issues (due to my faults) during the tests: VMware Tools are not required (it works also without them or with the service stopped), but if you are installing them and the VM is still in the phase with the menu “End VMware Tools installation” you cannot move the VM… if you try you have to power off the VM in order to clean the VMware Tools installation (was no more possible quit it from the menu).

Also remember that local resource may prevent the vMotion operation (like in all vMotion cases): be sure to put the CD/DVD in client setting, because also a disconnect ISO will stop the operation (on the WebClient you will notice a message about this aspect).

Also, but this is obvious, you need at least one vmkernel vMotion interface for each host. Remember that vMotion could be L3 now and that you can also specify a different TCP/IP stack for it.

On the other side, the VM network must still be a L2 network, for example by using a NSX Logical Network or some kind of L2 VPN.

About the possibility of virtual MAC address conflicts see also this post: Duplicate MAC Address concerns with xVC-vMotion in vSphere 6.0.

My wishes

This kind of vMotion could be the first step to bring some great and massive enhancements in the virtualization world.

Future evolution for sure will include the possibility to make the movement from the vSphere Web Client (or future version of the GUI client)… technically could be not so difficult.

But will be more interesting when will be possible do a vMotion between vCenter and vCloud Air (or between vCenter and vCloud).. this will give more freedom and permit to build a real hybrid cloud (for the IaaS level).

Of course will be not so easy to implement, but finding something to federate the resources of two virtual datacenter could be a way on how start… And the first brick (VM mobility) it’s already there!

By moving resource across private and public cloud there will be also the difficult on which baseline must be set… VMware EVC is really reach, but at this point maybe become more easy and simple implement a single baseline… or found a way to unsterstand an expose which CPU baseline is supported.

Finally a thought about one potential user case of this kind of migration: VMware call it “follow the sun” and could be use, for example to move VMs where workload are needed, or in coldest datacenters (in this case is a “follow the moon” approach :) )… Seems crazy and not so applicable. VM migration may need a lot a time… but what about if combining this kind of operation with vSphere Replication or Virtual Volumes (with storage replication) as a way to provide some checkpoints or a full replica of the VM in order to accelerate the VM transfert? In this case the required time could be reasonable… and could become possible and easy also live migrate an entire datacenter… Let’s see but a new revolution become now possible.

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.