vSAN errors encountered during ESXi precheck in the Workload Domain after vSAN was removed outside of SDDC Manager

Products

• VMware SDDC Manager

Issue/Introduction

• While performing an ESXi upgrade precheck for a workload domain, an error related to vSAN is encountered. Investigation reveals that although the workload domain was initially configured with vSAN, vSAN was removed from the vCenter Server and SAN was configured as the primary storage outside of SDDC Manager. 
  
  
  
  SDDC Manager Logs indicate conflicting datastore types

• /var/log/vmware/vcf/lcm/lcm.log shows the datastore type as VMFS

  YYYY-MM-DDTHH:MM:SS] DEBUG [vcf_lcm,##########,####] [c.v.e.s.l.p.i.vsan.VsanHealthService,Async-28] For cluster id ##########-####-####-####-##########, the datastore type found is VMFS
  
  

• /var/log/vmware/vcf/operationsmanager/operationsmanager.log still references vSAN, with entries like setting datastore Type vSAN
  
  [YYYY-MM-DDTHH:MM:SS] INFO  [vcf_om,##########,89f1] [c.v.v.l.s.LicenseManagerServiceImpl,http-nio-127.0.0.1-7300-exec-##] Getting licensing information for resourceType DOMAIN, resourceIds [####################]
[YYYY-MM-DDTHH:MM:SS] DEBUG [vcf_om,##########,fcdc] [c.v.v.h.c.u.InventoryResourceAssembler,http-nio-127.0.0.1-7300-exec-##] Processing Host from inventory: <hostname>
[YYYY-MM-DDTHH:MM:SS] DEBUG [vcf_om,##########,ec6e] [c.v.v.h.c.u.InventoryResourceAssembler,http-nio-127.0.0.1-7300-exec-##] Processing Host from inventory: <hostname>
[YYYY-MM-DDTHH:MM:SS] DEBUG [vcf_om,##########,fcdc] [c.v.v.h.c.u.InventoryResourceAssembler,http-nio-127.0.0.1-7300-exec-#] setting datastoreType vSAN
[YYYY-MM-DDTHH:MM:SS] DEBUG [vcf_om,##########,ec6e] [c.v.v.h.c.u.InventoryResourceAssembler,http-nio-127.0.0.1-7300-exec-##] setting datastoreType vSAN
  
  

Cause

When storage configuration changes (such as removing vSAN and switching to SAN) are made outside the SDDC Manager, these changes are not automatically synced back to the SDDC Manager’s internal database.
As a result, SDDC Manager continues to reference vSAN, leading to mismatches between the actual datastore type and what the manager expects. This discrepancy causes vSAN-related errors during ESXi upgrade prechecks.

Resolution

To verify the issue:

1. SSH to the SDDC Manager appliance using an SSH client (e.g., PuTTY, OpenSSH) with the vcf user:
   
   ssh vcf@<SDDC_Manager_IP_or_Hostname>
   
   
2. Switch to the root user:
   
   su -
   
   
3. Run the following command to verify the primary datastore type:
   
   psql -h localhost -U postgres -d platform -c "SELECT id, name, primary_datastore_type, primary_datastore_name FROM cluster;"
   
   If the primary datastore type is listed as vSAN instead of the expected type(Eg. Fiber channel), this indicates a configuration issue.
   
   Please log a case with Broadcom Support for further assistance. Refer - Creating and managing Broadcom support cases