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

Using the vSphere API in vCenter Server to collect ESXTOP & vscsiStats metrics

by // 1 Comment

Back in 2013, I wrote two articles here and here on how to use the Service Manager API that was introduced in vSphere 5.1 to remotely collect ESXTOP and vscsiStats metrics. At the time, I was told that this API was only available when connecting directly to an ESXi host using the vSphere API. This was still a huge improvement over the previous method which basically required customers to run the commands locally. For ESXTOP, there was resxtop but it was not available for all platforms and some customers still prefer to use the ESXi Shell's version. When I had learned about this API, I was really hoping I could collect both ESXTOP & vscsiStats metrics using vCenter Server which would remove the need to have direct connectivity to each ESXi host.

Last week, an Engineer came across one of my blog posts related to the Service Manager APIs which helped him with a problem he was trying to solve. In the email conversation, I then came to learn from the Engineer that the the Service Manager API can be used from vCenter Server and going directly to the ESXi host was not necessary. It turns out that the QueryServiceList() method which accepts an array of "location" expects a special keyword prefix appended to the list of ESXi hosts that you wish to use the local Service Manager instances on.

The special keyword prefix is "vmware.host." and this is appended to either the Hostname or IP Address of the ESXi hosts being managed by the vCenter Server. For example, in my environment I have an ESXi host (192.168.1.50) that is managed by my VC and so the location string for that host should be "vmware.host.192.168.1.50". If the method was successfully called, you should get back the two service instances for ESXTOP and vscsiStats for each of the ESXi hosts where you can then perform the metric collection.

I have created two sample pyvmomi scripts which exercises the Service Manager API for ESXTOP and vscsiStats:

Note: For more details on how to use Service Manager API to collect ESXTOP and vscsiStats, please refer to this post here and here.

[Read more...]

vCenter Server Database retention purge schedule

by // 5 Comments

The size of your vCenter Server Database is largely based on the amount events/tasks and performance statistics that you retain for your vSphere environment. You can view and edit these settings by going to the vCenter Server "General" settings as shown in the screenshot below (documentation here and here):

vcenter-server-data-retention
A common misconception when changing any one of these retention policies, especially when decreasing the amount of data to be retained, is that the existing data would be purged immediately to comply with the new settings. This is actually not the case and for data that is applicable for removal, there are a set of purge jobs that run on a specific schedule to perform the clean up. Below is the schedule in which these database jobs run for each of the data types:

Performance Statistics:

  • Daily Level - Once every 30 minutes starting at 00:00 (e.g. 00:00, 00:30, 01:00, etc.)
  • Weekly Level - Once every 2 hours starting at 01:45 (e.g. 01:45, 03:45, 05:45, etc. )
  • Monthly & Yearly Level - Once a day at 02:15

Events and Tasks:

  • Once a day at 00:15

For customers that are looking for immediate results and reclaim storage from within their VCDB, you can take a look at the following VMware KB 1025914 which outlines the specific instructions. This can especially be useful if you are looking to perform a Windows vCenter Server to vCenter Server Appliance Migration and wish to reduce the overall amount of data that is being copied over from your existing environment.