History of Cross vCenter Workload Migration Utility and its productization in vSphere 7.0 Update 1c (p02)

I am super excited to share that the popular Cross vCenter Workload Migration Utility Fling has been officially productized and is now available with the release of vSphere 7.0 Update 1c (Patch 02)! The official name for this capability is now referred to as Advanced Cross vCenter vMotion, would that mean the short hand is Ax-vMotion? 🤔 In any case, this has literally been 5 years in the making from an idea that I had shared back in 2015 to now having it fully integrated as a native vSphere feature in 2020 is pretty wild!

While reflecting back and writing this blog post, I came across this tweet from our CEO, Pat Gelsinger, which I thought was quite fitting

I love this. Thanks for sharing. To me, execution is everything. It's much easier to have a good idea than it is to actually get it done. https://t.co/DAPdip6A8e

— Pat Gelsinger (@PGelsinger) November 24, 2020

I have learned over the years, that simply having a good idea is not enough. It takes hard work, time and perseverance.

It has been very humbling to work with so many of customers of all sizes and shapes and enabling them to take advantage of vMotion in a new way that would allow them to solve some of their unique business needs. vMotion is still as magical in 2020 as it was when VMware transformed the IT industry when it was first introduced.

🤯 WOW 🤯

~400TB migrated using the Cross vCenter Workload Migration @vmwflings 🔥

You win @vRobDowling 👏👏👏

I want to say the largest VM migration that I heard of with this tool was ~15K https://t.co/gfjGHQcJaE

— William Lam (@lamw) December 18, 2020

Of course this would not have been possible without the support of so many amazing VMware Engineers who contributed to the Fling including the original developer, Vishal Gupta who I had worked with as part of the VMware Cloud Foundation (VCF) team. After Vishal left VMware, I recruited a few more folks to help with the project including Vladimir Velikov, Vikas Shitole, Rajmani Patel, Plamen Semerdzhiev and Denis Chorbadjiyski. Lastly, I also want to thank Vishwa Srikaanth and Abhijith Prabhudev from the vSphere Product Management team who have been supportive of the Fling since day 1 and has been advocating with me on behalf of our customers.

History

Back in 2015, I wrote an article called Did you know of an additional cool vMotion capability in vSphere 6.0? which was and still is not widely known about vMotion. In vSphere 6.0, we introduced the Cross vCenter vMotion feature which allowed customers to live migrate a VM between two different vCenter Servers, which were part of the same vCenter Single Sign-On (SSO) Domain. This constraint was not a limitation of vMotion but rather an artificial constraint imposed by the vSphere UI. While looking through the vSphere API, I had noticed some properties that indicated that a vMotion could actually span an SSO Domain and I quickly built a PowerCLI script leveraging the APIs to allow our customers to take advantage of this additional capability.

This not only unlocked brand new use cases, especially for customers looking to consolidate or retire old hardware, but in my mind it was also the beginning of true workload mobility. Remember, HCX had not existed at this time yet. In fact, while re-reading that 5 year old blog post, I thought this personal quote nicely sums up the potential I had saw back in 2015:

I think it truly removes any boundaries for a vSphere virtual machine and will open up an entire new class of mobility use cases that were never thought possible before.

The PowerCLI script was definitely one of the most popular amongst customers and I continued to share that solution with as many internal and external folks as I could. My good friend Alan Renouf took noticed and with his help we ported the functionality from my script into PowerCLI's Move-VM cmdlet with the PowerCLI 6.5R1 release in 2017.

Although the PowerCLI cmdlet made it easier to consume, I noticed it was still a challenge for many to write the basic PowerCLI code to perform "bulk" VM migrations. After making the VMware Cloud Foundation (VCF) team aware of this solution, we realized there was an opportunity to further simplify the experience by having a graphical user interface that can make it easy for anyone to migrate their workloads, whether that is a couple or several thousand VMs. We also kept the automation use case front and center by ensuring that we also a simple to use REST API, since vCenter Server only had REST APIs for vSphere Tags. At the end of 2017, the Cross vCenter Workload Migration Fling was released.

