I have written about vCLS a few times, so I am not going to explain what it is or what it does (detailed blog here). I do want to talk about what is part of vSphere 7.0 U3 specifically though as I feel these features are probably what most folks have been waiting for. Starting with vSphere 7.0 U3 it is now possible to configure the following for vCLS VMs:
- Preferred Datastores for vCLS VMs
- Anti-Affinity for vCLS VMs with specific other VMs
I created a quick demo for those who prefer to watch videos to learn these things if you don’t skip to the text below. Oh and before I forget, a bonus enhancement is that the vCLS VMs now have a unique name, this was a very common request from customers.
Why would you need the above functionality? Let’s begin with the “preferred datastore” feature, this allows you to specify where the vCLS VMs need to be provisioned to from a storage point of view. This would be useful in a scenario where you have a number of datastores that you would prefer to avoid. Examples could be datastores that are replicated or a datastore that is only intended to be used for ISOs and templates, or maybe you prefer to provision on hybrid storage versus flash storage.
So how do you fix this? Well, it is simple, you click on your cluster object. You then click on “Configure”, and on “Datastores” under “vSphere Cluster Services”. Now you will see “VCLS Allowed”, if you click on “ADD” you now will be able to select the datastores to which these vCLS VMs should be provisioned.
Next up Anti-Affinity for vCLS. You would this feature for situations where for instance a single workload needs to be able to solely run on a host, something like SAP for instance. In order to achieve this, you can use anti-affinity rules. We are not talking about regular anti-affinity rules. This is the very first time a brand new mechanism is used on-premises. I am talking about compute policies. Compute policies have been available for VMware Cloud on AWS customers for a while, but now are also appear to be coming to on-prem customers. What does it do? It enables you to create “anti-affinity” rules for vCLS VMs and specific other VMs in your environment by creating Compute Policies and using Tags!
How does this work? Well, you go to “Policies and Profiles” and then click “Compute Policies”. Now you can click “ADD” and create a policy. You now select “Anti Affinity with vSphere Cluster Services (vCLS) VMs”. Then you select the Tag you created for the VMs that should not run on the same hosts as the vCLS VMs, and then you click create. The vCLS VM Scheduler will then ensure that the vCLS VMs will not run on the same hosts as the tagged VMs. If there’s a conflict, the vCLS Scheduler will move away the vCLS VMs to other hosts within the cluster. Let’s reiterate that, the vCLS VMs will be vMotioned to another host in your cluster, the tagged VMs will not be moved!
Hope that helps!
Pin Pin Poola says
This is a great first step in the evolution of vCLS!
I hope in future we get the ability to customise the inventory naming of the vCLS VM’s – even a prefix/suffix of the ESXi Hostname would be a helpful start.
Also an option to prefer placement of the vCLS VM on a ESXi hosts local VMFS would be nice.
Duncan Epping says
Those are definitely on the feature request list, thanks for the feedback!
I would like to see the names become fully customizeable. We have hundred of these things and all internal naming is based on FQDNs so simple prefix/postfix wouldn’t be the best option (even though it would be better than the current)
This is GREAT! Right now all of the vCLS go on an NFS mounted datastore which we don’t use for VMs and then I have to move them off.
@gungazoo, we had the same problem, except the NFS was in another site in another town!
The feature “Preferred Datastores” will be a great one! so finally, we can decide where to put the vCLS machines!
does anyone know how to set “Preferred Datastores” using PowerCLI/API?
Matthias Kaufmann says
got it myself with codeCapture:
$clspec = New-Object VMware.Vim.ClusterConfigSpecEx
$clspec.DrsConfig = New-Object VMware.Vim.ClusterDrsConfigInfo
$clspec.SystemVMsConfig = New-Object VMware.Vim.ClusterSystemVMsConfigSpec
#$clspec.SystemVMsConfig.AllowedDatastores = New-Object VMware.Vim.ClusterDatastoreUpdateSpec (2)
$dsspec = New-Object VMware.Vim.ClusterDatastoreUpdateSpec
$dsspec.Datastore = New-Object VMware.Vim.ManagedObjectReference
$dsspec.Datastore.Type = ‘Datastore’
$dsspec.Operation = ‘add’
$dsspec.Datastore.Value = $_.Extensiondata.MoRef.Value
$clspec.SystemVMsConfig.AllowedDatastores += $dsspec
James Duncan says
Hi Duncan. Would it be possible to do an article on applying CIS Benchmarks against the vCLS
as per https://www.cisecurity.org/benchmark/vmware/
Duncan Epping says
I have no experience in this whatsoever to be honest. Let me ask around internally, but I haven’t seen this coming up ever before.
Great new feature. Though I did notice that when applying the allowed datastores for one cluster, I suddenly saw the vCLS on all other clusters also being redeployed. Had no issues because of this, but was surprised to see it happen.
Ankit Mehrotra says
Hi Duncan, Great article. In a stretched cluster scenario, will it be advised to also have the vCLS VMs included in site affinity rule (should have) so that at least one vCLS VM resides on the secondary data site?
Ludovic girardin says
My vCenter is in 7U3 but ESXis are in 7U2a. Can I use the functionnality “Preferred Datastores for vCLS VMs” in this case ? supported ?
I love this feature, but be careful when specifying allowed vCLS datastores on clusters where you are NOT storing swap files in the vm directory (default setting) but instead are using the “Datastore specifed by host” option. If you do, you must ALSO include the host-specifed swap datastore(s) as allowed vCLS datastore(s). If you do not include host-specifed swap datastore(s) in this list of allowed vCLS datastores for your cluster, as soon as you select specific vCLS datstores the vpxd process will kill/delete the vCLS vms, then the eam process will determine that you do not have sufficient number of vCLS vms for the cluster and deploy new ones. And because they are deployed without memory reservation they need to use the host-specifed swap datastore (which you have just unwittingly prevented them from accessing), and then the vpxd process deletes them, and them eam kicks in to redeploy new ones, and so on in an infinite loop – until you add the host-specifed swap datastores to the vCLS-allowed list.
Duncan Epping says
Thanks for providing that extra info!