ExVC-vMotion

Cross vCenter Workload Migration Fling v3.1

01/22/2020 by William Lam 1 Comment

Here is a small update to the Cross vCenter Workload Migration Fling which includes a couple of commonly requested features along with some bug fixes.

What's New in v3.1

Support for disk format conversion between Thick (Lazy Zeroed), Thick (Eager Zeroed) and Thin provisioning
Support for VM rename pattern for Clone operation
Fixed duplicated network selection when performing bulk migration
Fixed startup failure when a new home vCenter is specified as a command line argument

vSphere HTML5 and Standalone UI Client Support

In our 3.0 release, we added support for a native vSphere HTML5 (H5) Client experience which leverages new remote plugin framework that was introduced in vSphere 6.7 Update 1 and enables customers who prefer to use the H5 Client for their day to day use to also take advantage of the Cross vCenter Workload Migration Tool directly from the same UI. However, the addition of this new consumption UI created some confusion as some folks assumed this was the only mechanism. As stated in the release notes, we support both the new H5 UI as well as the standalone UI which many customers have been using for quite some time.

I suspect the confusion was due to the new CLI syntax which now requires specifying a vCenter Server endpoint to register. It is true that if you wish to use the new H5 Client integration, you will need to have a vSphere 6.7 Update 1 environment and provide credentials to that "home" vCenter Server. However, if you do not wish to use the H5 Client and you wish to use the old standalone client, you simply omit the vCenter Server registration details and the standalone client will work. In fact, even if you decide to use the H5 Client UI, you can always use the standalone client as that is the actual backend of the system.

Option 1: vSphere H5 Client Plugin

The following command will register the Cross vCenter Workload Migration Fling plugin to the specified vCenter Server:

java -jar xvm-3.1.jar --vcenter.fqdn=VCENTER-IP-OR-FQDN --vcenter.user=ADMIN-USER --vcenter.pass=ADMIN-PASSWORD

You will need to logout and then log back in to see the plugin which is located under "Menu" as shown in the screenshot below.

Option 2: Standalone UI Client

The following command will start the Cross vCenter Workload Migration Fling in standalone mode:

java -jar xvm-3.1.jar

You can then access the standalone client by opening a browser to localhost and port specified (default is 8443). You can always access the plugin locally whether you are using Option 1 or 2.

vMotion across different VDS version between onPrem and VMC

09/19/2018 by William Lam 10 Comments

For those of you who have attempted a vMotion (whether that is within a vCenter Server or between different vCenter Servers (including across SSO Domains), if the VM is running on a Distributed Virtual Switch (VDS) and the version of the VDS is not the same between the source and destination (VDS 6.5 to VDS 6.7), the operation will fail with the following error message (UI and API):

Currently connected network interface 'Network adapter 1' cannot use network 'DVPG-VM-Network (VDS-67)', because the destination distributed switch has a different version or vendor than the source distributed switch.

This behavior is no different on VMware Cloud on AWS (VMC) or at least, I thought it was, until I recently learned about a really neat feature that was introduced in the VMC 1.4p2 release, here is a snippet from the release notes:

Cross VDS version vMotion Compatibility
With this advanced configuration option enabled, bi-directional vMotion between on-premises and VMware Cloud on AWS can be achieved across different virtual distributed switch (VDS) versions (greater than or equal to version 6.0). This must be enabled on the on-premises vCenter.

It turns out there is actually a way to allow vMotions across different VDS versions, this is important for VMC because the software stack will always be using a newer version than what we ship to our onPrem customers. However, due to this limitation, we could not benefit from the latest VDS version but had to default it to VDS 6.0 to ensure that customers could migrate their workloads. The advanced setting mentioned in the release notes allows us to disable the strict compatibility check which is performed on the destination vCenter Server when a vMotion is initiated, this setting is now enabled by default on the VMC vCenter Server which is why you can perform migration across different VDS without having to do anything special on your onPrem vCenter Server.

UPDATE (10/16/18) - With the release of vSphere 6.7 Update 1, customers can now also vMotion VMs from on-prem running on a VDS to VMC with NSX-T N-VDS.

Resource Pools, Folders & VMC now supported with Cross vCenter vMotion Utility Fling

07/18/2018 by William Lam 1 Comment

Many of you are already familiar with the Cross vCenter vMotion Utility, which was released as a Fling last year. In fact, a number of you have even shared your VM migration numbers, many of which are quite impressive (e.g. 5-10K VMs). Not only are the number of production VMs significant, but I also learned the duration of customer migration projects, such as datacenter evacuation, was able to complete significantly faster with the help of this tool.

Although v2.1 was just recently released, Vishal, the lead developer is constantly looking for ways to improve the tool. Most recently, we had a few customers ask for supporting additional placement targets such as vSphere VM Folders and Resource Pools. Customers often use VM Folders for organization purposes but also as a way to manage permissions and of course resource management with the use of Resource Pools (not for organization purposes ;)). These two stand alone feature are quite useful on their own, but they are also a building block to allow us to support migrating workloads to and from VMware Cloud on AWS (VMC) which we have received requests for as well. VMC has a restrictive permission model and customer workloads must be placed in a specific VM Folder and Resource Pool, both of which was not initially supported with the Cross vCenter vMotion Utility.

With the latest v2.2. release, customers will now have the ability to optionally specify a target Resource Pool and/or VM Folder by enabling an Advanced settings option at the upper right hand corner of the tool as shown in the screenshot below.

