Over the last few years, I have spoken to a number of customers who have greatly benefited from the ability to live migrate Virtual Machines across different vCenter Servers that are NOT part of the same vCenter Single Sign-On (SSO) Domain, which I had first shared back in 2015 here and here. This extended capability of the Cross vCenter vMotion feature enabled customers to solve new use cases that were challenging, especially for scenarios such as Datacenter migration, consolidation or even migrating existing workloads from their current environment into new SDDC deployments such as VMware Cloud Foundation (VCF) as an example.

Although customers could initiate Cross vCenter vMotions using the vSphere API which included PowerCLI (Move-VM cmdlet was enhanced in 6.5, more details here), the overall experience was still not as friendly. This was especially true for customers who may only have a small number of VMs to migrate and prefer a UI-based interface rather than an API/CLI only option. In addition, for large number of VM migrations, there was not an easy way to perform "batch" VM migrations that was easily consumable for folks who may not have a strong background in Automation or the vSphere APIs.

Today, I am pleased to share a new VMware Fling called the Cross vCenter Migration Utility that will help simplify the consumption of initiating VM migration(s) across different vCenter Servers, especially between dispart SSO Domains where a graphical interface was not available. This solution was developed out of our VMware Cloud Foundation (VCF) Engineering group which is part of the Integrated Systems Business Unit at VMware. I had spoken to a number of folks within the group about the extended Cross vCenter vMotion capability and I was super excited when I heard they were planning to release this tool as a Fling and make it available to all customers. I was fortunately to have been involved in the project alongside the Engineering lead Vishal Gupta and we are excited that we can finally talk about this project and see how customers will be using this new tool.

Cross vCenter Migration Utility Fling

Cross vCenter vMotion Requirements: KB 2106952

Download Fling here


Features

  • Completely UI-driven workflow for VM migration
  • Provides REST API for managing migration operations
  • Works with vCenter not part of the same SSO domain
  • Supports both live/cold migration of VMs
  • Batch migration of multiple VMs in parallel
  • Flexible network mappings b/w source and destination sites

Simplified UI

The Fling is a multi-platform Java client application that can run on Windows, macOS and Linux. After you start the application from the command-line, you can simply access it using a web browser which runs on localhost and port 8080 (default). The first step is to register your vCenter Server(s) as shown in the screenshot below, you can register as many as you want but do note that the application is stateless and the configurations will be lost once the application is closed.


Once you have registered your vCenter Server(s), you can initiate a VM migration request by simply going to the Migrate tab. Here you select the source and target resources and VM(s) that you wish to migrate. The really nice thing about the UI is that it will automatically detect all VM Networks for the VMS that you have selected which makes mapping the destination networks a breeze. Once you are ready, you can click submit and watch the progress either using the UI and/or the vSphere Web/H5 Client.

Automation via REST API

For customers with smaller environments, a simplified UI is a great option, but we knew the UI should not be the only method of consumption. In fact, we assume most will want to drive this from Automation standpoint which meant having a nice simplified REST API. In the upper right hand corner of the application, you will find an "API" link to built-in Swagger documentation. Not only can you access the REST API documentation within the application but you can also use the API directly from the Swagger UI if you would like as shown in the screenshot below.

PowerCLI Integration

I know many of our customers today automate using PowerCLI and I thought this would be a great way to not only help test the Fling's REST API but to also share some useful PowerShell functions that customers can quickly take advantage of immediately for the initial vCenter Server registration to initiating batch migration requests.

With that, I have created a PowerShell module called XVM.psm1 which you can simply download and import by running the following command:

Import-Module XVM.psm1

Once imported you will have access to the following 7 functions:

  • Get-VMNetwork
  • Get-XVCMSite
  • Get-XVCMStatus
  • Get-XVCMTask
  • New-XVCMRequest
  • New-XVCSite
  • Remove-XVCMSite


Below is a screenshot of using the Get-XVCMStatus, New-XVCMSite and Get-XVCMSite to check whether the API endpoint is running and then registering two vCenter Servers and listing them afterwards.


The Get-VMNetwork uses PowerCLI behind the scenes to take in a list of VMs (if left blank, all VMs are returned) and provides a nice summary output of all VM Networks that are attached to the VMs that you might be interested in migrating. This is useful for creating the network mapping for migrating between your source and destination vCenter Server.


The New-XVCMRequest is what starts a VM migration request (hot/cold) and the input params should be fairly straight forward. You will need to provide the logical site name that we had defined earlier, in our example below that is SiteA and SiteB. Next, we need to provide the source and destination vSphere Datacenter and Cluster, destination vSphere Datastore which will be used for VM placement on the destination vCenter Server. You also will need to include a list of VMs you wish to migrate, notice the input is similar to that of Get-VMNetwork function. Finally, you need to include a hashtable of the VM networks to map between your source and destination vCenter Server. Upon a submitting a successful migration request, you get back a TaskId that you can then pass into the Get-XVCMTask function to get progress on the individual migrations as shown in the screenshot below.

PowerCLI Demo

Here is a video demonstrating the use of the PowerCLI Module

Cross vCenter Migration Utility Fling - PowerCLI Integration Demo from lamw on Vimeo.

We hope you give the Fling a try and if you have any feedback or comments, feel free to leave it on my blog or better yet, directly on the Fling site where both Vishal and I will be monitoring.

9 thoughts on “Bulk VM Migration using new Cross vCenter vMotion Utility Fling

  1. Very useful Fling! Do the pre-flight checks include MAC address uniqueness at the destination (in other words, ensuring an existing VM the destination does not have a conflicting MAC address)? Thanks!

  2. Jason,

    There’s currently no pre-flight checks built into the underlying vMotion API which is what the Fling is consuming (think of it as a client that uses the API just like the vSphere Web Client for example). This is something that we definitely could consider adding into the Fling

  3. There is a minor but important clarification that is needed in KB 2106952 relating to xvMotion. The first two column headers are “Source vCenter Server” and “Destination vCenter Server” respectively, but the values provided in each are “vSphere”. This brings up an important question on which I’d like clarification: What if the source or destination vCenter is at the version specified but the ESXi hosts are not? For example, will a xvMotion succeed where the source is vC 6U3 + ESXi 6U2 and the destination is vC 6.5U1 + ESXi 6.5U1? This is an important distinction for customers that may wish to use the API or Fling because it informs them what exactly they must upgrade on the source vSphere side in order to accomplish migrations. Is it only vCenter, or vCenter and ESXi?

    • Its BOTH. vCenter Server + ESXi hosts must be the same version. vSphere, IMHO, is a “Family” name that includes BOTH VC+ESXi hosts, but I know its often used interchangeably with the ESXi Hypervisor which can cause some confusion.

      • That’s what I figured, but the column headers cause a slight bit of confusion and I know that this question will be one asked when considering cross vCenter migrations.

  4. just tried this for moving vm’s from 6.0 vcsa to 6.5 and getting an error. “error while getting placement results for vm”. Any idea’s?

Thanks for the comment!