WilliamLam.com

Preserving VM snapshot hierarchy across vCenter Servers

by // Leave a Comment

On occasion, you might find yourself needing to take multi-level VM snapshots for various testing or development purposes, not an uncommon task for IT administrators.

In the past, if you needed to move the VM and preserve its snapshot hierarchy, it was usually difficult and involved manual tasks to unregister the VM and copying its files to the destination environment.


At VMware Explore last year, I had a customer who shared a nice tidbit regarding this topic with me that I was recently reminded of. By performing a Cross vCenter vMotion (not clone), the VM snapshot hierarchy is automatically preserved.

You of course can use the vSphere API and PowerCLI to initiate a Cross vCenter vMotion OR you can easily perform this operation by using the Advanced Cross vCenter vMotion capability that is built right into the vSphere UI, which can also be useful if you need to quickly cold migrate some workloads from older vSphere releases.

After authenticating into my source vCenter Server which is running vSphere 7.0 Update 3o, I simply select my VM with snapshots and perform a migration (not clone) and in a few minutes, it is now running in my vSphere 8.0 Update 2 destination vCenter Server!

Does vCenter Server recycle VM MAC Addresses after Cross vCenter vMotion?

by // 7 Comments

I recently received a question from a customer who was concerned that after a VM has been migrated from one vCenter Server to another using Cross vCenter vMotion, that the original source VM MAC Address could potentially be recycled and re-used at a later point. Back in 2015, I actually wrote about this very topic and the concerns around VM MAC Address duplication after a Cross vCenter vMotion, which I highly encourage folks to check out if you have not seen this article already.

While re-reading the article, I realized that the article had primarily focused on vCenter Servers that were in Linked Mode or under the same vSphere Single Sign-On (SSO) domain and although I did mention the Cross vCenter vMotion across across different vSphere SSO domains scenario, it looks like the details were a tad bit light.

To quickly summarize, when a VM is migrated from a source vCenter Server to the designation vCenter Server, the VM's MAC Address is added to a MAC Address "block list" on the source vCenter Server. This ensures that the VM MAC Address will not be reallocated by the source vCenter Server which would cause a network conflict. This has been the default behavior since vSphere 6.0 and no additional configuration change is required by customers.

[Read more...]

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