Yesterday while reading about Enhanced linked mode I stumbled across this blogpost by William Lam where he have demonstrated how to split vCenters which are configured in linked mode.

I thought to give it a try in my lab also as these days I am playing around PSC’s and repointing, ELM things etc.

In my lab I have 2 PSC nodes and 2 vCenter server nodes each pointing to one of the PSC. Both PSC nodes are in same SSO domain/site

Both PSC are replicating to each other. Also I have verified that I do not have any stale entries for any PSC nodes from my existing lab activities.… Read More

Linked Mode was first introduced in vSphere 4.x and it has come a long way with vSphere 6.0.

Enhanced linked mode (ELM) allows administrators to manage multiple vCenter servers from one place using vSphere Web client. vCenter servers in ELM can replicate roles, permissions, licenses and policies between them.

ELM also enables Cross vCenter vMotion i.e you can migrate virtual machines across clusters on separate vCenter instances; subject to network limitations.

Previously linked mode configuration was only possible with Windows based VC as ADAM was used as the replication engine between the VC’s.

ELM in vSphere 6.0 don’t rely on ADAM anymore but have its own replication system which is a multi-master replication technology also called VMDir based on Open LDAP which means replication now works across Windows vCenter as well as vCenter appliances.

Note: All vCenters configured in ELM can be managed only from Web Client. If you are using vSphere C# client then you can only manage that vCenter server to which you are connected.… Read More

Prior to vSphere 6.0 U1 it was only possible to repoint vCenter Server which was deployed with external PSC to another PSC in same SSO domain. With vSphere 6.0U1, you can now reconfigure embedded vCenter server deployment to an external deployment.

Components of PSC which resides in embedded node are demoted and the repoints vCenter server to an external PSC node which resides in the same Single Sign On (SSO) domain as the source embedded node.

VMware made it possible by introducing an utility named cmsso-util and there are two main uses for cmsso-util:

Reconfigure

• Reconfigure is used when you want to point your vCenter server from embedded PSC to an externally deployed PSC.
• The source and target PSC should be in same SSO domain.

Repoint

• This is used when a vCenter is deployed with external PSC and you have one more external PSC and you want to move vCenter from source PSC to target PSC.

VMware introduced SSO with vSphere 5.1 and over the release SSO has matured very much. SSO can now be connected to multiple authentication domains, like active directory and ldap, so that it can exchange authentication for tokens which are used to access multiple vSphere services.

An Identity Source is a collection of user and group data, which is stored in either Active Directory, OpenLDAP or locally in the OS.

At the time of PSC/vCenter deployment we create one identity source (SSO domain) and after vCenter installation is completed, only the users defined under this SSO domain or localos can login to vCenter. This identity source is internal to vCenter SSO.

A SSO administrator can add additional identity sources for centralized authentication, can define the default identity source, and create users and groups in the default identity source.

In this post we will focus on below tasks:

• Define Identity sources for single sign-on.

In this post we will learn how to decommision/remove a PSC from SSO domain. I am covering steps needed for VCSA in this post. Steps for a Windows based vCenter server are very similar and is explained in VMware KB-2106736.

Why I need to do so?

In my lab I was doing a lot of new things with PSC deployments and repointing my vCenter server from one PSC to other. If you are new to how to repoint a vCenter server amongst PSC’s, please read below 2 articles:

1: How to repoint vCenter Server 6.x between External PSC within a site

2: Repointing vCenter Server 6.0 to External PSC’s across sites

At present I have 3 PSC’s namely psc02.alex.local,psc03.alex.local and psc03.alex.local. I have one vCenter server which was originally deployed with psc02 as external psc. First I moved my vCenter server from psc02 to psc03 (they were in same domain/site) and then I moved VC from psc03 to psc04 (they were in same domain but different site)

You can see in output of below command that which PSC is replicating to which other PSC

In my last post I have demonstrated how to move a vCenter server from one PSC to another. In this article we will learn to repoint vCenter Server 6.0 between Platform Service Controllers (PSC) which are in same domain but different sites.

Before vSphere 6.0 U1, it was not possible to repoint vCenter server amongst PSC’s which were not in same site (but being in same domain). With vSphere 6.0 U1, VMware made this possible by introducing a new utility called cmsso-util. 

VMware KB-2131191 article outline the steps for achieving this goal.The steps outlined in the KB are for vCenter server with external PSC deployment architecture.

Note: If you have an embedded vCenter 6.0, then you can use cmsso-util to change embedded deployment model to an external PSC model. The old PSC will be decommissioned during this process. Go ahead with this configuration only if  you have no plans for using your old PSC again.… Read More

In this post we will look into how to configure Core Dump settings on Esxi hosts. But before doing that lets talk a bit about what is core dump.

What is Core Dump?

A core dump is the state of working memory of an Esxi host in the event of host failure like Purple Screen Of Death aka PSOD. In the event of PSOD the state of the VMkernel Memory is sent to the server where where dump collector service is running. This server is typically your vCenter server.

Core dumps information are very important when it comes to identifying and troubleshooting the issue which made the ESXi host to show a purple screen.

By default, a core dump is saved to the local disk. You can use ESXi Dump Collector to keep core dumps on a network server for use during debugging. The core Dump resides in a Diagnostic partition and in-order to create a partition we require atleast 100 MB of free space either locally or remotely available disks.… Read More

In this post we will learn how to configure Esxi-6 hosts to send the logs to a centralized syslog server.

Purpose of configuring syslog server?

As per VMware KB-2003322

ESXi 5.0 and higher hosts run a syslog service (vmsyslogd) that provides a standard mechanism for logging messages from the VMkernel and other system components. By default in ESXi, these logs are placed on a local scratch volume or a ramdisk.

To preserve the logs further, ESXi can be configured to place these logs to an alternate storage location on disk and to send the logs across the network to a syslog server.

Retention, rotation, and splitting of logs received and managed by a syslog server are fully controlled by that syslog server. ESXi cannot configure or control log management on a remote syslog server.

How to configure Esxi hosts for centralized logging?

There are various ways to configure syslog settings on Esxi hosts.… Read More