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.bsky.social | @*protected email*) (@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.
Excellent stuff! Thanks a lot William. I'm pretty sure this helps customers making migrations between platforms even more fluid!
"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" - do we have still the same limitation as before, that source and destination vDS should be one the same version?
Simon,
Yes. Please see https://www.williamlam.com/2018/09/vmotion-across-different-vds-version-between-onprem-and-vmc.html for workaround if this is required, but it is recommend you try to match VDS version and then you can always upgrade once workloads have moved across
Hi Lam
It it indeed huge announcement and exciting news about “Cross vCenter migration utility is now productized in the #vSphereClient 7.0U1c!”
My question here
1-does the MAC address changes while migration ?
2-is VMs downtime required for migration between vCenter.
TBH In this KB
https://kb.vmware.com/s/article/2106952
couldn’t found in-depth info.
Thanks 😊 and congratulations for the great works 👍
1) No, but a conflict could occur. Take a look at https://www.williamlam.com/2015/03/duplicate-mac-address-concerns-with-xvc-vmotion-in-vsphere-6-0.html for the behaviors. There's also script to help check for these things before you consider migrating
2) No, this is a vMotion 🙂
Thanks William,
1-thanks for sharing the same.
2-dose it mean there is there RTO happen during migration.
By three way this is really helpful for us as we have 13 vCenter 🙃
8vCenter(6.5)
1 vCenter(6.5)vXRAIL
2(5.5)EOL. VDI
2(6.0) VDI
Thanks a lot god bless you🌷
Hi I do have a question here..My Source vc is on 7.0 U1c with ESXi 7.0x and ESXi 6.5x and destination is with vc 6.5 and ESXi 6.5. The xvmotion from webclient is working source 6.5 ESXI host to destination 6.5 ESXi host. But it does not work from 7.0 source ESXi host to 6.5 destination ESXi host and it crashes destination VC with error:
[07:01 am] Sindhu K M
Error vCenter does not support hosts of this type ( ).
vCenter does not support hosts of this type ( ).
Please see https://kb.vmware.com/kb/2106952
Awesome William.. Nice to see one of my tweet there which i send way back in 2018 appreciating teams work . Just finished migrating another 400+ servers using the fling to VXrail ... Old habit die hard.. best part....we saved ton's of customer money intended for buying a migration tool and with zero investments..
Thanks Once again for this ..congratulations for the great works 👍
Seems not working for vcenter 6.0u3.
I can't see the vm inventory from the import VM menu
Is it an expected behaviour ?
Thank you in advance
Hi Guillaume have you made any progress with this? I get the same behaviour. If I use the fling I can cold-move a VM (cold because I think I have EVC issues... :sadface....)
Same behaviour above... source vCenter 6.0U3, destination 7.0.1c and VM Inventory is empty from the Import VM wizard.
Fling works fine, I can see VMs from source vCenter.
Thanks,
+1 for this behaviour too. Haven't tried the fling. I want to use this to migrate away from a legacy 6U3 environment and as far as I can tell it's all supported, no FW on the windows VC. I get that I will have work to do to provision the vds on the new environment but at the moment I don't even get that far!
Hi William, great work! In your "Use Case - Import or migrate VMs from another vCenter Server (which does NOT have to be running vSphere 7.0 Update 1c (p02)", do the 2 vCenter servers need to be in linked-mode/Enhanced Linked-mode (I'm hoping not!).
Regards,
George.
as per this vmware blog, it appears not. https://core.vmware.com/resource/introducing-advanced-cross-vcenter-server-vmotion-capability I have a vcsa 7 u1C which can authenticate with a windows vc 6.0U3 in a different sso domain but the inventory is blank. As far as I can see the reqs are met, others have reported the same issue. 🙁
That's correct. It seems this question continues to come up even though I've explicitly mentioned it as part of the history 🙂
The Cross vCenter vMotion feature does NOT care about how your SSO Domain is setup (Linked or NOT Linked). The Advanced Cross vCenter vMotion simply makes its functionality more easily accessible natively in vSphere UI, there's no requirement on HLM, just source/destination vSphere version as mentioned in that VMware KB
If your ESXI7.0 DVS is 7.0 and 6.X DVS is different , you cannot do HOT vmotion. Shut down the VM and migrate
Great post,
Hi William, Great job!
If I have vCenter 7.0 U1c or later, still need the Enterprise plus license at both sides?
Thanks
Hi William, Does this need vSphere Enterprise plus license on source side as well ?
You’ll need proper licensing on both source and destination
Is in the 7.0 1c also the api included? Can not find any reference to this.
This is a UI feature as the API has been around since vSphere 6.0. Recommend you take a look at the history on how the Fling and ultimately productized feature came to be 🙂
I'm having Problems on getting things done here.
In Destination 7.01d while selecting destination cluster i get "Compatibility check took too long to complete. Please check vCenter Server logs for more details."
Any Hints what could be wrong or where to look? vpxd.log on both vcenter seems not very helpful
Hard to say what this could be. My recommendation is to reach out to VMware Support so they can help in troubleshooting
i think i found the error while checking all connections and firewalls:
We did set a proxy in vCenter to download updates. It seems that this proxy is used when connecting to other vCenter. Because of Policies this is not allowed. After disabling the proxy on both vCenter the problem disappeared.
Would be nice if there would be a hint in documentation about this scenario!
Hi William,
I am using vmware fling utility plugin to migrate my VMs from 6.7 VC running on UCS to 7.0 VC running on Nutanix. I am able to migrate standard VMs with no issues. But I tried to migrate a VM that has RDM attached to it. Once I submit the job, I am getting "call DRS for cross vmotion placement recommendations" task failed with error "operation is not allowed in the current state" on target VC. Please help on this. Note: I chose the virtual disk format to thin provision.
I tested the same in other environment and it was successful.
Hey William! Now that xNew-VM is productized in the vSphere GUI, is there / will there be a new official PowerCLI cmdlet to use that functionality, or will we continue to use xNew-VM the way we always have?
Move-Vm already allows you to perform Cross vCenter vMotion. What’s been productized is UI capability to perform Cross vCenter vMotion across differ t SSO Domain. PowerCLI has added that support awhile back 🙂
Hi!
I have a new environment setup (7.0 U3) and the old one (6.0 U2) and Advanced XVM seems perfect.
But when I try to import one VM it is empty under VM-list?
Is it because version 6.0 U2 or that it is not Enterprise Plus licens?
source needs to be at least 6.5 for XVM.
Both vCenter and ESXi version?
Hi William, What interfaces exactly do vmotions occur on? by the vmkernel of vmotion? by mgmt's vmkernel?
Its whatever VMkernel interface that you've configured vMotion traffic on 🙂
Hi! Got this exact lovely error message "again" in 2024, both vCenters and all hosts/VDSwitches on v8: "vCenter does not support hosts of this type ( )" Problem this time around was caused by not working DNS, and using vCenter IPs instead of DNS names helped as workaround in our case, for info, if it might help someone out there troubleshoot this 🙂