VCF 9 Validate & Deploy fails with error: "VSAN storage cannot be used as primary datastore for cluster because of failure in [vsanObjectHealthStatus]"

Products

• VMware vSAN

Issue/Introduction

Symptoms:

• During the Validate & Deploy phase of a VMware Cloud Foundation (VCF) deployment or expansion, the SDDC Manager UI fails with the following validation error:

"No common datastore (vSAN, NFS, or FC) matches import criteria. VSAN storage cannot be used as primary datastore for cluster [Cluster-Name] because of failure in [vsanObjectHealthStatus]."

• Additional Indicators:
  
  
  • vSAN Skyline Health displays warnings for Virtual Objects.
  • Running "esxcli vsan debug object health summary get" on an ESXi host confirms objects are in an inaccessible or reduced-availability-with-no-rebuild state.

Environment

• VMware Cloud Foundation (VCF) 9.x
• VMware ESXi 8.x

Cause

VCF requires a fully healthy vSAN storage foundation to proceed with deployment. Even orphaned objects from decommissioned VMs will trigger a vsanObjectHealthStatus failure, causing VCF to halt the workflow to prevent provisioning on an unstable cluster.

 

 

Resolution

1. Identify and Address Inaccessible Objects:
   
   
   • Before proceeding, check if any objects are in the Inaccessible state.
     
     Action: Run "esxcli vsan debug object list --health=inaccessible" to find inaccessible UUIDs.
     
     IMPORTANT: If objects are Inaccessible, do NOT attempt to delete them. This indicates a potential data loss scenario or a critical cluster failure. Engage Broadcom Support immediately to follow the appropriate data recovery workflow.
     
     
2. Identify Degraded/Orphaned Objects:
   
   
   • If no objects are inaccessible, but objects remain in reduced-availability-with-no-rebuild:
     
     Action: Retrieve the specific UUIDs using the ESXi CLI:
     
     esxcli vsan debug object list --health=reduced-availability-with-no-rebuild
     
     Alternatively, locate the UUIDs in the vCenter UI > Monitor > vSAN > Virtual Objects tab.
     
     
3. Verification and Consent:
   
   
   • Verify that the identified UUIDs belong to orphaned components (e.g., stale VM Home or vSwap files) from VMs that have been permanently decommissioned.
     
     MANDATORY: The user must obtain explicit customer consent before proceeding with the deletion of any vSAN objects.
     
     
4. Purge Stale Objects:
   
   
   • Once consent is received and the objects are confirmed to be orphaned, purge them from the ESXi shell using "objtool":
     
     /usr/lib/vmware/osfs/bin/objtool delete -u [OBJECT_UUID] -f
     
     
5. Resume VCF Workflow:
   
   
   • After the "esxcli vsan debug object health summary get" command shows zero degraded objects, restart the Validate & Deploy workflow in SDDC Manager.

Additional Information

• To speak with a customer representative or a Support Engineer, see Contact Support.
• Subscribe to this article to receive updates: How to subscribe to Knowledge Management articles.
• Reduced availability with no rebuild" in vSAN object health
• vSAN Health Service - Data Health - vSAN Object Health - inaccessible objects