The Fling immediately resonated with customers and it was non-stop from there. Almost every week, we had a new customer share how many VMs they had successfully migrated. It started off with dozens, hundreds, thousands and eventually we even had a number of customers who reached 10k+ for major migration projects. The most common use case for leveraging this tool was to get off of legacy hardware and/or older releases of vSphere, without having to go through long and tedious upgrades. However, we also found customers were using the Fling to consolidate datacenters, especially after acquiring a new company. The reverse was also true, we had a few customers "split" up and this Fling was crucial in those scenarios as well. Workload Mobility is fairly common now, but it was still a new concept back then and I believe the Fling has allowed our customers to solve some real business problems which is why it has become such a popular tool.

Customers loved the standalone UI interface of the Fling, but it was a separate interface that customers had to learn. With the vSphere UI now completely transition off of the vSphere Flash Web Client and using HTML5, this was another opportunity for us. This work was lead by Vladi Velikov, an Engineer on the vSphere UI team who wanted to provide customers with a more integrated and improved user experience. We found that some of the issues that were reported from the community stemmed from migration pre-check and validation, majority of which was already part of vCenter Server's migration workflows. Since the Fling was simply exposing the underlying API, it was often difficult for customers to quickly pin-point why a migration failed. Rather than re-build this undifferentiated functionality, we wanted to leverage the existing tasks/events and error reporting facilities of vCenter Server. Remember, at the end of the day our Fling was just a client to the vMotion API. In 2019, an HTML5 plugin to the vSphere UI was released and customers could now choose either the standalone UI or the integrated vSphere UI to migrated their workloads.

In total, we had 10 releases of the Cross vCenter Workload Migration Fling, including adding support for NSX-T opaque networks and granular vSphere inventory selection to support VMware Cloud on AWS customers. Early on, my goal for the Fling was to always find a way to "productize" this capability natively within vSphere, so that every customer can get these benefits. It has been a long journey advocating on behalf of our customers and by no means was it easy, but it has definitely been rewarding and I am glad there is finally light at the end of tunnel 🙂

vSphere 7.0 Update 1c (Patch 02)

OK, enough of the history lesson. Let's now take a look at how the Cross vCenter Workload Migration feature works in vSphere 7.0 Update 1c (p02) which can be consumed using two different methods depending on your use case.

For general Cross vCenter vMotion requirements, please see VMware KB https://kb.vmware.com/kb/2106952 for more details.

Method 1:

Use Case - Import or migrate VMs from another vCenter Server (which does NOT have to be running vSphere 7.0 Update 1c (p02), see the KB above for supported source vCenter Server version).

There is now a new option called "Import VMs" when you right click on either a vSphere Datacenter or Cluster object.

Next, you will specify your source vCenter Server. By default, this will be blank and you will need to add all vCenter Server(s) you wish to migrate VMs from to the current vCenter Server that are you connected to.

Note: For security purposes, the saved vCenter Server credentials are not persisted and will be cleared upon logging out or when the current session expires.

Now, click on the Saved vCenters tab and select the specific source vCenter Server and click next.

The last step is to select all VM(s) from the selected source vCenter Server that wish to migrate to the current vCenter Server, the user experience should feel similar to that of the Fling. The other benefit with an integrated vSphere UI experience is that you can now use all the supported filtering options that is supported to quickly locate the VMs you are interested in migrating.

Once you have selected all the VMs, the remainder of the wizard is the same for standard Cross vCenter vMotion and all relevant pre-checks will automatically be validated, which is more exhaustive than the Fling as this is simply part of vCenter Server migration workflow.

Method 2:

Use Case - Export or Migrate VMs from the current vCenter Server to another vCenter Server which is not part of the same SSO Domain

To initiate this workflow, just right click on the desired VM(s) and then click on "Migrate" and you will now see a new migration type called Cross vCenter Server export option.

From here, the workflow is simliar to Method 1 where you select or add the desired vCenter Server(s) and then proceed with the migration.

The other nice thing about this native vSphere UI integration is that the migration tasks will be displayed in the vCenter Server which initiated the migration, which is useful as you do not have to connect to two different vCenter Servers to be able to view the complete migration status, especially if something goes wrong.

I am really looking forward to hearing from customers when they get a chance to play with this new feature. I know the vSphere Product Management team is also interested in hearing if there are other features you would like to see in the future. Feel free to leave a comment with your feedback.