Automating Cross vCenter vMotion (xVC-vMotion) between the same & different SSO Domain

In the last couple of months, I have noticed an increase in customer interests in using the Cross vCenter vMotion (xVC-vMotion) capability that was introduced back in vSphere 6.0. In my opinion, I still think this is probably one of the coolest features of that release. There is no longer the limitation of restricting your Virtual Machine mobility from within a single vCenter Server, but you can now live migrate a running VM across different vCenter Servers.

The primary method to start a xVC-vMotion is by using the vSphere Web Client which requires your vCenter Servers Servers to be part of the same SSO Domain and will automatically enable the new Enhanced Linked Mode (ELM) feature. ELM allows you to easily manage and view all of your vCenter Servers from within the vSphere Web Client as shown in the example screenshot below.

However, the vSphere Web Client is not the only way to start a xVC-vMotion, you can also automate it through the use of the vSphere API. In fact, there is even an "Extended" capability of xVC-vMotion that is not very well known which I have written about here which allows to live migrate a running VM across two different vCenter Servers that are NOT part of the same SSO Domain. This Extended xVC-vMotion (unofficially I am calling it ExVC-vMotion) is only available when using the vSphere API as the vSphere Web Client is unable to display vCenter Servers that are part of another SSO Domain. Below is a quick diagram to help illustrate the point in which VM1 can be seamlessly migrated between different vCenter Servers from within the same SSO Domain as well as between different vCenter Servers that are not part of the same SSO Domain.

Note: For additional details and requirements for Cross vCenter vMotion, please have a look at this VMware KB 210695 and this blog post here for more information.

UPDATE (06/15/17) - I have added a few minor enhancements to the script to support migrating a VM given a vSphere Resource Pool which enables the ability to migrate to and from VMware's upcoming VMware Cloud on AWS (VMC). There is also an additional UppercaseUUID parameter which seems to be required for some xVC-vMotions where the vCenter Server's InstanceUUID must be provided as all upper case or the operation will fail. I have still not identified why this is needed for some migrations, but for now there is a nice flag that can be used to enable this if you are hitting this problem.

UPDATE (04/08/17) - In vSphere 6.0 Update 2, there is a known limitation which prevents a VM that has multiple VMDKs stored across different datastores to be xVC-vMotion (compute only) using the vSphere Web Client. This limitation no longer exists in vSphere 6.0 Update 3 but does require customers to upgrade. If you need to perform a compute-only xVC-vMotion where the VM has multiple VMDKs across different datastores, the vSphere APIs does not have this limitation and you do not necessary need to upgrade to be able to perform this operation. Huge thanks to Askar Kopayev who discovered this and also submitted an enhancement to my xMove-VM PowerCLI script to support this functionality.

Given the amount of interest recently and some of the feedback on my original ExVC-vMotion script which I had written about here, I figured it was time to refactor my code so that it could easily support both ExVC-vMotion as well as standard xVC-vMotion. In addition, I have also added support for migrating to and from a Distributed Virtual Switch (VDS), where as previously the example only supported Virtual Standard Switch (VSS). Lastly, the script now also supports migrating a VM that is configured with multiple vNICs.

The new script is now called xMove-VM.ps1 and is even more simpler than my original script. You will need to edit the script and update the following variables:

Variable

Description

vmname

Name of the VM to migrate

sourceVC

The hostname or IP Address of the source vCenter Server in which the VM currently resides in

sourceVCUsername

Username to the Source vCenter Server

sourceVCPassword

Password to the Source vCenter Server

destVC

The hostname or IP Address of the Destination vCenter Server in which to migrate the VM to

destVCUsername

Username to the Destination vCenter Server

destVCpassword

Password to the Destination vCenter server

datastore

Name of the vSphere Datastore to migrate the VM to

cluster

Name of the vSphere Cluster to migrate the VM to

resourcepool

Name of the vSphere Resource Pool to migrate the VM to

vmhost

Name of the ESXi host to migrate the VM to

vmnetworks

Name of the vSphere Network(s). in the order in of the vNIC interfaces to migrate the VM to

switch

Name of the vSphere Switch to migrate the VM to that is comma separated and ordered by vNIC

