vSAN massive resync and degraded object health alerts after exiting Maintenance Mode

Products

VMware vSAN

Issue/Introduction

This article addresses a scenario where a vSAN cluster displays massive resync estimates, Skyline Health alerts, and Reduced Availability states immediately after a host exits Maintenance Mode. When a host is offline under the "Ensure accessibility" option, active virtual machines continue to write data to the remaining cluster nodes. This causes the data on the offline host to become stale components. Upon the host's return, provided it occurs before the default 60-minute clomd timeout, vSAN initiates a delta-sync rather than a full rebuild. This process updates the stale components to restore compliance. Administrators may observe artificially high resync sizes and temporary degraded object warnings, which can be concerning but are expected behaviors as the cluster synchronizes.

After a host exits Maintenance Mode (specifically when Ensuring Accessibility) and rejoins the vSAN cluster, the vSphere Client displays a massive active resync operation (often multiple Terabytes, e.g., ~26 TB) under Monitor > vSAN > Resyncing Objects.
Skyline Health displays critical alerts for vSAN object health and/or Physical disk operation health, specifically showing objects in a Reduced Availability (degraded) state.
Certain vSAN datastore objects, namespaces, or performance stats volumes may temporarily display as (inaccessible) in the vCenter Server inventory tree.
UI operations may occasionally fail and throw the error: "Cannot be completed due to inaccessible objects".
This behavior is highly common in smaller environments (e.g., 3-node or 4-node clusters), where maintenance tasks more easily trigger Reduced Availability states due to fewer fault domains.

Environment

VMware vSAN 8.x
VMware vSAN 9.x

Cause

The primary cause of these alerts is stale components due to host maintenance duration.

When a host is placed into Maintenance Mode with "Ensure accessibility," vSAN guarantees that all VMs remain online, but it does not fully evacuate the data. While the host is offline, active VMs continue to write new data to the remaining active hosts in the cluster. As a result, the data components residing on the offline host become stale. Because the objects are missing an active, up-to-date replica, vSAN correctly flags their health as degraded (Reduced Availability).

When the host is brought back online within the default Object Repair Timer, vSAN does not initiate a full data rebuild. Instead, it initiates a delta-sync to update the stale components. The massive resync size displayed in the vSphere UI often reflects the total size of the degraded objects being evaluated for synchronization, rather than the actual size of the delta payload that needs to be moved over the network. The actual time to sync is usually significantly shorter than the displayed capacity implies.

Resolution

No immediate remedial action is required. This is a transient state, and the cluster is working by design to sync the delta data and restore full FTT (Failures to Tolerate) policy compliance.

Follow these steps to verify the cluster is undergoing a normal recovery without underlying hardware faults:

Verify Object Health Run the following command via SSH on any host in the cluster to check the object states. As the sync progresses, objects will move from reduced-availability back to healthy. Command: esxcli vsan debug object health summary
Example Output:
```
Health Status                                     Number Of Objects
------------------------------------------------  -----------------
reduced-availability-with-active-rebuild          144
healthy                                           439
```
Monitor Resync Progress Run the following command to view the actual bytes remaining to sync. This value should steadily decrease. Command: esxcli vsan debug resync summary get
Example Output:
```
ResyncSummary:
   Total Number Of Resyncing Objects: 144
   Total Bytes Left To Resync: 28311552000
   Total GB Left To Resync: 26.37
```
Audit Hardware Logs Review the /var/run/log/vobd.log and /var/run/log/clomd.log on the host that recently rejoined the cluster to ensure no underlying physical disk failures or network partitions are causing the resync to stall.
Example of problematic events indicating a stalled resync:
If the resync is failing to progress, you will typically see corresponding errors in these logs rather than clean voting operations.
vobd.log (Hardware / Disk Failure Example): Watch for vob.vsan or vob.scsi events indicating that a physical drive has gone offline or lost connectivity.

YYYY-MM-DDTHH:MM:SS.000Z: [vob.vsan.lsom.diskerror] vSAN physical disk ####-####-####-####-######## has encountered an error and is offline.
YYYY-MM-DDTHH:MM:SS.000Z: [vob.scsi.scsipath.por] Path vmhba#:C#:T#:L# is dead and device naa.################ is in APD state.