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.

Screen Shot 2015-02-07 at 10.34.53 AM
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.

xvc-vmotion-between-same-and-different-sso-domain-0
Note: For additional details and requirements for Cross vCenter vMotion, please have a look at this VMware KB 210695 for more information.

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
datastorename Name of the vSphere Datastore to migrate the VM to
clustername Name of the vSphere Cluster name to migrate the VM to
vmhostname Name of the ESXi host to migrate the VM to
vmnetworkname Name of the vSphere Network(s). in the order in of the vNIC interfaces to migrate the VM to
switchname 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)

Here is a screenshot of running the script:

Screen Shot 2016-05-25 at 8.01.50 PM
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.

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

22 thoughts on “Automating Cross vCenter vMotion (xVC-vMotion) between the same & different SSO Domain

    • vMotion network can be routed L3 but VM cannot change its IP address during vMotion so it has to remain in same L2 network after migration

  1. William,

    Thank you for updating the script. I’m trying to run it, but I get the error below. Any ideas?

    PowerCLI C:\script> .\xMove-VM.ps1

    Migrating VW764THIN from sv8vc1.avondale.org to svlvca.avondale.org …

    VERBOSE: 5/26/2016 9:56:18 AM Wait-Task Started execution
    VERBOSE: 5/26/2016 9:56:18 AM Wait-Task Finished execution
    wait-Task : 5/26/2016 9:56:20 AM Wait-Task The operation for the
    entity “VW764THIN” failed with the following message: “A specified parameter
    was not correct: ”
    At C:\script\xMove-VM.ps1:151 char:14
    + $task1 | wait-Task -Verbose
    + ~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Wait-Task], InvalidArgument
    + FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpda
    tes_OperationFailed,VMware.VimAutomation.ViCore.Cmdlets.Commands.WaitTask

  2. I’ve not seen this answered elsewhere, but does the source host and vds version need to be 6, or only the vcenter?

  3. hi

    What are the communications requirements to make a Croos vCenter vMotion?

    Visibility between vCenters? ,L3?, ports?

    Visibility between ESXi?, L3?, from management network to management network? form vmotion network to vmotion network? ports?

    thanks

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

    • Dag, did you ever get a response? or get the multi-datastore VM migration worked out? I have the same issue and have a few thousands Vms to migrate to a new vCenter.
      Thanks,

  5. 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 Sathish,

      Not today, but it’s something I’ve already fed into the team and hopefully we’ll see an update to the Move-VM cmdlet to support xVC-vMotion

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

    The operation for the entity “kstllcrml01-clone” failed with the following message: “Currently connected network
    interface ‘Network adapter 1’ uses network ‘DVSwitch: ‘xx xx xx xx xx xx xx xx xx’, which is not accessible.

  7. William. Thanks for the script. We have to move quite a few VMs. Does the script have to be run on the vCenter server itself? Also, can more than one instance of the script be run at a time?

      • Brian,

        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 🙂

  8. I’am using your script with PowerCLI 6.3R1 against to 2 vCenter (6U2build3634793) of the same SSO-Domain. And always get following error:
    Wait-Task : 22.08.2016 13:17:20 Wait-Task The operation for the entity “myVM” failed with the following message: “Ein angegebener Parameter war nicht korrekt:
    ServiceLocator.instanceUuid”
    In C:\tmp\xMove-VM.ps1:151 Zeichen:14
    + $task1 | Wait-Task -Verbose
    + ~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Wait-Task], InvalidArgument
    + FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpdates_OperationFailed,VMware.VimAutomation.ViCore.Cmdlets.Commands.WaitTask
    Thank you very much in advance for your answer.

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

  10. 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?

    Thanks
    Eric

Thanks for the comment!