Today I am writing a blog post about a new fling that was released. For those of you that do not know, VMware flings are small projects run by VMware engineers to test new features with the greater community. If these projects are popular they can become part of actual VMware products. A good example to this is the HTML 5 vSphere Client. It started out as a fling and is now embedded in vSphere 6.5. The fling I want to talk about in this blog post is the Cross vCenter Workload Migration Utility. This utility has the capability to move workloads across vCenters in bulk through a graphical user interface.
Now why is this so special you may ask, because we have Cross vCenter vMotion as a feature in vSphere 6 and up. Well, to start off, if you want to use the vSphere Web Client to do a cross vCenter vMotion this only works for federated vCenters (ie part of the same SSO domain). There is the possibility to do a cross vCenter vMotion to a non-federated vCenter but this was only possible using the vCenter API. Not so long ago it also became possible to do this with PowerCLI 6.5 which made it somewhat easier but now with this fling you can use a GUI to do the same.
Because the setup and configuration of this fling is very straight forward this is a very nice option for customers that do not want to build PowerCLI scripts or a custom tool with API’s. Or, if a fairly small number of VM’s need to be migrated.
Talking about migration, this fling can be used to migrate workloads that run on vSphere 6.0 to vSphere 6.5. Keep in mind tough that it has to adhere to the limitations that cross vCenter vMotion has. So, to migrate from vSphere 6.0 to 6.5 the versions must be 6.0 U3 and 6.5 GA. Also keep in mind that this is a one way migration because visa-versa it will not work. When moving between environments of the same version this limitation does not apply of course.
For more information about the cross vCenter vMotion requirements visit https://kb.vmware.com/kb/2106952
Key Features
- Completely UI-driven workflow for VM migration
- Provides REST API for managing migration operations
- Works with vCenter not a part of the same SSO domain
- Support for batch migration of multiple VM’s in parallel
- Supports both live as well as cold migration of VM’s
- Performs storage vMotion, not requiring shared storage
- Flexible network mappings between source and destination sites
Install and configuration
The installation is pretty easy. First download the zip file from the fling page. There is one zip file that works for Windows, Linux and MacOS.
As discussed earlier, you need vCenter 6.0 or higher. Also make sure you have Java Runtime Environment version 1.8 or higher installed.
Installation
Unpack the zip file, change to the correct directory and run the command:
java - jar xvm-1.0.jar
This will initialize the service on port 8080 by default.
If you want to have it running on a different port you can add the following parameter
-Dserver.port=<portnumber>
Now go to http://localhost:8080 in your browser and you should see the following site
Configuration
In this example I have set up two environments which are non-federated. So, the two vCenter servers (version 6.5 GA) are not in the same SSO domain.
Click the Migrate button followed by the Register button so we can add the two vCenter Servers. Fill in the details of the first site and click Submit, do the same for the second site.
Keep in mind that the configuration of the sites is stateless so when you stop the XVM process the information is lost and you have to re-register the vCenter servers again the next time. You could automate this using the REST API, more on that later.
Migration
After we have set up the two vCenter servers we can start migrating VM’s between the two. Click on the Migrate button again and use the pull-down fields to fill in the correct information.
Click on submit and watch the progress as the VM’s get moved to the new vCenter. As you will see the VM’s are migrated in parallel.
When the migration is done the VM’s are happily running in their new environment.
Of course you need to make sure that for all of this to work you need to have the requirements for cross vCenter vMotion in place in the environment as well as the correct VM networks so there is no loss in network connectivity.
REST API
Now that we have seen how the GUI works I will give a short overview of the REST API. If you click on the API button in the top right you will go to the REST API swagger documentation. Using this page you can look at how the API works and test it. With this information it is then possible to further automate the migration of VM’s with this tool. In this example you see how you can programatically add a vCenter site, using this allows you to setup the utility quickly after it was shutdown (the utility is stateless remember).
Conclusion
This concludes my overview of this new VMware fling, Cross vCenter Workload Migration Utility. I think this tool is a very nice addition and I would not be surprised if this became available in the actual vSphere product in the future. The ability to vMotion VM’s as part of a migration from vSphere 6.0 to vSphere 6.5 is something that can really benefit customers moving to a new greenfield 6.5 environment. No more using ‘swing-hosts’ and offline migrations to get your VM’s across.
There is one last thing I want to mention. VMware has also released a cloud service called HCX. This is available as initial availability. HCX is a VMware Cloud Service which provides high-scale zero-downtime migration between any cloud. HCX has the ability to move VM’s from environments that run vSphere 5.5 to newer versions, so this sounds really powerful.