switchtype

The type of vSphere Switch (vss or vds)

xvctype

Whether this is a Compute-only Cross VC-vMotion (1=true or 0 = false)

UppercaseUUID

There cases where the vCenter Server InstanceUUID must be all caps ($true or $false)

Here is a screenshot of running the script:

Note:When changing the type of vSphere Switch, the following combinations will are supported by the script as well as using the vSphere Web Client: VDS to VDS, VSS to VSS and VSS to VDS. VDS to VSS is not supported using the UI or API and neither are 3rd party switches supported.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of:

The “Target Datastore” part is a bit of an issue.
In severals situations I need to live migrate from a brown-filed to a green-field environment.
However, both the new and old envirnoment have full access to the same storage, so Storage vMotion is not necessary.
If You have one vdisk or all your vdisks reside on the same VMFS, then I only have to tell it to use the source VMFS as the target VMFS. In that case an ordinary vMotion (without Storage vMotion) is performed.

But, when You have two or more vdisks residing on two different VMFS, then it immediately becomes a hassle.

Is there a way to tell the xVC-vMotion to “leave disks as is” ?
Not entering a target datastore fails (at least the script fails).

William – thank you for this script – it is invaluable. We are in a similar brown-field/green-field situation with the added complication of VSAN.

We are Storage vMotioning from the VSAN to a temporary large datastore (NFS) that I am considering mounting on both the ‘OLD’ cluster and the ‘NEW’ cluster, then for the non-critical machines powering them off an removing them from inventory then adding them to the inventory on the new cluster. For the essential machines, can we use (as Dag mentioned above) setting the SOURCE VMFS (nfs in this case) in the script the same as the DESTINATION VMFS (the SAME nfs storage) so XVC-motion will just vmotion the machine and not the storage?

Was this ever answered? We are in the same boat – storage is shared between the vcenters so we don’t need to do the storage vmotion but the script fails if you drop the datastore info. This adds a lot of time to the process that is unnecessary.

Awesome information! I have a question, would we not be able to use the conventional “Move-VM” cmdlet to move VMs between a linked mode vCenter 6.0 with in the same SSO domain?
Especially cases where only compute vmotion is required and no need of Storage vmotion.

Hi William, I have been playing with this script. Does this script also works migration from vds to vds? I tried running it with only resource pool spec, so that i will let DRS place the VM, I am getting the below error message. I did verify the target dvswitch has the same UUID and is accesable to the cluster that is specified.

I experienced the same error regarding VDS to VDS migration and debugged it. Line 120 returns both UUIDs of both VDS (source and destination). Therefore -Server needs to be added as well here to work-around that:

No, the script does not have to run on the vCenter Server and in fact, most customers would normally run it on a Management system that has their various Automation tools/etc. Yes, you can run multiple instances of the script. vMotion is VM agnostic 🙂

Thank you for the script! How much time this will save me!
I wrote a small wrapper script to translate network portgroup names and datastore names and then feed it into your script one-vm-at-a-time. Soooo much better than using the Web Gui 🙂

I found if I am moving VMs between datacenters in the same vCenter then you can Rem out the “service” on line 107:
spec.service = $service
You actually don’t need any of the related $service lines. It was causing errors anyways (maybe because I’m using the same source and destination vCenter?)

I noticed some comments above asking about omitting the datastore and having issues with multiple datastores.
From my research the API only allows a single datastore to be passed. If you attempt to vMotion a VM with multiple datastores the vSphere Web GUI does not allow you to move it between datacenters. So I >assume< that a VM with multiple datastores cannot be vMotioned across vCenters as-is. I believe it's a limitation of either the API (corner case not caught by the developers) or it requires additional complexity that VMware did not have time to address (yet).

Also, the datastore is a requirement if you are going between datacenters because, as the API doc says, even if it's the same datastore name, it's a completely different datastore object. So it needs to know where to find the VM in the "other" vCenter or Datacenter.

First off, I want to say thank you for this script. It is helping us with a large migration and has been going very well.

I do have one question though. We are trying to use the script to migrate a large Exchange server. The datastore size is 4TB and the Exchange server is using about 3TB of that space. When we try to migrate the server using the script we get a message that saying “Insufficient disk space on datastore”. We are not changing datastores. The destination vCenter and host are able to see the datastore. Can you tell me how much free space we need to have in order to complete the migration?

