Loss of access to vSAN iSCSI LUNs due to the vSAN datastore being low on space.

Products

VMware vSAN

Issue/Introduction

Access to the iSCSI LUNs is suddenly lost.
Guest OS reporting failed to authenticate messages when trying to log into the vSAN iSCSI target
Below messages are seen in the vitd.log of all hosts in the vSAN cluster:

2026-07-03T11:32:03.589Z In(14) vitd[94512533] FILE:open error on /vmfs/volumes/vsan:52f9aeb7eda69da2-############/.iSCSI-CONFIG/etc/vit.conf: Interrupted system call
2026-07-03T11:32:03.589Z In(14) vitd[94512533] Thread-0x72fa255500 unable to open and lock config file /vmfs/volumes/vsan:52f9aeb7eda69da2-############/.iSCSI-CONFIG/etc/vit.conf: Interrupted system call
2026-07-03T11:32:03.589Z In(14) vitd[94512533] Thread-0x72fa255500 Failed to open config file, continuing with old configuration
vmkwarning.log:

2026-07-03T11:52:37.902Z Wa(180) vmkwarning: cpu66:135261901 WARNING: VSAN: VsanReleaseRangeLocks:1749: Failed: uuid 40189d65-9ae1-cacc-a6fa-############ lockOwnerUUID a656476a-6c2e-89d2-5d69-############ vsanFDSHandle 0x43153920d930 locks 1 status Connection timed out
2026-07-03T11:52:37.902Z Wa(180) vmkwarning: cpu66:135261901 WARNING: VSAN: VsanReleaseRangeLocks:1755: Terminating association with the owner
vSAN Health Service is reporting alerts for high disk space utilization.
Guest OS MPIO may drop paths to the vSAN iSCSI target depending on it's respective timeout interval waiting for the path to become active again

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

Environment

VMware vSAN (All Versions)
vSAN iSCSI

Cause

This is due to high disk space utilization resulting in low free space. Health logs confirm a Red Alert under a single host failure simulation (esxi01), with total disk space utilization reaching 90.87%:

2026-07-03T09:22:36.913Z INFO vsan-mgmt[255966] [VsanHealthSummaryLogUtil::PrintHealthResult opID=agw-0124396-f46a] Cluster vSAN_Cluster01 Overall Health : red
Group limits health : red
Test limit1hf health : red
ClusterLevel: Resource Utilization Health
(ComponentUtilization, 11%(5202Of45000), Green), (DiskSpaceUtilization, 90.87%(123143.70GbOf135508.95Gb), Red),

This capacity threshold breach automatically triggers, reactive background object rebalancing (resync I/O) across the storage tier and negatively impacts overall vSAN cluster performance such as in this case accessing vSAN iSCSI LUNs.

Because the local range lock association was forcibly terminated, the corresponding storage component will be marked offline. This forces a rapid, back-to-back target configuration cluster update across several active LUN mappings within a matter of seconds:

2026-07-03T11:52:38.051Z In(14) vitd[94512533]: Thread-0x7328a8a700 Applying config generation 99
2026-07-03T11:52:49.252Z In(14) vitd[94512533]: Thread-0x7328a8a700 Applying config generation 100
2026-07-03T11:52:49.406Z In(14) vitd[94512533]: Thread-0x7328a8a700 Applying config generation 101

Every time an update comes in, the service has to open the configuration file (vit.conf) to apply changes. Due to the ongoing storage congestion, opening the file takes longer than usual; before it can finish, the next wave of internal alarms interruptes the process and causes the file-open attempt to fail completely. Per the safeguard in the design, this interruption causes the service to immediately give up and run on an outdated memory state where the drives were already marked offline, resulting in an instant loss of connectivity for all connected guest servers.

Resolution

To prevent this from occurring ensure to maintain plenty of free space within the vSAN cluster. Recommend free space be below 80% ideally around 70% See the below docs for reference.

vSAN Health Service - Capacity utilization - Storage space

Understanding Reserved Capacity Concepts in vSAN

Workaround:

If the cluster is already impacted and vSAN iSCSI LUN access is lost open a case with vSAN Support for assistance with restoring conectivity.