Virtual machine becomes inaccessible after the vSAN network outage

Products

• VMware vSAN

Issue/Introduction

 Symptoms

• Virtual machines may become inaccessible after recovering from an unplanned network outage like inter site link outage. 

• vSAN objects will go inaccessible. 
  
  Run the below commands  to collect list of inaccessible objects. 
  
  # esxcli vsan debug object list --health=inaccessible

  Object UUID: a26fa467-e005-####-####-############
  Version: 15
  Health: inaccessible - Object is initializing or creating.(APD)
  Owner: esxi01
  Used: 21846.21 GB
  hostFailuresToTolerate: 1
  subFailuresToTolerate: 1
  CSN: 3054
  SCSN: 3181
  spbmProfileName: vsanRaid5-Stretched(Cluster01)
  locality: None
  Path: N/A
  Group UUID: a775a367-844d-####-####-############
  Directory Name: N/A

• vCenter UI > Cluster > Monitor > vSAN > Resyncing Objects may show resync not progressing.

• ESXi host may not enter maintenance mode with Ensure Accessibility and Full data evacuation options due to the inaccessible object.

 

vSAN Cluster will become Network partitioned and vsansystem logs will show the nodeCount fluctuating: 

2025-05-24T06:57:01.078Z info vsansystem[2102272] [vSAN@6876 sub=VsanSystemProvider opId=CMMDSMembershipUpdate-9426] Complete, nodeCount: 13, runtime info: (vim.vsan.host.VsanRuntimeInfo) {
.
.
2025-05-24T06:57:05.840Z info vsansystem[2102264] [vSAN@6876 sub=VsanSystemProvider opId=CMMDSNodeUpdate-973e] Complete, nodeCount: 9, runtime info: (vim.vsan.host.VsanRuntimeInfo) {
.
.
2025-05-24T06:57:34.233Z info vsansystem[2102132] [vSAN@6876 sub=VsanSystemProvider opId=CMMDSNodeUpdate-a1c8] Complete, nodeCount: 13, runtime info: (vim.vsan.host.VsanRuntimeInfo) {

Environment

VMware vSAN (All Versions)

Cause

 

• This is rare case scenario where the affected object entered an APD (All Paths Down) state due to the exhaustion of available resync scheduler slots, causing resynchronization tasks to become stuck and unable to progress.

• The environment shows frequent small and large ping test failures, indicating an unstable network or inter-switch link (ISL). This network instability can lead to repeated object rebuilds, increasing the risk of resync contention

 

Resolution

 

• This issue has been addressed in vSAN 8.0 P05 and later releases.

• It is also recommended to review the network configuration and stability to minimize rebuild triggers and resync slot exhaustion.

 

Additional Information

Reference :vSAN Skyline Health - Data Health - vSAN Object Health - inaccessible objects