This article explains the vSAN Health Service – Cluster configuration consistency check in vSAN Health Service and provides details on why it might report an error.
For more information on vSAN cluster configuration consistency, see:
Q: What does the vSAN Health Service – vSAN cluster configuration consistency check do?
This health check validates that all hosts in this cluster and their disks have a configuration consistent with the configuration set at the cluster level, For Example: dedup/compression, Data-at-Rest/Data-in-Transit encryption, performance service.
Q: What does it mean when it is in an error state and how to fix?
If this check fails, it means that there are inconsistent configuration (for example: dedup/compression, encryption) setup on hosts or disks with the cluster. The results of this health check will report the inconsistency in the cluster that can range from host and disks with issues to encryption mismatches, and will provide some remediation recommendations to resolve the issue.
The User can attempt to remediate the issue by clicking "Remediate inconsistent configuration" button to run the cluster configuration remediation action to fix hosts and disks which have inconsistent configurations (e.g. dedup/compression, encryption). Caution should be taken when remediating any inconsistency that has potential to initiate a large amount of data resync (e.g. enabling/disabling dedup/compression, encryption on disks) as this can have a negative impact on the performance of the cluster.
For performance service configuration inconsistency, user cannot manually remediate the cluster configuration by click "Remediate inconsistent configuration" button. An auto-remediation will be applied to this cluster when an inconsistent configuration is detected for the vSAN performance between vCenter and ESXi hosts. Note the configuration inconsistency health check for performance service is available since vSphere 6.7 release.
If the vSAN cluster is in compute only mode, user may see the health check trigger, if there's a host with a vSAN disk-group created. This is because vSAN disk-groups are not supported in compute-only clusters and this can be remediated either by removing the host from the cluster or removing the disk-group from host.