Before upgrade, remediation failed because vSAN health check failed. (" vSAN ESA is enabled on the cluster, but a disk group is detected on this host")
search cancel

Before upgrade, remediation failed because vSAN health check failed. (" vSAN ESA is enabled on the cluster, but a disk group is detected on this host")

book

Article ID: 406186

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

When using VMware vSphere Lifecycle Manger you get an error that states" Before upgrade. remediation failed because vSAN health check failed"

And when vSAN Health is checked you see the following alert "vSAN ESA is enabled on the cluster, but a disk group is detected on this host"

Environment

VMware vSAN (All Versions)

Cause

At some point the vSAN cluster was moved in to a new vCenter and/or a replacement vSAN cluster object was created.  This new cluster object was created as an ESA cluster even though the hosts were configured for OSA.  This misconfiguration issue will lead to mutiple issues including failed upgrades via VMware vSphere Lifecycle Manger. 

 

Resolution

Need to create a new OSA cluster object and migrate the hosts to the new cluster object.

The following should be run with all due caution. It is important to ensure that good backups are available as any such change carries a degree of risk. This process seeks to mitigate that risk.

  • This is not recommended if using Horizon or any other application that auto deploys VMs as it will require re-configuration with the new Cluster.
  • If NSX is used, make sure Transport Node Profiles are in use otherwise this will result in NSX getting uninstalled from the Hosts. Transport Node Profiles (TNP) allows for Hosts to be able to move from one Cluster into another Cluster within the same vCenter without the NSX getting uninstalled from the Hosts.
Steps to create a new identical Cluster in the vSphere Client:
 
1.) Re-name current Cluster and add -old to end of it
2.) Verify the settings of the old Cluster and then create a new Cluster with identical settings ( e.g. Deduplication and Compression, Encryption, Advanced options, etc.) 
3.) SSH into each vSAN Host and run the following command to avoid any potential partitions:
esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListupdates
 
5.) Drag each disconnected vSAN Host into the new Cluster
(If desired, verify Cluster Membership by running esxcli vsan cluster get on each Host)
 
6.) Once all vSAN Hosts have been moved to the new Cluster, right click each vSAN Host and select "connect" 
7.) Navigate to Cluster --> Monitor > vSAN Health

All alarms should be the same as before except for the following will be triggered: vSAN Skyline Health Service - Cluster health – vCenter state is authoritative
This is expected due to the Advanced configuration that was set in Step 3. 
Verify that this is the only Alarm being triggered and that configurations are correct and identical between old and new Cluster. 
 
8.) SSH into the vSAN Hosts and reverse Step 3 by executing on each:
esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListupdates
 
9.) Navigate to Cluster --> Monitor > vSAN Health
Click 'Troubleshoot' on the Alarm "vCenter state is authoritative" and click "Remediate Inconsistent Configuration"
The Cluster should now be in working order without the appearance of any Alarms referring to "Hyperconverged Cluster Configuration"

If you have any questions or issues on this action, please open a case with vSAN Support for further investigation.

Additional Information

Powered by Wolken Software