Below is a screenshot of vMotion'ing 3 running PhotonOS VMs from onPrem environment to my VMC's SDDC. The Fling supports both hot and cold relocate, however for vMotion to work you will need to ensure that your source vCenter Server (including ESXi hosts) are running vSphere 6.7 and the VM is configured with the new Per-VM EVC (requires vHW 14) which can be configured in the vSphere H5 Client.

Give the latest Fling a try and let us know what you think, if you have any feedback or request, feel free to leave a comment on the Fling page.

Bulk VM Migration using new Cross vCenter vMotion Utility Fling

12/20/2017 by William Lam 50 Comments

Over the last few years, I have spoken to a number of customers who have greatly benefited from the ability to live migrate Virtual Machines across different vCenter Servers that are NOT part of the same vCenter Single Sign-On (SSO) Domain, which I had first shared back in 2015 here and here. This extended capability of the Cross vCenter vMotion feature enabled customers to solve new use cases that were challenging, especially for scenarios such as Datacenter migration, consolidation or even migrating existing workloads from their current environment into new SDDC deployments such as VMware Cloud Foundation (VCF) as an example.

Although customers could initiate Cross vCenter vMotions using the vSphere API which included PowerCLI (Move-VM cmdlet was enhanced in 6.5, more details here), the overall experience was still not as friendly. This was especially true for customers who may only have a small number of VMs to migrate and prefer a UI-based interface rather than an API/CLI only option. In addition, for large number of VM migrations, there was not an easy way to perform "batch" VM migrations that was easily consumable for folks who may not have a strong background in Automation or the vSphere APIs.

Today, I am pleased to share a new VMware Fling called the Cross vCenter Migration Utility that will help simplify the consumption of initiating VM migration(s) across different vCenter Servers, especially between dispart SSO Domains where a graphical interface was not available. This solution was developed out of our VMware Cloud Foundation (VCF) Engineering group which is part of the Integrated Systems Business Unit at VMware. I had spoken to a number of folks within the group about the extended Cross vCenter vMotion capability and I was super excited when I heard they were planning to release this tool as a Fling and make it available to all customers. I was fortunately to have been involved in the project alongside the Engineering lead Vishal Gupta and we are excited that we can finally talk about this project and see how customers will be using this new tool.

UPDATE (05/07/18) - The Fling has just been updated to 2.0 with the following new features:

Added support to select individual host as the placement target
Added support for migrating VMs with shared datastore
Added clone functionality in addition to relocate
Added resource summary details for placement targets
Added a prompt to verify site thumbprint during SSL verification
Added a link to refresh vm list in the inventory view
Updated REST APIs to add operation type parameter

Cross vCenter Migration Utility Fling

Cross vCenter vMotion Requirements: KB 2106952

Download Fling here

Features

Completely UI-driven workflow for VM migration
Provides REST API for managing migration operations
Works with vCenter not part of the same SSO domain
Supports both live/cold migration of VMs
Batch migration of multiple VMs in parallel
Flexible network mappings b/w source and destination sites

When to use Move-VM cmdlet vs xMove.ps1 script for performing Cross vCenter vMotions?

10/26/2017 by William Lam 10 Comments

Since publishing my Automating Cross vCenter vMotion between the same and different SSO Domain article back in early 2016, I have had a large number of customers reach out to me and share their success stories of allowing them to perform datacenter migrations to consolidating vCenter Servers all due to this awesome capability that was introduced in vSphere 6.0. In fact, many of the VM migration numbers were in the 4,000 to 8,000+ range which completely blew me away. It was great to hear from customers on how the xMoveVM.ps1 script had enabled them to do things that was simply not possible before, especially without impacting their workloads.

I still get pinged on a regular basis from customers about using my script and one thing that surprises many customers when I mention to them that this functionality has already been ported over to the native Move-VM cmdlet that was introduced with the PowerCLI 6.5 release. This had always been my original intention to provide an example using our vSphere API and enabling our customers in the short term and working with Alan Renouf and the PowerCLI team to get this folded back into the official PowerCLI cmdlets. This means, you no longer have to use my script for basic Cross vCenter vMotions whether that is between the same or different SSO Domain, which is quite nice as the number of user inputs is significantly reduced by using Move-VM cmdlet.

UPDATE (01/01/2018) - One additional option is the recently released Cross vCenter vMotion Utility Fling. For more details, please have a look at the blog post here.

Lets take a look at an example below where I have a VM called TestVM-1 which is residing in vcenter65-1 and I want to vMotion it to vcenter65-3:

With just 5 simple and easy to read lines of PowerCLI, you can perform this operation:

Uniquely identifying VMs in vSphere Part 3: Enhanced Linked Mode & Cross VC-vMotion

07/11/2017 by William Lam 4 Comments

Back in 2012, I had published two articles which provides details and guidance on how to uniquely identify a Virtual Machine for both a vSphere and/or vCloud Director environment. The primary use case for this information was for customers or partners who have developed their own provisioning solution which requires them to track their VM assets throughout their lifecycle, usually in some sort of configuration management database (CMDB).

Although these articles are almost 5 years old, the content is still very relevant today and I still continue to reference them both with customers, partners and even some of our internal R&D folks. Most recently, I had a question about whether the guidance in these article were still applicable or whether they would be impacted by some of the new VMware technologies and capabilities that had been introduced since writing those articles such as Enhanced Linked Mode (ELM) and Cross vCenter vMotion (xVC-vMotion).