0

vSphere 7 Update 1 added a new "vSphere Clustering Service (vCLS)" and according to the doc:

  • Basic Architecture

    The basic architecture for the vCLS control plane consists of maximum 3 virtual machines (VM), also referred to as system or agent VMs which are placed on separate hosts in a cluster. These are lightweight agent VMs that form a cluster quorum. On smaller clusters with less than 3 hosts, the number of agent VMs is equal to the numbers of ESXi hosts. The agent VMs are managed by vSphere Cluster Services. Users are not expected to maintain the lifecycle or state for the agent VMs, they should not be treated like the typical workload VMs.

It's very confusing to me how these vCLS VMs can help provide Clustering Service. These VMs even don't have network adapters so they cannot directly talk to each other. It's the cluster's ESXi hosts who are actually exchanging their status info. So technically speaking, an ESXi service (running as processes) can do whatever the vCLS VMs can do.

Try Googling "vsphere disable vcls" and you'll see this new feature really introduced some confusion to users. So what's the point of using the vCLS VMs?

SF.express
  • 378
  • 1
  • 16

1 Answers1

1

"so they cannot directly talk to each other" - there's more ways for VMs to talk to each other and to vCenters than just ethernet/IP.

Since DRS and HA were introduced they were essentially dependant on the vCenter being up - the VC decided what VMs to move for DRS and orchestrated the hosts moving them, and HA needed the VC to help coordinate the HA voting process and plan the 'failure map'.

vCLS allows for both DRS and HA to not only continue in the absence of a VC but also to allow HA voting and plans to evolve based on host availability with the VC in place. Think of it as the <7.0u1 VC DRS and HA functions shipped out of the VC into a three-way cluster to do this role for it - does that make sense?

Anyway just ignore them, they're effectively self-managed, by all means stick them in their own VM folder to hide them away but don't worry about them.

Chopper3
  • 101,299
  • 9
  • 108
  • 239
  • "there's more ways for VMs to talk to each other and to vCenters than just ethernet/IP." -- vCLS VMs are running on different ESXi hosts, so how? – SF.express Nov 05 '21 at 15:09
  • yes i can just ignore them. just curious from the tech point of view. it's beyond my understanding. – SF.express Nov 05 '21 at 15:12
  • There are a number of internal VMware protocols they have available to them for various reasons. – Chopper3 Nov 05 '21 at 15:38
  • i understand the *internal protocols* are possible if the VMs are on the same ESX host but vCLS VMs are on different ESX hosts. – SF.express Nov 05 '21 at 16:19
  • Specifically they use the VMCI/vSocket interface to allow the VM to talk to the host and as the hosts can talk to each other they can use that mechanism to communicate between themselves. – Chopper3 Nov 05 '21 at 16:24
  • yes but why bother? the ESX hosts can communicate their status with each other without the vCLS VMs. right? it seems to me the vCLS VMs are only adding complication here. – SF.express Nov 05 '21 at 16:26
  • Dunno, didn't design it sorry, this is probably an evolutionary step from everything controlled by the VC to fully decentralised, this is just one step I think. – Chopper3 Nov 05 '21 at 16:29
  • i agree it's cool to make DRS/HA/... continue working when VC is down. just cannot think of what magic roles the vCLS VMs are playing. – SF.express Nov 05 '21 at 16:33
  • They allow for DRS to work without the VC and for the hosts to initiate a HA vote and plan, then communicate the plan between them - basically just distributing that role away from the VC. – Chopper3 Nov 05 '21 at 16:53