Hi there! I've never heard about that alert.
It seems to be a cache / capacity ratio problem. vSAN require the cache disk to have -at least- 10% size of the capacity tier. For example, for a capacity tier of 2TB, the cache disk must be 200GB or bigger.
Wb seems to be Write Buffer.
I found this chinese site explaining the advanced settings, you can translate it to english using the browser: https://www.halfcoffee.com/2016/09/12/vsanlsom/
Also this post may be useful Write Buffer Sizing in vSAN when Using the Very Latest Hardware
If you run vsan debug advcfg list in an SSH session, you will see that option listed.
vsan debug advcfg list --option='LSOM.ssdWbSize'
Welcome to Communities.
Is the Witness running on a different build of ESXi than the data-nodes are?
I ask as (other than manual advanced configuration changes) this is the most common source of such alerts in vSAN Health - this is as a result of ESXi/vSAN having different parameters set for certain things in different build versions, not all of these are customer-facing and thus not all configurable via the UI (as some of these really shouldn't be messed with).
If it is running on a different build then update the nodes to the matching build or if this is not possible then redeploy the Witness on the same ESXi build the hosts have installed.
On the datanode's I have 4x 1.8TB disks and a 900 GB SSD so that would be around 12.5%
I don't really know how this works with the witness appliance, with the deployment I just configured one for 500VM's.
I SSH'd into the machine's but the command was unknown.
TheBobkin I checked the builds and you were right
the 2 data node's and the server running the witness appliance are V6.7 Build 15160138
The witness appliance itself is V6.7 Build 8169922.
I've reinstalled the witness appliance with the correct build.
but... the issue still persists
So I had a quick dig into this from internal documentation and it would appear that LSOM.ssdWbSize=90 is the correct setting for a Witness with default settings, so this health alert is not a cause for concern.
However, the check for this in Health is intended to filter out this check on the Witness (as it is an intentional difference and thus we don't want it triggering a warning) - what build of vCenter is in use here?
If the hosts are on 6.7 U3 then so should vCenter:
the vCenter version matches with the rest.
According to the matrix I could also use V7.0? maybe I should do that..
If the error persists should I just silence it and try to continue with the vSAN config?
If you haven't restarted services and/or rebooted the vCenter since updating the Witness I would try this first if even just to rule this out.
I don't think updating to 7.0 will fix this as from vSAN Health perspective this has mostly the same functionality/code as 6.7 U3 (7.0 GA anyway).
I wouldn't advise silencing this Health check as it is responsible for checking a lot of other configuration settings and can be quite useful/informative.
As I said above - that setting for the Witness is correct and should pose no functional/operational issues, the issue is with vSAN Health not seeing that it is a Witness and should be ignoring the disparity.
"If the error persists should I just silence it and try to continue with the vSAN config?"
Has the cluster been fully configured e.g. all nodes have vSAN networking, Disk-Groups and the Witness (10.0.99.120) added? If not, please complete the configuration.
If this is a production cluster and/or you have a support contract with VMware GSS I would advise opening a Support Request with us so that we can figure out why vSAN Health is triggering this.