WilliamLam.com

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

by // 34 Comments

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 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.

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.

[Read more...]

Cross vCenter Workload Migration Fling v3.1

by // 20 Comments

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

by // 21 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 (11/07/21) - Thanks to Robert Cranedonk, it looks like you can now also vMotion across different NSX-T Logical Switches by adding vCenter advanced setting called  config.vpxd.network.allowVmotionBetweenLogicalSwitches and set the value to true.

UPDATE (01/02/21) - If you are running vSphere 7.x, an additional advanced setting must be configured called config.vmprov.enableHybridMode and set the value to true. For more details, you can refer to this VMware KB 79446. Thanks to reader Marc Alumbaugh for sharing this finding!

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.

[Read more...]