The vSphere Cluster Service (vCLS) was introduced with vSphere 7 Update 1. With vSphere 7 Update 3, there's several good updates to vCLS to make operations like agent VM host placement and datastore placement more efficient.
Using the Compute Policies construct which now is part of vSphere, we can enforce smarter agent VM placement. Compute Policies were already part of the VMC on AWS solution. It's a dynamic way of creating (anti)affinity rules sort of speak, it's creating dynamic VM placement within a cluster using vSphere tags. In the vSphere 7 Update 3 release, Compute Policies can only be used for vCLS agent VMs.
This is solving a potential problem customers had with, for example, SAP HANA workloads that require dedicated sockets within the nodes. Customers do not share the sockets from HANA workloads to run any other applications or even agent VMs like with vCLS. Hence customers would either lose a full socket in a HANA cluster to run vCLS VMs which could be a loss of significant compute resources, depending on the cluster size and configuration.
With the smart affinity configurations for vCLS agent VMs, using Compute Policies, we can run vCLS agent VMs on hosts within the cluster that not interfere with specific VMs. That way, SAP HANA users can specify affinity so the agent VMs are using a dedicated host for example. The reason that Compute Policies are used, and not the DRS (anti)affinity rules, is that DRS will not be available while the vCLS agent VMs affinity is being configured.
How to Configure?
To start, we need a vSphere Tag. In the following example I'm creating a tag in my custom created tag category. I'll attach this tag to VMs, where the goal is to not have the vCLS agent VMs running on the same hosts as these VMs configured with the new tag.
Once the tag is set up, and I have configured VMs with this tag, the next step is to define the vCLS Compute Policy. In the vSphere Client menu, select 'Policies and Profiles'. Here is where you'll find the new Compute Policies option in vSphere 7 Update 3.
Hitting 'Add' will show a menu where users can define the policy type, although there's only one option today; Anti-affinity with vSphere Cluster Services (vCLS) VMs. Its configuration is pretty straight forward. Configure a name and optional description, and the VM tag including its category before saving this configuration.
The policy will be effective immediately. If there's incompliancy, the vCLS agent VMs are migrated to another host that is compliant to the compute policy. Note that the vCLS agent VMs are migrated, not the workload VMs! Looking closer at the tasks in the vSphere Client, you'll notice a task 'Remediate vCLS VM placement' as in the example below.
Clicking on the compute policy itself, the vSphere Client presents information about the policy. Information like the VMs that are managed by this policy is shown, including their compliancy to the policy. As you add more VMs to the policy, by attaching the tag to those VMs, there's dynamic placements done for the vCLS agent VMs!
Better Datastore Placement
Customer can now define what datastores are used to host the vCLS agent VMs. This is fully optional, but helps in controlling what datastore is used for vCLS. Only the 'vCLS Allowed' datastore are now used for vCLS agent VMs. Once configured, vCLS agent VM's that are currently running on local storage or any datastore not in the vCLS allowed list, are migrated using Storage vMotion to a vCLS allowed datastore option, as configured by the user.
There's also a 'Solution Blocked' category, containing datastores that are enabled with solutions like Site Recovery Manager (SRM) or vSAN Maintenance Mode which is why these datastore are not eligible for vCLS agent VMs. The 'Learn More' link will redirect you to KB article 79892.
Another change in vSphere 7 Update 3, is that the vCLS agent VMs now reflect their UUID to make it easier to distinct agent VMs from different clusters. Before, all the vCLS agent VMs from multiple clusters potentially got the same name, with a number appendix.