WilliamLam.com

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

by // 7 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).

[Read more...]

Cross vCenter Server operations (clone / migrate) between versions of vSphere 6.x

by // 7 Comments

When cross vCenter Server operations such as clone and migrate was first introduced in vSphere 6.0, it required that both the source and destination vCenter Server (includes ESXi hosts) to be running the same vSphere version. With the release of vSphere 6.5, this base requirement still holds true (e.g. vSphere 6.5 for both source and destination), especially when performing these operations using the vSphere Web Client where mixed-vSphere versions is not supported outside of a rolling upgrade.

Having said that, it is possible and supported to clone or migrate a VM across different versions of vSphere 6.x, for example a vSphere 6.5 and a vSphere 6.0 Update 3 environment. This can be accomplished by performing a xVC-vMotion or xVC-Clone operation using the vSphere API. For the the xVC-vMotion use case, I have extensively written about it here and here and with PowerCLI 6.5r1, the Move-VM cmdlet has even been updated based on my feedback to support this capability natively. Furthermore, you can even perform these operations across completely different vCenter Single Sign-On Domains, which enables a new level of mobility for your VMs and access to resources of independently deployed vCenter Server instances.

UPDATE (11/01/17) - The following VMware KB 2106952 has just been updated to reflect what is officially supported in terms of Cross vCenter Operations ( Clone / Migrate) across different versions of vSphere. The matrix in the KB reflects what has been tested by Engineering and one thing you may notice is that Cross vCenter vMotion/Clone from vSphere 6.x to vSphere 6.5 is only supported when running at least vSphere 6.0 Update 3. After speaking with the PM, the reason for this change is that pre-vSphere 6.0 Update 3, there were no pre-checks in the code to prevent Cross vCenter Operations for un-supported target hosts such as ESXi 5.5, which could lead to poor user experience as well as undefined failure scenarios. In addition, vSphere 6.0 Update 3 also includes additional enhancements to properly clean up failed provisioning operations which will make Cross vCenter Operations much more robust. Due to these reasons, though it is possible to perform Cross vCenter vMotion from earlier versions, it will not be officially supported. I have also updated my summarized table below to reflect what is in the VMware KB, but please use the KB as your official source of truth for what VMware supports.

To help make sense of the different combinations of vMotions and cloning operations, below are a few tables to help outline what is possible and supported today.

vMotion

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported N/A
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Cold Migrate

Source vCenter Server Destination vCenter Server Supported UI or API
vSphere 6.0 vSphere 6.0 Yes UI and API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 Possible but Not Supported API
vSphere 6.0 Update 3 vSphere 6.5 Yes API
vSphere 6.5 vSphere 6.5 Yes UI and API
vSphere 6.5 vSphere 6.x No No
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Clone

Source vCenter Server Destination vCenter Server Supported  UI or API
vSphere 6.0 vSphere 6.0 Yes UI and  API
vSphere 6.x (pre 6.0 Update 3) vSphere 6.5 No N/A
vSphere 6.0 Update 3 vSphere 6.5 No N/A
vSphere 6.5 vSphere 6.5+ Yes UI and API
vSphere 6.5 vSphere 6.x No N/A
vSphere 6.5+ VMware Cloud on AWS Yes UI and API
VMware Cloud on AWS vSphere 6.5+ Yes UI and API

Virtual Networking Migration

Source Type Destination Type Supported
VDS VDS Yes
VDS VSS No
VSS VSS Yes
VSS VDS Yes

Note1: vMotioning and/or cloning of VMs which uses the new vSphere Encryption feature introduced in vSphere 6.5 is not supported.

Note2: "Compute" only xVC-vMotion insufficient space issue has now been resolved with vSphere 6.0 Update 3, see this post here for more details.

Note3: xVC-vMotion is not supported on 3rd party switches as we can not checkpoint the switching state.

Here are some additional xVC-vMotion and vMotion articles that may also useful to be aware of:

Quick Tip - vSphere 6.0 Update 3 resolves "Compute" only Cross-vCenter vMotion operation

by // Leave a Comment

Previously when a "Compute" only Cross-vCenter vMotion (xVC-vMotion) was initiated, which only migrates the VMs compute from one vCenter Server to another while maintaining its current storage configuration, an insufficient space error may be thrown under certain conditions. This behavior was due to the way vCenter Server used to calculate the available space on the destination vCenter Server.

Prior to vSphere 6.0 Update 3, vCenter Server used the Managed Object Reference (MoRef) ID of the vSphere Datastore determine whether the source and destination was the same. Even if you have the exact same vSphere Datastore mounted in both the source and destination vCenter Server, there was a good chance the MoRef ID will be different which then causes this calculation to occur. Now, the "insufficient space" error only occurs IF, the free space on the current vSphere Datastore is less than the size of the VM to be migrated which is why this behavior was only observed in some environments. Some customers workaround the problem by simply freeing up enough capacity which then allowed them to perform the operation.

The good news is this has now been resolved in the latest vSphere 6.0 Update 3 release which came out last Friday and has been outlined as one of the resolved issues in the release notes:

  • Attempts to perform an exclusive compute resource cross vCenter vMotion might fail.
    When a VM is migrated using vMotion or cold migrate from a vCenter to another vCenter and space available on datastore is less than size of the Virtual Machine Disk (VMDK), an error similar to the following is displayed:
    insufficient space

Rather than using the MoRef ID to determine if the vSphere Datastore is the same in both the source and destination vCenter Server, it is now using the datastore URL path. This means, if you want the correct behavior for a "Compute" only xVC-vMotion, you should ensure that the vSphere Datastore is mounted using the same name in both the source and destination vCenter Server.