This is the relevant kb article for this health check:
But it appears that you already found this and it looks like restarting the service is not working for the same reason that it did not start automatically in the first places (e.g. /scratch partition which is required for this to start is not available).
I would advise investigating whether /scratch is full (or out of inodes) and/or there is some other reason it cannot be written to.
Edit: I will look into doing something from my side regarding documentation of further troubleshooting/investigation should restarting the service not resolve the issue.
Hi Bob, thank you for reply
I'm still very new to vSphere in general, how would I check if the /scratch folder is full?
Welcome to vSphere and vSAN so.
Start by SSHing to the host and check does it even exist e.g.:
# cd /scratch
This should then show where scratch is pointed by the directory path changing e.g. if it is pointed to /tmp then it will look like:
If it is stored on a persistent or vfat partition then check if any of these are out of space (e.g. Use% is 100%):
# df -h
If it is stored in a Ramdisk (e.g. like /tmp) then check the available space on these:
# vdf -h
So basically it is case of first validating /scratch exists (corner-case being those without this like diskless Auto-Deploy hosts which are not supported for use with vSAN) and then validating that it has free space and inodes - if it doesn't then figure out what is consuming the space (e.g. something logging to the same parent directory) and free up space and redirect whatever was filling it to somewhere else more appropriate where it won't cause problems.
Most of the above and further related troubleshooting steps are covered here: