WilliamLam.com

How to split vCenter Servers configured in an Enhanced Linked Mode (ELM)?

by // 22 Comments

An interesting question that came up on the VMTN forum the other day (thanks to Andreas Peetz for sharing via Twitter) was how to split two vCenter Servers configured in an Enhanced Linked Mode (ELM)? Due to an organization changes in the customers environment, they needed to separate out their two vCenter Servers and run them independently of each other. Although this may sound like an rare event, I have actually seen this use case come up several times now which maybe from a business unit restructuring, spinning out or selling off company assets which then requires the customer to split their existing vCenter Servers that is configured with ELM.

Below is a diagram depicting an example where the original source environment (left) which is composed of two vCenter Servers and two external Platform Services Controller (PSC) configured in an ELM and the desired destination environment (right) which are two separate vCenter Server instances no longer configured in ELM.


The solution to this problem is actually pretty straight forward and leverages the existing vCenter Server and/or Platform Services Controller (PSC) "decommission" workflow. Rather than decommissioning the nodes, we are just simply keeping them around. Below are the instructions on how to achieve this outcome.

UPDATE (05/31/22) - I was recently made aware of the following VMware KB 2106736 article that provides official guidance for splitting/unregistering your vCenter Server from ELM. This should be followed as the officially supported method

UPDATE (01/28/19) - As of vSphere 6.7 Update 1, splitting an Enhanced Linked Mode (ELM) configuration is now supported by using the repointing workflow provided by the enhanced cmsso-util tool.

Disclaimer: Although this solution uses an existing supported workflow, this particular use case has not been tested by VMware. As such, this would not be officially supported by VMware until the appropriate testing has been done by our Engineering teams. One potential option in the short term if you are looking for support from VMware is to file an RPQ request through your VMware account team.

[Read more...]

vSphere 6.5b prevents vSphere Web Client logins for users w/o VC permissions

by // 8 Comments

A patch update was just released for vCenter Server 6.5, dubbed vSphere 6.5b. While glancing through the release notes, I caught one interesting "resolved issue" which I thought was worth sharing.

Users with no vCenter Server permissions can log in to the vSphere Web Client

Users without permissions can log in to the vSphere Web Client. Users can click the menu options, but no inventory is displayed.

Users with no permissions can no longer log in to the vSphere Web Client.

To enable the login, set the allow.user.without.permissions.login = true property in the webclient.properties file.

This particular behavior has been something that has confused a few customers and has been asked about since the introduction of vCenter Single Sign-On (SSO) service. The issue or rather the confusion is that prior to the SSO service, vCenter Server handled both authentication as well as authorization.

With SSO, authentication was no longer being handled by vCenter Server and this meant that even if you had no permissions in vCenter Server but you could authenticate to SSO (especially common when Active Directory is configured), you would still be allowed to login to the vSphere Web/H5 Client.


Although vCenter Server would does the right thing and does not display any inventory if you do not have any permissions, it was still not a desired behavior in addition to the confusion it caused. I was pleasantly surprised to see that we have changed this default behavior by disallowing logins to the vSphere Web/H5 Client if a user has no VC permissions. Below is the message you will receive if you try to login without VC permissions.


If you wish to revert to the original behavior, you can do so by simply adding the allow.user.without.permissions.login = true setting into the vSphere Web/H5 Client configuration file (webclient.properties) and restart the vSphere Web/H5 Client service. I think many of our customers will appreciate this fix as well as the new default behavior!

Default hashing algorithm changed in OVFTool 4.2 preventing OVF/OVA import using vSphere C# Client

by // 11 Comments

After upgrading my home lab recently to vSphere 6.5, I also updated some of the related utilities such as the various SDKs and CLIs. One of the CLIs that I had updated was the latest version of OVFTool which is now at 4.2. I use OVFTool extensively to automate various Virtual Machine deployments (import/export). While testing out a new OVA that I had been working on, I needed to verify that it also worked with previous release of vSphere like vSphere 6.0 Update 2. I happen to have the vSphere C# Client open and connected to a vCenter Server and when I tried to import the newly created OVA, but it failed with the following error message:

The following manifest file entry(line1) is invalid: SHA256

screen-shot-2016-11-17-at-7-37-47-am
I was pretty surprised by this since I went through this exact same workflow a couple of days ago without any problems. The only change that had happened was OVFTool and error seems to indicate an issue with the hashing algorithm. I ran OVFTool again using just the --help option to check what the default SHA hashing algorithm was, it was SHA256. I then compared that to an older version of OVFTool and it looks like the default had changed from SHA1 to SHA256.

From a security standpoint, this is a positive change as SHA1 is no longer considered a secure hashing algorithm and a stronger version should be used. It also turns out that the vSphere C# Client can only support SHA1 which is why I received the error after upgrading to the new version of OVFTool. Luckily, this is NOT a problem when using the vSphere Web Client or the vSphere HTML5 Client and only affects the vSphere C# Client. If you do need to use the vSphere C# Client for importing OVF/OVAs exported from the latest version of OVFTool, the workaround is quite simple, just override the default hashing algorithim when exporting by adding the additional CLI option:

--shaAlgorithm=sha1