vSAN file service does not deploy nodes after being removed.
You may see a health check in Skyline health indicating an issue with vSAN file services infrastructure.
When attempting to start socketrelay on the host through SSH using command: /etc/init.d/fsvmsockrelay start, you will get the below error
If vSAN file services was disabled during upgrade, this can cause vSphere ui errors when trying to edit vSAN file services. This will resolve it self when all hosts are upgraded and match same version. You will still observe the 'EAM certificate trust' as well in the logs.
vSAN 7.x
vSAN 8.x
This is related to an EAM API call failing with CertificateNotTrustedFault or EAM agent has CertificateNotTrusted issue
You can confirm this issue by reviewing the EAM logs under: /var/log/vmware/eam/eam.log
where you will see an error similar to the following:
Resolve the EAM trust issue either by creating a leaf trust, disabling trust, installing cert trust, or replacing the machine certificate.
Do one of the following options below to create leaf trust, or disable trust to OVF URL.
To keep cert verification and have secure download to external URL.
To bypass cert verification with unsecure download possible,
Reference KB: https://knowledge.broadcom.com/external/article/313402/
An outdated or mismatching certificate data between the cert and VECS can cause the trust mismatch. To resolve, you can refresh the certificate in VECS with the current machine certificate for vCenter. Which will update endpoints to the current certificate chain.
To learn more about VECS and reviewing the certificates stored in VECS, please see this KB.
EAM API call fails with CertificateNotTrustedFault:
https://knowledge.broadcom.com/external/article/313402/
Upgrade Pre-check states "Source ESX Agent Manager Configuration contains URLs that are not trusted by the System:
https://knowledge.broadcom.com/external/article/313026/
Manually reviewing VECS:
https://knowledge.broadcom.com/external/article/321380/