With vSphere 6 adoption going up, the new features are helping our customers manage their environments better than ever before. vSphere Web Client is the most common way that these new features and enhancements are used, but sometimes the UI changes get lost in the discussion. The following is a deepdive into the changes and new pages in the vMotion workflow, and if you find this insightful, please let us know in the comments and we can do more posts! The credit for the below work goes to Dimitar Dimitrov, a member of the engineering team in Sofia, Bulgaria that felt passionate about showing our customers improvements to the UI.
Virtual machine migration in vSphere 6.0 Web Client
When VMware vMotion® was first introduced, it was one of the most exciting features in the virtualization world – it was the first live migration solution that provided the ability to migrate a running virtual machine from one vSphere host to another host, with no perceivable impact to the end user.
In the subsequent VMware vSphere® releases, the vMotion architecture continued to evolve, with Storage vMotion and then Enhanced (shared-nothing) vMotion, further increasing the flexibility and broadening the capabilities of virtual machine migration.
The vMotion feature in vSphere 6.0 is breaking yet more boundaries:
There is a number of articles explaining the requirements and specifics of the above enhancements, but there are much less and maybe even none articles about the user interface accompanying these enhancements in the vSphere Web Client.
The UI for virtual machine migration has also undergone significant changes, some of which are related to the new vMotion enhancements. Others have been introduced to enhance the existing user experience or address customer needs.
Roughly the UI changes can be grouped in three categories:
…migration workflow changes
…migration wizard page changes
…less visible wizard features
Migration workflow changes
After invoking the “Migrate…” action for a virtual machine, the new migration wizard opens and asks you to select a workflow.
The three workflows from the wizard in vSphere 5.5 are still present, even though there are some slight changes. The most interesting change is that now there are two different ways of changing both the compute and the storage of the migrated virtual machines.
The first approach is compute-centric, very similar to the way both compute resource and storage are being migrated in vSphere 5.5. First you pick a destination from an inventory tree of all available compute objects, then from a filtered list of all the related storage objects.
The second approach is storage-centric[i], analogous to the compute-centric approach, but with the roles of storage and compute being reversed. In this new workflow, storage selection is performed first from an inventory tree of all available storage objects. This is preferable if using a specific storage resource is more important than using a specific compute resource. Doing the same in vSphere 5.5 required checking the “Related Objects” tab of that storage resource and finding a destination compute object, and then going back into the migration wizard.
In both of these migration workflows, the first selection is performed through a tree-based component which purpose is to show the user all the potential compute/storage destinations. It’s even possible to have multiple vCenter Servers as the multiple roots of this component.
Here’s an example with the new tree-based page for storage selection:
And in both of these workflows, the next important selection is performed through a list-based component which purpose is to filter out the available selections with regard to the selection in the first step.
Here’s an example with the new list-based page for compute resource selection:
Migration wizard page changes
The new wizard adds four new pages and changes some existing ones.
We’ve already seen the tree-based storage page and the list-based compute resource page[ii]. There are two other entirely new pages in the wizard.
The first is a page for selecting a destination VM folder. The page is shown only for migrations across vCenter Servers[iii], and only if there is a choice to make, i.e. the destination datacenter contains at least one VM folder other than its own (the datacenter’s) built-in one.
The second is a page for remapping the VM networking of the migrated virtual machines (in order to cross the virtual switch boundary[iv]). This page is shown only when the compute resource of the migrated virtual machines is being changed[v], and it has two modes, similar to the list-based storage page.
“Basic” mode allows mapping a source network to destination network[vi] (so changing the VM networking of all the migrated virtual machines can be done with a single selection, if they use a single network prior to the migration), and its “Advanced” mode allows mapping virtual network adapter to destination network (so fine-grained remapping of each of the virtual network adapters of each of the migrated virtual machines to a different destination network is possible).
Aside from the entirely new pages, some other page-related changes have been introduced.
The most important of these changes is that resource pool and host selection have been collapsed into a single step[vii]. In order to do that, the tree-based compute resource page now shows the hosts under the clusters in the inventory tree, and the list-based compute resource page has a separate “Hosts” tab where both standalone and clustered hosts are shown[viii] (see the screenshot of the list-based compute resource page in the migration workflow changes section).
Smaller changes of this sort include allowing multiple vCenter Servers as roots in tree-based pages (in order to cross the vCenter Server boundary), hiding the vMotion priority page for Storage vMotion, changing the last, summary page to reflect the various other changes, et cetera.
Less visible wizard features
With the visible migration workflow getting more and more complex, expressing the user intent gets more and more complex too. The vSphere Web Client does a number of things behind the scenes the richest possible interaction without burdening the user too much.
The most important of these are:
Integration with DRS placement recommendations
Datastore mirror/stretched storage recognition
Preserving resource pool during intra-cluster host migrations
The first item addresses the fact that prior to vSphere Web Client 6.0, migrating both the compute resource and the storage of a live virtual machine into a DRS cluster (and some storage attached to it), required the user to manually pick a destination host within the cluster. Naturally, this often results in the selection of a suboptimal host from a DRS standpoint.
Now the user can just pick a DRS cluster/a resource pool in a DRS cluster and get a host placement recommendation when he reaches the last, summary page of the wizard, similar to the way Storage DRS recommendations are being used. The best recommendation gets applied automatically, and DRS faults are also displayed. It’s worth emphasizing that currently this holds true specifically for XvMotion (live migration of both compute resource and storage) of a single VM into a DRS cluster[ix].
The second item addresses the fact that registering the same shared storage in multiple datacenters will result in multiple datastore objects (the shared storage won’t be represented as a single datastore object within the whole inventory, but as multiple datastore “mirrors”, one for each datacenter, to which it was registered).
With vSphere 6.0, the vSphere Web Client will recognize if all the migrated virtual machines are currently residing on a datastore that has “mirrors” in other datacenters, and will show and allow selecting compute resources related to that datastore, as well as compute resources related to that datastore’s “mirrors” during the “Change compute resource only” workflow[x]. This means that if a virtual machine resides on a datastore backed by a NAS storage, also registered in another vCenter Server, even the “Change compute resource only” workflow can be used to perform a migration across vCenter Servers.
Other similar enhancements include picking a host behind the scenes in Cross vCenter scenarios[xi] in order to keep consistent user experience regardless of whether the migration crosses the vCenter Server boundary, or automatically populating virtual machine networking when some source networks are also available at the destination.
The UI for virtual machine migration had changed significantly in vSphere 6.0 in order to allow leveraging the ever-expanding capabilities of vMotion. While the latter has always been of utmost importance, achieving it while hiding complexity and promoting consistency is equally important for that area of the vSphere Web Client. Future work will continue to require increasing the expressive power of that interface and decreasing the amount of switches and knobs that the user needs to operate or keep in mind in order to perform virtual machine migrations.
[i] The new workflow has some limitations. For example, specifying disk provisioning type or VM storage policy, as well as custom storage placement per VM disk are still unsupported.
[ii] The list-based compute resource page is also used in the “Change compute resource only” workflow, which is a significant improvement. In vSphere 5.5, the analogous “Change host” workflow uses a tree-based page that shows practically all the compute resources in the inventory. As a result, the page can allow many obviously invalid choices, as the compute resources not related to the current storage of the migrated virtual machine are not filtered out.
[iii] VM folder selection is also relevant for migrations across datacenters within the same vCenter Server, so enabling the folder selection page in that scenario is also being evaluated.
[iv] Aside from enabling to cross the virtual switch boundary, adding a network reconfiguration step addresses a request raised by a number of customers.
[v] There are some additional conditions that should be satisfied: at least one of the migrated VMs should have a network adapter, none of the migrated VMs should be a secondary Fault Tolerance VM, and others.
[vi] Click on a row in the “Basic” mode of the network page for some additional info about the corresponding source network.
[vii] This change addresses a request raised by a number of customers.
[viii] Selecting both a resource pool and a host in that single compute resource selection step is sometimes required. In order to enable that, the vSphere Web Client relies on a placement API that can recommend host placement within a DRS cluster (or a resource pool under a DRS cluster). The integration with this API is examined in the last section of this article.
[ix] Integrating the DRS placement recommendations mechanism in other scenarios is also being evaluated, as there are multiple other cases where these recommendations can be employed, including even simultaneous host and datastore placement.
[x] The caveat here is that the migrated virtual machines should reside on a single “stretched” datastore. If multiple datastores are involved, finding out all their mirrors and calculating the sets of clusters/hosts/resource pools/vApps that are related to the correct sets of mirrors is too expensive and heavy of an orchestration logic for the vSphere Web Client.
[xi] Observant users will notice that in such scenarios the last, summary page of the wizard will show a “Host” row containing the host that was automatically picked, even though no explicit host or recommendation selection have been done.
