Hello wsanders11,
Are all the hosts on the same build version (5969303)?
Test if restarting vsanmgmtd on all hosts has any effect on web client info availability (this has no negative effects and does not break communication with vCenter):
#/etc/init.d/vsanmgmtd restart
Check if same visibility situation when going via the HTML client:
https://vCenterIP/ui
There is actually Health check for vSAN cluster available via direct connection to single host via HTML client in 6.6:
https://HostIP/ui
Host > Datastores > vsanDatastore > Monitor > Health (or something similar - no lab access at present to check, sorry)
If restarting vsanmgmtd has no effect then (depending on other factors), you could try rebooting vCenter (or restarting all of its services):
https://kb.vmware.com/s/article/2109881
SSH to the host that is disconnected from vCenter, the following will have no impact on activity of a host that is disconnected from vCenter:
# ps | grep hostd (this checks open hostd processes)
#/etc/init.d/hostd status (checks hostd status e.g. 'running')
#/etc/init.d/hostd stop (stops hostd)
# ps | grep hostd (if hostd processes are still open then hostd is hung and need to find out why)
Can try killing these hung processes but this will likely not work, rebooting host may be only option if hostd can not be remediated.
If the host can not be reconnected to vCenter (due to hostd issues) then unfortunately you can not vMotion anything off, however if the VMs are still up and functional (more likely than with non-vSAN storage) you can shut-down VMs from CLI or via HTML client at a time that is best and put host in MM with Ensure Accessibility and reboot (either via CLI or HTML client depending which is accessible).
The above points are not everything possible to do in this situation - just the 'Cliff's Notes' - if deeper analysis is required and available then always if in doubt open a Support Request with GSS.
Bob
