How to fix "vCenter state is authoritative" ?

[KildeDK]

Hi,

I had to reinstall my vcenter server, and I just setup vSAN but I'm getting the error: vCenter state is authoritative and the option Update ESXi configuration doesn't fix it.

Anyone have any suggestions on how to fix this?

Thank you in advance.

[scott28tt]

Moderator: Moved to vSAN

[TheBobkin · Accepted solution]

Hello KildeDK​

Welcome to Communities.

Can you please share screenshot or details of what it is specifically saying is the reason for vCenter is not authoritative (and which hosts are shown in the alert if not all) - this can be for a number of reasons including last changes made in a different vCenter but also disparities between the vSphere-level cluster settings and those applied to the cluster (e.g. Dedupe, Encryption etc.) - please validate that you created the new vSphere-level cluster with the same settings and features enabled (and that these are adequately licensed for).

Potentially vC can't push down unicast list check/change because this was left disabled on some/all nodes, this can be checked with the following command via CLI and if it is set to '1' then vC can't push down such changes:

# esxcfg-advcfg -g /VSAN/IgnoreClusterMemberListUpdates

Bob

[KildeDK]

Hi Bob,

After reading your reply it hit me I had changed the unicast list to ignore because I had to manually add neighbors for each host (Could this be because my vSAN network are connected through LACP into a switch)?

But after IgnoreClusterMemberListUpdates were set back to 0, I could run update ESXI configuration and it went back to green.

[TheBobkin]

Hello KildeDK​,

If the cluster was fully-formed and all nodes had correct and complete unicastagent lists when IgnoreClusterMemberListUpdates was enabled then manually editing or adding to lists shouldn't be necessary unless you are adding new nodes (or re-installed ESXi on any) - whether using LACP or not shouldn't matter provided you didn't change IPs etc.

Note that even if the unicastagent lists on all nodes are correct and reflective of the vSphere cluster members, this check will remain red if vCenter is prevented from pushing down changes

Another thing to note is that it is imperative that if using IgnoreClusterMemberListUpdates that it be used consistently applied to all nodes in the cluster as otherwise there are scenarios whereby the cluster can become partitioned.

Bob