"I ran the command "esxcfg-advcfg -g /VSAN/IgnoreClusterMemberListupdates" against all of the ESXi hosts and only one host out of the 5 were set to 1"
, So this can explain all nodes stating requiring remediation due to vCenter not being authoritative - One node is set to ignore vC membership updates and thus it can't validate and/or remediate this nodes settings/configuration (even if they don't differ from vC's opinion of the cluster etc.).
"If setting this option to 0 there will be no effect on data. Also I apologize about constantly asking about data."
Absolutely no need for apologies whatsoever - my colleague (Hi Kam!) has a statement (maybe more of a mantra ) that I completely believe in when dealing with any situation where there is any question of the outcome and/or approach:
'Our first priority here is the data. Our second priority here is the data. Our third priority here is the data. All other priorities fall after these.'
Setting this to 0 (the default setting) on this node won't do anything, however, it will allow (when remediate button is pushed) vC to check the settings/configurations on this node and push any necessary changes to this and the other nodes - typically this is only relegated to unicastagent updates e.g. if what the nodes have as the vsan IP of a node differs with what it is currently set to from vC's perspective. The worst possible outcome from such change would be that node getting isolated from the cluster (which doesn't permanently impair data and is easily remediated), but this shouldn't be possible provided the information on the nodes and also the from vC perspective (e.g. check in the UI) are matching and correct.
This can be easily validated via checking the following:
Check the unicastagent list on each node - this should contain correct UUID and vsan-IP entry for all nodes in the cluster except the node this is being run on (e.g. a node in a 6-node cluster with single vsan-enabled vmk will have 5 entries):
# esxcli vsan cluster unicastagent list
Check that the information from the above IPs match the hosts information for the vsan-enabled vmk in the UI.
Host to UUID information can be determined via:
(run on each node and only returns itself)
#cmmds-tool whoami
or from any node:
# cmmds-tool find -t HOSTNAME | grep -iE 'uuid|health|content'
"Do I have to disconnect the host, put it into maintenance mode and rename it (https://kb.vmware.com/s/article/1010821) or can I just change the hostname?"
Yes, host name changes requires the steps in that kb (e.g. it has to be in Maintenance Mode (with Ensure Accessibility to keep all VMs accessible), remove from cluster (this does NOT remove the vSAN Disk-Groups, just kicks it out of the cluster), disconnect, remove from inventory, make the changes, reconnect, move back into cluster, exit MM.
While there are slightly 'hacky' means of keeping a node in a vSAN cluster while removed from vC inventory, these are not advisable and thus I won't be advising on these.