WilliamLam.com

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

02.27.2017 by William Lam // 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

02.27.2017 by William Lam // 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.

Quick Tip - Connect-OMServer throws The request was aborted: Could not create SSL/TLS secure channel.

02.23.2017 by William Lam // 3 Comments

While doing some work with PowerCLI and vRealize Operations Manager (vROps), I ran into the following error message when trying to connect to my vROps instance using PowerCLI:

Connect-OMServer : 2/17/2017 5:27:50 AM Connect-OMServer The request was aborted: Could not create SSL/TLS secure channel.
At line:1 char:1
+ Connect-OMServer -Server vrops.primp-industries.com -User admin -Password VMware ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (VMware.VimAutom...tionServiceImpl:OMConnectionServiceImpl) [Connect-OMServer], OMException
+ FullyQualifiedErrorId : OM_ConnectivityServiceImpl_ConnectOMServer_ByUserNameAndPassword_ConnectError,VMware.VimAutomation.vROps.Commands.Cmdlets.ConnectOMServer

Although there were some hits on Google, none of the suggestions has worked. I had also found that this issue was only happening in one of my lab environments which was running Windows 2008 R2, for my other system which had Windows 8.1, the issue was not observed.

I had reached out to the PowerCLI Engineering team and it looks like the issue is due to a change in the hashing algorithm (SHA512) that vROps uses for its SSL Certificates. When using TLS 1.2, SHA512 is not supported by default. The fix is to simply install the following patch here which will resolve the problem.