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 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:

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 and neither are 3rd party switches supported.

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

61 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,

    • 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?

      Thanks in advance,

      PMB

  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

  11. Hi William,

    i have a problem with the migration of a host.
    FYI: I use the same SSO Domain.
    My changes of the powershellscript are these:

    $vmname = “testmachine”
    $sourceVC = “vcenter1.domain”
    $sourceVCUsername = “”
    $sourceVCPassword = “”
    $destVC = “vcenter2.domain”
    $destVCUsername = “”
    $destVCpassword = “”
    $datastorename = “storage1”
    $clustername = “clus2”
    $vmhostname = “esx1-clus2.domain”
    $vmnetworkname = “VLAN-404 XXXXXXX”
    $switchname = “dvs1”
    $switchtype = “vds”

    # Connect to Source/Destination vCenter Server
    $sourceVCConn = Connect-VIServer -Server $sourceVC
    $destVCConn = Connect-VIServer -Server $destVC

    Now when i execute the script, gives me the PowerCLI following error:

    Wait-Task : 26.09.2016 14:37:15    Wait-Task        The operation for the
    entity “testmachine” failed with the following message: “Die Anmeldung kann
    aufgrund eines falschen Benutzernamens oder Kennworts nicht abgeschlossen
    werden.”
    In C:\Users\XXXXXX\Documents\bashscript.ps1:151 Zeichen:14
    +     $task1 | Wait-Task -Verbose
    +              ~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (:) [Wait-Task], InvalidLogin
        + FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpda
       tes_OperationFailed,VMware.VimAutomation.ViCore.Cmdlets.Commands.WaitTask

    He tells me my credentials are wrong, but i’m sure type it correctly.
    The interesting is that i can see the action in the vcenter, but with the same error
    my credentials are wrong.

    Can you please help me? Or can you give me help how to debug and where i can look
    for it?

    Thank you

  12. Thanks for the script, very useful!! I was wondering if there is a way to point the script to a particular vm folder or even maybe a csv file instead of just moving one vm at a time? Thanks!

  13. 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 …

    VERBOSE: 28/09/2016 14:09:18 Wait-Task Started execution
    VERBOSE: 28/09/2016 14:09:18 Wait-Task Finished execution
    Wait-Task : 28/09/2016 14:09:19 Wait-Task The operation for the entity “denetv5is12xvmo” failed with the following message: “A specified parameter was not correct: ServiceLocator.instanceUuid”
    At C:\scripts\xMove-VM.ps1:151 char:14
    + $task1 | Wait-Task -Verbose
    + ~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Wait-Task], InvalidArgument
    + FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpdates_OperationFailed,VMware.VimAutomation.ViCore.Cmdlets.Commands.WaitTask

    Do you have an idea how to solve this?

    Thank you!

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

      PowerCLI C:\bin\vSphere\vmotion> .\xMove-VM.ps1

      Migrating testvm from vcenter1.domain1.com to vcenter2.domain2.com …

      VERBOSE: 12/7/2016 6:09:17 PM Wait-Task Started execution
      VERBOSE: 12/7/2016 6:09:17 PM Wait-Task Finished execution
      VERBOSE: 12/7/2016 6:09:17 PM Wait-Task Started execution
      VERBOSE: 12/7/2016 6:09:17 PM Wait-Task Finished execution
      Wait-Task : 12/7/2016 6:11:47 PM Wait-Task The operation for the entity “testvm” failed with the following message: “A
      general system error occurred: Operation was canceled”
      At C:\bin\vSphere\vmotion\xMove-VM.ps1:155 char:14
      + $task1 | Wait-Task -Verbose
      + ~~~~~~~~~~~~~~~~~~
      + CategoryInfo : NotSpecified: (:) [Wait-Task], SystemError
      + FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpdates_OperationFailed,VMware.VimAutomation.ViCore.Cm
      dlets.Commands.WaitTask

  15. After cross VC vmotion, how can I find the migrated VM in destination VC? Through instance UUID? Is it possible that there are existing VM with same instance UUID in destination VC?

  16. Hello,
    nice Script you have there, works totally fine for me.
    But what do i do if my VM has 2 vLans connected?

    Thanks and greetings from Germany,
    Josh

    • pass them through comma separated into the function. William’s script will separate them. Just pass them through in the order that they appear in the VMConfig IIRC.

      i.e. $strNetworks = “my_portgroup1,myportgroup2,myportgroup3”

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

      From

      • That option did not work.

        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.

  18. Hi All,

    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.

  19. Hi William,

    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:

    Get-Datastore : 4/26/2017 12:03:50 PM Get-Datastore Datastore with name ‘VMFS-V1-VDI’ was not found using the specified filter(s).
    At C:\scripts\xMove-VM.ps1:118 char:23
    + $DestDS = Get-Datastore -Server $destvc -name $sourceDS
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : ObjectNotFound: (:) [Get-Datastore], VimException
    + FullyQualifiedErrorId : Core_OutputHelper_WriteNotFoundError,VMware.VimAutomation.ViCore.Cmdlets.Commands.GetDat
    astore

    Any assistance you could provide in troubleshooting this would be most helpful.

    Thank you!

  20. Hi William

    Thanks for a great script, it has done good work for us.

    Just a question, is it possible to place a VM (with for example 2 vmdk) on two different target datastores?

    Thank you
    Magnus

  21. Does the move-vm command work in the reverse scenario of moving a VM from a vCenter 6.5 to 6.0? Also, VM is in a VMFS6 datastore, moving back to a VMFS5 DS.

  22. Hi,

    great script! thank you for sharing. If I just want to do the cross migration and keep the same datastore location should I just write the original datastore name?

    • 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

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

  24. About to test this but I have 2 observations:

    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?

    Thanks.

  25. I saw that the script is referring to the $sourceDS where it should be referring to the DestDatastore

    $DestDS = Get-Datastore -Server $destvc -name $sourceDS

    cheers

  26. Is there any reason that a vmotion triggered by this script would happen slower than a vmotion done between linked vcenters in the web interface?

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

Thanks for the comment!