vSAN Health Service - Unicast agent configuration inconsistent

Products

VMware vSAN

Issue/Introduction

The Unicast agent configuration inconsistent check in the vSAN Health Service verifies that the unicast agent address on each data site host points to the witness host.

If this health check is not green (OK), the vSAN stretched cluster has configuration errors that affect its operation.

Environment

VMware vSAN (All Versions)

Resolution

To troubleshoot and resolve the configuration errors:

Configure the unicast communication between the data site host and the witness host so that the IP address and port are configured consistently on all hosts.
- To verify the listening IP address and port used by the witness host, run the esxcli vsan network list command. To avoid confusion, use only one interface configured for vSAN traffic. The witness host uses the first available vSAN network interface to listen for unicast IP traffic.
- To configure the listening address of the witness host on a host in a data site, use the esxcli vsan cluster unicastagent command. Currently only one unicast agent address is supported.
Configure the unicast agent with the IP address and port of the witness host. Every host in the data sites uses its unicast agent to communicate with the witness host. The Cluster with multiple unicast agents check verifies that the unicast agent is configured with a valid IP address and port. See Configuring vSAN Unicast networking from the command line for steps.
Configure all hosts in each data site with the same IP address and port for the unicast agent. All hosts in a stretched cluster must have a consistent configuration.

Additional Information

To view the list of ESXi hosts, run the esxcli vsan cluster get command. If you run the command on the witness host, the local node type appears as WITNESS.

For example:

[root@:~] esxcli vsan cluster get Cluster Information Enabled: true Current Local Time: 2015-06-25T23:52:26Z Local Node UUID: ########-####-####-####-########8d0e Local Node Type: WITNESS Local Node State: AGENT Local Node Health State: HEALTHY Sub-Cluster Master UUID: ########-####-####-####-########27e7 Sub-Cluster Backup UUID: ########-####-####-####-########9e57 Sub-Cluster UUID: ########-####-####-####-########e1bb Sub-Cluster Membership Entry Revision: 2 Sub-Cluster Member Count: 3 Sub-Cluster Member UUIDs: ########-####-####-####-########27e7, ########-####-####-####-########8d0e, ########-####-####-####-########9e57 Sub-Cluster Membership UUID: ########-####-####-####-########27e7

You can collect the list of node information and preferred fault domain by querying CMMDS from a host.

For example:

[root@:~] cmmds-tool find -t NODE owner=########-####-####-####-########0000(Health: Healthy) uuid=########-####-####-####-########9e57 type=NODE rev=0 minHostVer=0 [content = (i2 i1 i0 i1 i0)], errorStr=(null) owner=########-####-####-####-########0000(Health: Healthy) uuid=########-####-####-####-########27e7 type=NODE rev=0 minHostVer=0 [content = (i2 i1 i0 i1 i0)], errorStr=(null) owner=########-####-####-####-########0000(Health: Healthy) uuid=########-####-####-####-########8d0e type=NODE rev=0 minHostVer=0 [content = (i2 i1 i3 i1 i0)], errorStr=(null)