Very useful Script. Thanks. But one question, I’ve tested it with two vCenters, within the same SSO Domain. One with embedded PSC, the other with external PSC. The move from the one with external PSC to the vCenter with embedded PSC works fine. The move back to the vCenter with the external PSC not:
Migrating denetv5is12xvmo from denetv5is12devv.123.xxx.dev to denetv5is08devc.123.xxx.com …

Can this technique work with vCenter environments in different domains (no trust)? Do they have to share the same vMotion network? I want to use this to migrate an entire environment from one data center to the other. Thanks!

In my POC, I setup two separate vCenters and each host is setup to use vMotion on the vMotion TCP/IP stack. Pings of the vMotion network work from an ESXi host in one domain to another ESXi in another domain. I have a testvm that is on a VLAN which is presented to both environments. So the setup is: Same vMotion network, same VM Networks, with different storage in two separate vCenters in separate domains. xMove just will not work for me. I am using VMware PowerCLI 6.3 Release 1. What am I missing?

I’m moving guests from an old vCenter to a new vCenter, but they will have all the same hosts, clusters, networks, etc.. I tested this on a test VM with a single disk. and it went great. I ended up re-writing some of the disk portions, since I want to preserve the datastore location from the source to the destination. However, it keeps complaining that the destination has insufficient space. Is there a way to tell this that I only want a “xVC compute migration”?

I think this is what I’m looking for. I’ll see how it works on a test VM.

diskMoveType* xsd:string Manner in which to move the virtual disk to the target datastore. The set of possible values is described inVirtualMachineRelocateDiskMoveOptions.
This property applies to all the disks which the virtual machine has, but can be overridden on a per-disk basis using diskMoveType prior to vSphere API 6.0 or using diskMoveType in vSphere API 6.0 and later.
This property can only be set if deltaDiskBackingsSupported is true.
If left unset then moveAllDiskBackingsAndDisallowSharing is assumed.
Since vSphere API 4.0

From

moveAllDiskBackingsAndAllowSharing All of the virtual disk’s backings should be moved to the new datastore.
If a disk backing is not the child-most backing of this virtual machine, and there exists a read-only disk backing with the same content ID on the target datastore, then this disk backing may not be copied. Instead it is acceptable to attach to the read-only disk backing at the target datastore. A read-only disk backing is defined as a virtual disk backing which no virtual machine is currently writing to.

I did simply increase the datastore size to more than twice the VM size on disk, and the vMotion worked after that. I watched the datastore during the process, and I could not find any evidence that files were moved. Also, this VM is roughly 5 TB in size but the vMotion only took 1 minute 16 seconds to complete. We are on 10 Gb/s but it would take longer than that to migrate if it actually copied the data.

At this point I believe that there is a pre-check for datastore space that does not account for migrations to the same datastore. Unfortunately I haven’t found an option yet to correct the behavior.

This script works well with and offline VM that can be moved successfully from one vCenter to another on different subnets and domains. However, when trying to live vMotion using the same script and process, it fails.

Are we to assume that both hosts need to have the same exact vMotion kernel port on the same subnet?

The vMotion failed because the destination
host did not receive data from the source
host on the vMotion network. Please check
your vMotion network settings and physical
network configuration and ensure they are
correct.

First, thank you for the script! I am encountering an error when running it that I hope you can help with. I am attempting to xVmotion between two vCenter v6 u2 instances, the hosts are running ESXi v6 u2, going between two vSS’s. The script appears to successfully identify the source datastore (VMFS-V1-VDI), but then throws the following error:

