This weekend i was playing around in my home lab and wanted to try the Cross vCenter vMotion functionality to a vCenter server in a different SSO domain with an identical SSO domain name.

Source:
vcenter.wesleygeelhoed.local (SSO DomainA: vsphere.local) (vCenter 6.5 U1)
Destination:
vcenter2.wge.corp (SSO DomainB: vsphere.local) (vCenter 6.5 U1)

As you can see the names of the SSO domains are identically, but in fact they are really two different SSO domains with each having their own VCSA with embedded PSC.

*the two vCenter instances are having a L3 connection over an IPsec VPN 

The script that I used with PowerCLI:

####################################################################################
# Variables
####################################################################################
# vCenter Source Details (SSO Domain A)
$SrcvCenter = ‘vcenter.wesleygeelhoed.local’
$SrcvCenterUserName = ‘administrator@vsphere.local’
$SrcvCenterPassword = ‘*********’

# vCenter Destination Details (SSO Domain B)
$DstvCenter = ‘vcenter2.wge.corp’
$DstvCenterUserName = ‘administrator@vsphere.local’
$DstvCenterPassword = ‘*********’

# vMotion Details
$vmToMigrate = ‘SRVCTX01’ # The VM Name to migrate
$DstDatastore = ‘ESX03-SSD’ # The destination datastore
$DstCluster = ‘DR’ # The destination cluster
$DstPortGroup = ‘vxw-dvs-18-universalwire-12-sid-10002-VXLAN’ # The port group or distributed port group.

####################################################################################
# Function GetPortGroupObject
function GetPortGroupObject {
Param(
[Parameter(Mandatory=$True)]
[string]$PortGroup
)

if (Get-VDPortGroup -Name $DstPortGroup -ErrorAction SilentlyContinue) {
return Get-VDPortGroup -Name $DstPortGroup
}
else {
if (Get-VirtualPortGroup -Name $DstPortGroup -ErrorAction SilentlyContinue) {
return Get-VirtualPortGroup -Name $DstPortGroup
}
else {
Write-Host “The PorGroup ‘$DstPortGroup’ doesn’t exist in the destination vCenter”
exit
}
}
}

function Drawline {
for($i=0; $i -lt (get-host).ui.rawui.buffersize.width; $i++) {write-host -nonewline -foregroundcolor cyan “-“}
}

####################################################################################
# Connect to vCenter Servers
Connect-ViServer -Server $SrcvCenter -User $SrcvCenterUserName -Password $SrcvCenterPassword -WarningAction Ignore | out-null
write-Host -foregroundcolor Yellow “`nConnected to Source vCenter…”
Connect-ViServer -Server $DstvCenter -User $DstvCenterUserName -Password $DstvCenterPassword -WarningAction Ignore | out-null
write-Host -foregroundcolor Yellow “Connected to Destination vCenter…”

####################################################################################
# vMotion 🙂
$vm = Get-VM $vmToMigrate
$destination = Get-VMHost -Location $DstCluster | Select-Object -First 1
$networkAdapter = Get-NetworkAdapter -VM $vmToMigrate
$destinationPortGroup = GetPortGroupObject -PortGroup $DstPortGroup
$destinationDatastore = Get-Datastore $DstDatastore

$vm | Move-VM -Destination $destination -NetworkAdapter $networkAdapter -PortGroup $destinationPortGroup -Datastore $destinationDatastore | out-null

####################################################################################
# Display VM information after vMotion
write-host -foregroundcolor Cyan “`nVM is now running on:”
Drawline
Get-VM $vmToMigrate | Get-NetworkAdapter | Select-Object @{N=”VM Name”;E={$_.Parent.Name}},@{N=”Cluster”;E={Get-Cluster -VM $_.Parent}},@{N=”ESXi Host”;E={Get-VMHost -VM $_.Parent}},@{N=”Datastore”;E={Get-Datastore -VM $_.Parent}},@{N=”Network”;E={$_.NetworkName}} | Format-List

####################################################################################
# Disconnect
Disconnect-VIServer -Server * -Force -Confirm:$false

Executing script from the Powershell command prompt, no issues or warnings appear.

Normal tasks are created as expected in the source and destination vCenter server.

After some minutes the task was completed successfully and the VM was running normal and smooth in the same VXLAN network on the destination vCenter Server.

Many blog posts already exists on the internet about this topic, but mainly focused on SSO domains with different names. I just wanted to test if some weird behavior would appear if you used the same SSO domain names. And the answer is; no. The migration went as smooth as an internal vMotion.

Source: CloudManiac