vSphere Cluster Services (vCLS) is activated by default and runs in all vSphere clusters. vCLS ensures that if vCenter Server becomes unavailable, cluster services remain available to maintain the resources and health of the workloads that run in the clusters. vCenter Server is still required to run DRS and HA.

vCLS is activated when you upgrade to vSphere 7.0 Update 3 or when you have a new vSphere 7.0 Update 3 or later deployment. vCLS is upgraded as part of vCenter Server upgrade.

vCLS uses agent virtual machines to maintain cluster services health. The vCLS agent virtual machines (vCLS VMs) are created when you add hosts to clusters. Up to three vCLS VMs are required to run in each vSphere cluster, distributed within a cluster. vCLS is also activated on clusters which contain only one or two hosts. In these clusters the number of vCLS VMs is one and two, respectively.

New anti-affinity rules are applied automatically. Every three minutes a check is performed, if multiple vCLS VMs are located on a single host they will be automatically redistributed to different hosts.

Table 1. Number of vCLS Agent VMs in Clusters
Number of Hosts in a Cluster Number of vCLS Agent VMs
1 1
2 2
3 or more 3

vCLS VMs run in every cluster even if cluster services like vSphere DRS or vSphere HA are not activated on the cluster. The life cycle operations of vCLS VMs are managed by vCenter Server services like ESX Agent Manager and Workload Control Plane. vCLS VMs do not support NICs.

A cluster activated with vCLS can contain ESXi hosts of different versions if the ESXi versions are compatible with vCenter Server. vCLS works with vSphere Lifecycle Manager clusters.

Monitoring vSphere Cluster Services

You can monitor the resources consumed by vCLS VMs and their health status.

vCLS VMs are not displayed in the inventory tree in the Hosts and Clusters tab. vCLS VMs from all clusters within a data center are placed inside a separate VMs and templates folder named vCLS. This folder and the vCLS VMs are visible only in the VMs and Templates tab of the vSphere Client. These VMs are identified by a different icon than regular workload VMs. You can view information about the purpose of the vCLS VMs in the Summary tab of the vCLS VMs.

You can monitor the resources consumed by vCLS VMs in the Monitor tab.

Table 2. vCLS VM Resource Allocation
Property Size
VMDK size 245 MB (thin disk)
Memory 128 MB
CPU 1 vCPU
Hard disk 2 GB
Storage on datastore 480 MB (thin disk)
Note: Each vCLS VM has 100MHz and 100MB capacity reserved in the cluster. Depending on the number of vCLS VMs running in the cluster, a max of 400 MHz and 400 MB of capacity can be reserved for these VMs.

You can monitor the health status of vCLS in the Cluster Services portlet displayed in the Summary tab of the cluster.

Table 3. Health status of vCLS
Status Color Coding Summary
Healthy Green If there is at least one vCLS VM running, the status remains healthy, regardless of the number of hosts in the cluster.
Degraded Yellow If there is no vCLS VM running for less than 3 minutes (180 seconds), the status is degraded.
Unhealthy Red If there is no vCLS VM running for 3 minutes or more, the status is unhealthy in a DRS enabled cluster.

Maintaining Health of vSphere Cluster Services

vCLS VMs are always powered-on because vSphere DRS depends on the availability of these VMs. These VMs should be treated as system VMs. Only administrators can perform selective operations on vCLS VMs. To avoid failure of cluster services, avoid performing any configuration or operations on the vCLS VMs.

vCLS VMs are protected from accidental deletion. Cluster VMs and folders are protected from modification by users, including administrators.

Only users which are part of the Administrators SSO group can perform the following operations:

  • ReadOnly access for vCLS VMs
  • Console access to vCLS VMs
  • Relocate vCLS VMs to either new storage, compute resource or both using cold or hot migration
  • Use tags and custom attributes for vCLS VMs

Operations that might disrupt the healthy functioning of vCLS VMs:

  • Changing the power state of the vCLS VMs
  • Resource reconfiguration of the vCLS VMs such as changing CPU, Memory, Disk size, Disk placement
  • VM encryption
  • Triggering vMotion of the vCLS VMs
  • Changing the BIOS
  • Removing the vCLS VMs from the inventory
  • Deleting the vCLS VMs from disk
  • Enabling FT of vCLS VMs
  • Cloning vCLS VMs
  • Configuring PMem
  • Moving vCLS VM to a different folder
  • Renaming the vCLS VMs
  • Renaming the vCLS folders
  • Enabling DRS rules and overrides on vCLS VMs
  • Enabling HA admission control policy on vCLS VMs
  • Enabling HA overrides on vCLS VMs
  • Moving vCLS VMs to a resource pool
  • Recovering vCLS VMs from a snapshot

When you perform any disruptive operation on the vCLS VMs, a warning dialog box appears.

Troubleshooting:

The health of vCLS VMs, including power state, is managed by VMware ESX Agent Manager and Workload Control Plane services. In case of power on failure of vCLS VMs, or if the first instance of DRS for a cluster is skipped due to lack of quorum of vCLS VMs, a banner appears in the cluster summary page along with a link to a Knowledge Base article to help troubleshoot the error state.

Because vCLS VMs are treated as system VMs, you do not need to backup or snapshot these VMs. The health state of these VMs is managed by vCenter Server services.