After dealing with some bugs (had to fight with this error: The destination distributed switch has a different version or vendor than the source distributed switch. Solution was to change the vendor name of the vds from VMware,inc to Vmware plus a typo on the code (there is a comma missing after [String]$vmnetworks, I managed to migrate my first VM and the result was excellent. great script

We will be in the need of this script in the near future, but I wanted to inquire to see if anyone had this scenario… (we will need to upgrade our source vCenter to 6.0 first) The source vCenter is on traditional SAN with VMFS5 datastores presented to the Hosts as LUNs. The new target vCenter will be VxRails which uses vVols. Is there a means to make this transition using this script? Thanks in advance.

1. I see no variable for $cluster within the “# Variables that must be defined” section.
2. I see no way of migrating a VM to a folder i.e. our folder structure & permissions will be the same at our destination VC anyway to include this?

Noticed this question was not answered, and I understand it is not a straight forward question. With variable $vmname, would it work to leverage a csv like this?
$vmname = import-csv c:\list-o-vms.csv | foreach-object {$vmname = $_.VMname}

file-format:list-o-vms.csv:
VMname
vm01
vm02
vm03

I know this only gets you so far, since the script still requires the $vmnetworkname and $switchname, Though I figure getting the above to work, would be similar for the variable. Just specify another column or keep the script limited to migrating VMs on the same DPG or PG. Thoughts?

Hi William, thanks a lot for this scripted process, it is really helping us a lot.
I have one small query related to line 188, the wait task. We get random timeouts as you can see below.
The migration still proceeds without issue and completes but do we need to worry about these messages? What exactly is the wait-task? Is it just the progress bar updating?

—————————————————————-
Wait-Task : 11/4/2017 2:09:31 AM Wait-Task The request channel timed out while waiting for a reply after 00:05:00. Increase t
or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
At C:\Users\Administrator\Downloads\xMove-VM.PS1:188 char:14
+ $task1 | Wait-Task
+ ~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Wait-Task], ViError
+ FullyQualifiedErrorId : Client20_QueryServiceImpl_WaitForUpdates_ViError,VMware.VimAutomation.ViCore.Cmdlets.Commands.WaitTask

Can you help me with JavaScript code to perform v motion across different clusters connected to different switches.The library workflow(connectvmnicnumbertovirtualdistributedportgroup) only binds the port groups of the same switch.Can i get a JavaScript code for the same?
Thanks.

Thanks William for the fantastic script
I’m trying to understand this script. I’ve tried it and it works. Awesome
I’ve tried it with single datastore, I’m trying to use this script with VM that has multiple datastore to the remote site with multiple datastore as well. when I tried this script, the VM from multiple datastore when it moved to the remote site, it went to one datastore

$datastorename = “datastore01”

Does it accept multiple datastore? I’ve tried comma separated it did not work.
I also changed

Just like to update this question, been using this for sometime now for our upcoming DR testing. We will be using this to LIVE vmotion our VMs from one DC to another and running in one DC for a few days/weeks.
This script works with a VM with single Datastore or multiple Datastore… but noticed some minor issue below regarding the vCenter/CLI reporting nothing on the ProvisionedSpace and UsedSpace after the vmotion using the script.

First of all… thanks William for the xMove-VM script. Its a fantastic script.
One question if anyone noticed, when I call this script and move a VM from DC1 to DC2 I noticed from the UI, it does not have provisioned space and usage space. its showing as blank.
has anyone experience this?

I am performing storage vmotion across and within vcenter.So i am facing this issue that once i perform vmotion on a vm across vcenter the library action that i am using “getnetworkforgivennic” fails.After troubleshooting,i found that the action matches the portgroup key and network key,whixh in my case after vmotion across vcenter is changing randomly..

So my aim is to get the portgroup attched to a vnic.I have tried vm.network but it is not giving me the network portgroups orderwise as nics.
Any resolutions?

I am getting EVC errors. The source VM is on HP G8 Blade and destination is G9 blade. I am getting this error. Do we need compatibility even though we are doing cross vcenter migration?

Move-VM : 10/20/2018 9:43:19 PM Move-VM The operation for the entity “XXXXXXVM” failed with the following message:
“The virtual machine requires hardware features that are unsupported or disabled on the target host. If possible, use
a cluster with Enhanced vMotion Compatibility (EVC) enabled; see KB article 1003212.

Primary Sidebar

Search this website

Author

William Lam is a Staff Solutions Architect working in the VMware Cloud on AWS team within the Cloud Platform Business Unit (CPBU) at VMware. He focuses on Automation, Integration and Operation of the VMware Software Defined Datacenter (SDDC).