Repurposed vSAN ESA Hosts Cause Sub-Cluster UUID Collision in New OSA Cluster
search cancel

Repurposed vSAN ESA Hosts Cause Sub-Cluster UUID Collision in New OSA Cluster

book

Article ID: 447194

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

When repurposing ESXi hosts from an existing vSAN Express Storage Architecture (ESA) cluster into a new vSAN Original Storage Architecture (OSA) cluster, the hosts fail to mount the new OSA datastore. Instead, the hosts experience a split-brain configuration and attempt to inject newly formatted OSA disk groups into the legacy ESA cluster's namespace. The vSAN health UI may show cluster partition and Sub-Cluster UUID mismatch errors.

Environment

vSAN 8.0u3
vSphere 8.0u3

Cause

The repurposed ESXi host(s) retained their legacy ESA Sub-Cluster UUID and unicast agent list within their local esx.conf registry. Moving the hosts into a new vCenter cluster object does not automatically wipe these active kernel-level vSAN identities. Because the new OSA cluster shares the same Layer 2 vSAN VLAN as the old ESA cluster, the vSAN services immediately re-established quorum with the original ESA nodes before vCenter could push the new OSA configuration payload.

Resolution

 

  1. Identify the Cache Tier UUIDs of the misaligned disk groups by connecting to each affected host via SSH and executing: esxcli vsan storage list | grep "VSAN Disk Group UUID" | sort -u

  2. Destroy the misaligned OSA disk groups to prevent storage metadata corruption in the ESA cluster by executing: esxcli vsan storage remove -s <VSAN_Disk_Group_UUID>

  3. In the vSphere Client, turn off vSAN on the new cluster object.

  4. Move the affected (repurposed) hosts out of the cluster to the Datacenter level.

  5. Force the affected hosts to drop the stale cluster routing and UUID via SSH by executing: esxcli vsan cluster leave

  6. Re-enable vSAN OSA on the vCenter cluster with only a "clean" anchor host present (a host never associated with the ESA cluster) to force vCenter to generate a pristine Sub-Cluster UUID.

  7. Verify the newly generated Sub-Cluster UUID differs entirely from the legacy ESA cluster by executing: esxcli vsan cluster get | grep -i "Sub-Cluster UUID"

  8. Move the affected hosts back into the vCenter cluster, allowing vCenter's declarative management to push the new, correct UUID and unicast agent routes.

  9. Recreate the OSA disk groups via the vSphere Client.

 

Additional Information

VMware vSAN Design and Sizing Guide

Powered by Wolken Software