vSAN on-disk format version upgrade fails due to cluster type mismatch
Article ID: 443161
Updated On:
Products
Issue/Introduction
When attempting to upgrade the vSAN on-disk format from version 15 to version 20, the upgrade process fails with e general vSAN error.
Symptoms
- The pre-check phase completes successfully without flagging any errors, but the execution fails with
"General vSAN error: Failed to convert object(s) on vSAN"
- vCenter host level events (Host > Monitor > Events) indicating that disk conversion cannot be performed because no storage pools are mounted with
"No disk conversion performed, host <REDACTED_IP> has no mounted storage pools"
- vSAN Skyline Health (Cluster > Monitor > vSAN > Skyline Health) reports the following cluster health alert for cluster configuration consistency with "
Issue: vSAN ESA is enabled on the cluster, but a disk group is detected on this host"
- The output of "
esxcli vsan cluster get" reports the output "vSAN ESA Enabled: false"
Environment
VMware vCenter Server 8.0.3
VMware vSphere ESXi 8.0.3
vSAN OSA
vSAN ESA
Cause
The cluster configuration in vCenter Server is incorrectly configured to use the vSAN Express Storage Architecture (ESA), whereas the underlying physical hosts are deployed with disk groups conforming to the vSAN Original Storage Architecture (OSA). Because vSAN ESA utilizes Storage Pools instead of Disk Groups, vCenter Server cannot execute the legacy disk format migration on the detected OSA disk topology.
Resolution
The resolution is to create a new vSphere vSAN cluster within the vCenter Server inventory and ensure that the vSAN architecture profile is explicitly set to Original Storage Architecture (OSA). Hosts can be migrated to the new cluster without downtime using the following process.
Pre-requisites & Operational Guardrails:
Automated Infrastructure/VDI: This migration procedure is not recommended if the cluster hosts VMware Horizon or any other workload lifecycle application that dynamically auto-deploys and manages virtual machines, as it will require extensive re-configuration of the target cluster infrastructure within those platforms.
NSX Networking: If NSX/NSX-T is utilized on the cluster, verify that Transport Node Profiles (TNPs) are attached to the source cluster. Transport Node Profiles allow ESXi hosts to migrate across different cluster objects within the same vCenter Server instance without triggering an uninstallation or detachment of the NSX host transport modules. If TNPs are not configured, hosts moving outside the cluster object boundaries will systematically uninstall the NSX fabric components, severing network data paths.
Step-by-Step Cluster Migration Workflow:
Phase 1: Preparation
1. Log in to the vSphere Client.
2. Rename the current, mismatched cluster object by appending -old to the name.
3. Note all configuration parameters on the original cluster under Cluster > Configure > vSAN Services (Deduplication and Compression, Data-at-Rest Encryption, vSphere HA/DRS settings, and advanced cluster-wide options).
4. Create a new Cluster object within the same Datacenter inventory structure matching the original settings, ensuring that the vSAN architecture profile is explicitly configured for Original Storage Architecture (OSA).
Phase 2: Host Migration
1. Open an SSH session to each ESXi host currently residing in the old cluster.
2. Execute the following command on all ESXi hosts being migrated to disable host membership updates from active vCenter cluster configuration sweeps, this prevents transient network or cluster partitioning errors during the inventory migration.
esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListupdates
3. In the vSphere Client, right-click each ESXi host within the old cluster and select Connection > Disconnect.
4. Drag and drop each disconnected ESXi host from the old cluster object into the newly configured OSA cluster object.
5. Once all hosts have been successfully relocated into the new cluster hierarchy, right-click each disconnected host and select Connection > Connect.
Phase 3: Post-Migration
1. Navigate to the new Cluster > Monitor > vSAN > Skyline Health UI.
2. Verify that all health checks report healthy, the only health alarm expected to trigger is vCenter state is authoritative, due to the advanced runtime configuration value applied in Phase 2.
3. Re-enable host-level membership coordination by running the following command via SSH across all migrated ESXi hosts:
esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListupdates
4. Return to Cluster > Monitor > vSAN > Skyline Health.
5. Select the vCenter state is authoritative alarm, navigate to the Troubleshoot or remediation sub-pane, and click Remediate Inconsistent Configuration.
The new cluster should now be in working order without the appearance of any alarms referring to "Hyperconverged Cluster Configuration". Proceed with running the vSAN on-disk format upgrade from version 15 to version 20. If unexpected behaviors occur during execution, open a technical support request with Broadcom VCF vSAN Support
Additional Information
Feedback
