## Data
| Name | Description |
| ---  | --- |
| vSAN object health | Provides a cluster wide overview by summarizing all objects in the cluster, grouping them in fine grained categories of object health. |
## Hardware compatibility
| Name | Description |
| ---  | --- |
| vSAN HCL DB up-to-date | Checks the age of the VMware Hardware Compatibility Guide database used for the HCL checks. Shows warning or error when it is older than 90 or 180 days, respectively. VMware updates the VCG frequently, so it is important to keep the local copy up-to-date. |
| vSAN HCL DB Auto Update | Checks the vSAN HCL DB can be downloaded and updated from the VMware HCL release website automatically. When there is no internet access to the VMware public website or the vSAN HCL DB auto update is not enabled, this health check will be in silent health check list by default to show skipped status unless user removes it from silent list manually. Otherwise, it shows warning if the HCL database cannot be auto updated for any other reason like cannot connect VMware HCL release website, fail to download latest HCL DB or fail to update the local HCL DB. |
| SCSI controller is VMware certified | Displays information about the storage I/O controller and verifies that the controller is supported in the VMware Compatibility Guide, based on its PCI ID. If there is a mismatch, contact VMware support. |
| Controller is VMware certified for ESXi release | Displays information about the storage I/O controller drivers. Checks if the installed driver is supported for the corresponding controller in the current release of ESXi. Only the VMware certified controller will be tested and shown in the result |
| Controller driver is VMware certified | Checks if the driver used by a controller is listed as certified in the VMware Compatibility Guide. Only the controller which is on the vSAN HCL and certified for the current release of ESXi will be tested and shown in the result |
| Controller firmware is VMware certified | Checks if controller firmware is certified per the VMware Compatibility Guide. A 'N/A' result means that a vendor tool should be installed if it is available to determine actual firmware version. Do so via the 'Update software' action when available, to update vendor tool and firmware to the recommended version. Only the controller which is on the vSAN HCL and certified for the current release of ESXi will be tested and shown in the result. |
| Controller disk group mode is VMware certified | Checks if the vSAN disk group type (All-Flash or Hybrid) is certified for the used SCSI controller in the VMware Compatibility Guide. Only the controller which is on the vSAN HCL and certified for the current release of ESXi will be tested and shown in the result. |
## vSAN Build Recommendation
| Name | Description |
| ---  | --- |
| vSAN Build Recommendation Engine Health | vSAN Build Recommendation Engine relies on VMware compatibility guide and VMware release metadata for its recommendation. In addition, it also requires VMware Update Manager service to be available, Internet connectivity and valid my.vmware.com credentials to be set to provide build recommendations. This health check makes sure that these dependecies are met and the recommendation engine is functioning correctly. |
| vSAN build recommendation | vSAN build recommendation. This is the ESXi build that vSAN recommends to be the most appropriate, given the hardware, its compatibility per VMware Compatibility Guide and the available releases from VMware. |
## Online health
| Name | Description |
| ---  | --- |
| Customer experience improvement program (CEIP) | The current status of the Customer Experience Improvement Program (CEIP) is disabled. Online health checks are not available if CEIP is disabled. |
## Network
| Name | Description |
| ---  | --- |
| Hosts disconnected from VC | This check refers to whether VC has an active connection to all hosts in the cluster. If any host is disconnected from VC (or not responding) it could cause operational issues. If VC is not connected to the host, its state is unknown to VC. The host may be up, and may be participating in the vSAN cluster, serving data, and playing a critical role in the storage functions of the cluster. Or the host may be down and unavailable. VC and hence the vSAN Health check cannot fully assess the situation as long the host is disconnected. If the host is participating in the vSAN cluster it will show up in the Unexpected vSAN cluster member check as unexpected, as its UUID cannot be determined, so the health check cannot conclusively tell if the host it is seeing in the vSAN cluster is the disconnected one or not. In addition, other health checks, like vSAN connectivity checks or disk health checks will not be able to take the disconnected host into account. |
| Hosts with connectivity issues | This check refers to situations where VC lists the host as connected, but API calls from VC to the host are failing. This should be extremely rare, but in case it happens it leads to similar issues as the Host disconnected from VC situation. |
| vSAN cluster partition | To ensure proper functionality, all vSAN hosts must be able to communicate over both multicast and unicast. If they cannot, a vSAN cluster will split into multiple partitions, i.e. sub-groups of hosts that can communicate, but not to other sub-groups. When that happens, vSAN objects might become unavailable until the network misconfiguration is resolved. |
| All hosts have a vSAN vmknic configured | In order to participate in a vSAN cluster, and form a single group of fully connected hosts, each host in a vSAN cluster must have a vmknic (VMkernel network interface or VMkernel adapter) configured for vSAN traffic. |
| vSAN: Basic (unicast) connectivity check | Performs a ping test with small packet size from each host to all other hosts. If this check fails, there is a basic issue with network connectivity. Check vmknic, uplink, VLAN, physical switch and associated settings. If this check passes, basic unicast connectivity is working properly. |
| vSAN: MTU check (ping with large packet size) | Performs a ping test with large packet size from each host to all other hosts. If this check fails while the basic connectivity check passes, there is an issue with MTU settings. |
| vMotion: Basic (unicast) connectivity check | Performs a ping test with small packet size between all VMkernel adapters with vMotion traffic enabled. |
| vMotion: MTU check (ping with large packet size) | Performs a ping test with large packet size between all VMKernel adapters with vMotion traffic enabled. |
| Network latency check | Performs a network latency check of vSAN hosts. The network configuration guidance of normal cluster requires RTT less than 1ms. To allow for temporary fluctuations, this health check reports warnings based on a conservative threshold of 5ms. If this check fails, please check vmknic, uplink, VLAN, physical switch and associated settings to locate the network issue. NOTE: This check will be skipped if the pair of hosts failed connectivity check. |
## Physical disk
| Name | Description |
| ---  | --- |
| Operation health | Checks the physical disk operation health for all hosts in the vSAN cluster. If this check fails, the disk cannot be used by vSAN anymore with the possible reasons like issue in reading the disk metadata or the vSAN software issue preventing it to use this disk |
| Disk capacity | If this check fails for a specific disk, it indicates that this disk is low on free disk space. This health check is only applicable to capacity tier drives, not to the cache devices. |
| Congestion | If this health status not green/OK, vSAN is still using the disk, but it is in a state of (possibly severely) reduced performance, manifesting in low throughput/IOPS and high latencies for vSAN objects using this disk. |
| Component limit health | Checks if the number of components on the physical disk reaches the maximum limit |
| Component metadata health | This check will fail if vSAN has encountered an issue with the integrity of the metadata of a component in this disk. This could be due to faulty drives, faulty controller or a misbehaving device driver, but could also originate from a problem in the vSAN software. The best course of action is to engage VMware Support. |
| Memory pools (heaps) | This check will fail if vSAN is running low on vital memory pools needed for the correct operation of physical disks. Even under high load, this should not happen. If it does happen, VMware Support should be contacted. Likely the disk will also report bad congestion health, which will in turn lead to performance issues. |
| Memory pools (slabs) | This check will fail if vSAN is running low on a vital memory pool needed for the operation of physical disks. Even under high load, this should not happen. If it does happen, VMware Support should be contacted. Likely the disk will also report bad congestion health, which will in turn lead to performance issues. |
## Cluster
| Name | Description |
| ---  | --- |
| ESXi vSAN Health service installation | Verifies that all the hosts in the vSAN cluster have the vSAN Health Service installed. Other vSAN health checks will be performed only when all the hosts are upgraded to 6.0U2 or later release. |
| vSAN Health Service up-to-date | Checks that the version of the vSAN Health VIB that is installed on all ESX hosts in the cluster is the same as the Health version of VC. if the check fails, it is recommended that you update the version of the vSAN Health VIB on the cluster. |
| Advanced vSAN configuration in sync | vSAN has a number of advanced config options that can be used for tuning or to address special requirements of particular deployments. Usually such settings get changed under the guidance of VMware Support, using a VMware KB article procedure. These advanced config options are set per host, which makes it easy to create inconsistent configurations across a cluster. This check ensures that critical vSAN advanced config options have the same value or default value across all hosts in a given cluster. |
| vSAN CLOMD liveness | Check the CLOMD liveness on all of the vSAN hosts |
| vSAN Disk Balance | Check whether the disk loads in hosts are in balance status, if not, user can initiate a proactive rebalance, which trigger the disk rebalance. User can stop the proactive rebalance if there is a proactive reblance task is initiated. |
| Resync operations throttling | If this check fails, it means that resync operations are throttled. Please clear the limit, unless you need it for particular cases like a potential cluster meltdown. |
| vCenter state is authoritative | During normal operation, the vCenter server state is regarded as source of truth, and ESXi hosts are automatically updated with the latest host membership list. When vCenter server is replaced or recovered from backup, the host membership list in vCenter server may be out of sync. This health check detects such cases, and alerts if vCenter server state was not pushed to ESXi due to vCenter server being out of sync. In such cases, first fully restore the membership list in vCenter server, and then perform 'Update ESXi configuration' action if required. |
| vSAN cluster configuration consistency | If this check fails, it means that there are inconsistent configuration (like dedup/compression, encryption) setup on hosts or disks with the cluster. |
| Time is synchronized across hosts and VC | Checks time difference among VC and hosts. Any difference larger than 60 seconds will lead this check to fail. If the check fails, it is recommended that you check the NTP server configuration. |
| vSphere cluster members match vSAN cluster members | Checks that vSphere cluster members match vSAN cluster members |
| Software version compatibility | Once a vSAN cluster starts using a new on-disk format version (after software upgrade), the cluster becomes incompatible with hosts of older software version that do not support the new on-disk format. If such an older host version is introduced in the cluster, this host is either in a network partition or can only see/access a very limited set of data in the cluster. Such configurations are unsupported and an immediate software upgrade or removal of the older host version are advised. |
| Disk format version | vSAN cluster expected format version is 5, which is the highest supported format version by any host in the cluster. For disk with format version lower than expected version, vSAN on-disk format upgrade is recommended, to support latest vSAN features. |
## Limits
| Name | Description |
| ---  | --- |
| Current cluster situation | Checks for component limits, free capacity tier disk space, and read cache reservations across the entire cluster. Note that this way of looking at the resources is simplistic and doesn't take all vSAN placement rules into account. Practical usable resources may be less. |
| After 1 additional host failure | This health check simulates the failure of the host with most resources consumed and shows the cluster resource consumption then. First, the resources on that host would be no longer available. Second, vSAN will attempt to re-protect all objects that were now running with reduced redundancy. Re-protection of all objects is impossible if utilization is more than 100%. |
| Host component limit | This health checks lists the component limit, and its current usage for each host. Note that when the component limit is hit or the component is not balanced, you may want to add host or rebalance these components. |
## Performance service
| Name | Description |
| ---  | --- |
| Stats DB object | Checks the health of the vSAN performance service statistics database object |
| Stats master election | Checks stats master of vSAN performance service |
| Performance data collection | Checks the statistics collection of the vSAN performance service |
| All hosts contributing stats | Checks if all host are contributing performance stats |
| Stats DB object conflicts | Checks stats DB object conflicts |