Cross vCenter vMotion UI in the vSphere Client
Workload mobility is key in the current state of the private, public and hybrid cloud. Traditionally, vCenter Server API has been supporting various vMotion features. Among the important ones is migrating VMs across the SSO boundaries of two vCenter Servers.
For about 5 years Cross-vCenter vMotion has been supported by the vCenter API but not by the vSphere UI. The gap had been filled by one of the most popular Flings ever – the Cross vCenter Workload Migration utility, driven by William Lam. A large number of folks were asking for productization and official support by VMware.
Wait no more! Since vSphere 7.0 Update 1c release Cross vCenter vMotion is natively supported by the vSphere Client!
Kudos to William Lam, Vishal Gupta, Rajmani Patel, Vikas Shitole, Denis Chorbadzhiyski & Plamen Semerdzhiev for their tireless work on getting this from idea to product!
Cross vCenter migration UI workflows
This is a new workflow in the vSphere UI which allows “pulling” VMs from external vCenter. It is represented by a wizard triggered from the “Import VMs” action of the Host or Cluster menu.
Selection of a Host or a Cluster already serves as indication of the migration target.
When it comes to the migration source the user needs to:
- Login and add an external vCenter for the operation. This one can potentially be saved for future migrations but only within the scope of the current user session (this sensitive data is not persisted).
- Select any number of VMs for migration – these need to have the same power state.
- Select all other resources as standard migration goes.
This is a new “Cross vCenter Server export” migration type option in the existing migration wizard triggered from the “Migrate” action of the VM menu. The whole workflow follows the standard migration with only one difference: there is an additional page to select a saved or add a new external vCenter Server to be used as a migration target.
Native implementation vs. Fling
Since 7.0 U1c the native implementation is recommended and has a number of advantages:
- No setup required. The feature is built in the vCenter and needs no external agent or machine.
- Full set of compatibility checks on the selected resources at each step of the workflow wizards. This will automatically check the vMotion requirements and display errors and warnings to the user before starting the migration instead of failing halfway during the operation when TBs of data might have been transferred. Such capability of the vSphere Client is quite advanced and is missing in the Fling.
- Seamless UX integration in the existing UI.
Fling features which are not yet present in the native UI are Clone operation (already scheduled on the roadmap) and VM pattern renaming.
Overall, the Fling is still applicable and recommended for 6.x to 6.x migrations. Nevertheless, it should be phased out for 7.0 in favor of the native vSphere Client feature.
Major use cases
The Cross vCenter vMotion Fling has been commonly used as a quick path to workload mobility without increasing environment complexity:
- no need for ELM to do cross-site migration.
- skip the sequence of upgrades when moving to the latest vSphere version – instead users can migrate the workloads to the new vCenter and decommission the legacy one.
- no need for HLM when migrating to VMware Cloud.
The native support of Cross vCenter vMotion means the same use cases are now available out-of-the-box in vSphere and VMC environments:
Cross vCenter vMotion vs. HCX
The new UI feature is fully based on the existing vCenter APIs which handle the classic vMotion scenarios. As such, Cross vCenter vMotion UI is not a replacement for HCX.
Cross vCenter migration is recommended to use where possible given it does not require any setup. Such cases include:
- migrating VMs on VLAN
- migrating the whole overlay network where possible
- migrating VMs from an overlay network with manual/planned VM batching and downtime
Advanced migration needs like automatic batching, migration of large sized VMs, NSX-T to NSX-T migration, replication, etc. are addressed by HCX.
In Retrospective: Why did it take so long?
1. vSphere Client being “the vCenter Client”
Throughout its history spanning the Desktop Client (C#), vSphere Web Client (Flash) and vSphere Client (HTML) the vSphere UI has always been focused on management and monitoring of the current vCenter and its linked vCenters in the SSO domain. Whatever was external to them has not been considered as an area that the current vSphere UI instance should be concerned with.
Nevertheless, with development of more complex infrastructure, multi-site environments and hybrid cloud more and more capabilities require crossing the SSO domain boundary. Cross vCenter vMotion joins High Availability as the vSphere features working with external (alien) vCenters with more of these expected in the future.
2. Feedback loop & Usage data
The Cross-vCenter migration Fling has always been popular, receiving good feedback from customers actually using it in Production (despite its unsupported state). That said, it was never put high enough on the priority list – folks would agree it makes sense yet the final leap was getting delayed.
Apart from a nice UX and integrated workflow the introduction of the Client plugin to the Cross vCenter vMotion Fling brought one additional benefit which became a game-changer: Telemetry data. Just a few months after 3.0 fling release deployment numbers of the plugin were through the roof positioning this utility in the Top 15 of most used plugins – again, in spite of its unsupported status.
Productization from this point onwards was just a matter of time.
Moral of the story: if you like a utility or a feature give your feedback on all channels, suggest improvements and please keep your telemetry On! 🙂
Talking of feedback – your input, comments and ideas are very much appreciated and will be considered for future iterations of the Cross vCenter vMotion UI.
Please use any channel of choice, DM me or just comment in the section below.