One host not contributing storage to vSAN cluster

Products

VMware vSAN

Issue/Introduction

When managing a vSAN environment, you observe the following symptoms within the vSphere Client (vCenter):
- In Cluster -> Configure -> vSAN -> Fault Domains, one specific host shows no claimed disk groups or is not contributing storage capacity.

- Despite the missing storage, all vSAN objects appear as "Healthy" when viewed in Cluster -> Monitor -> vSAN -> Virtual Objects.
- The affected host appears to be a member of the cluster and is not in Maintenance Mode.

Environment

VMware vSAN 8.x

Cause

This issue is caused by network connectivity degradation or interruptions on the management network between the vCenter Server and the affected ESXi host.
While the host may remain part of the vSAN cluster at the storage layer, the management plane (vCenter) cannot retrieve the storage configuration. You can confirm this by reviewing the vsansystem.log on the affected host:

[from /var/log/vsansystem.log on ESXi host]

2026-03-16T15:34:53.315Z Wa(164) vsansystem[2102248]: [vSAN@6876 sub=AdapterServer] Request 'queryNodeInformation' on 'vsan-performance-manager' from '##.##.##.##' (########-####-####-####-############) is

discarded: Too many outstanding requests

2026-03-16T15:34:53.316Z Wa(164) vsansystem[2102248]: [vSAN@6876 sub=IO.Connection] Failed to read buffer from stream; <io_obj p:0x000000b994f87e40, h:284, <TCP '127.0.0.1 : 9096'>, <TCP '0.0.0.0 : 0'>> e: 1

04(Connection reset by peer), async: true, duration: 0msec

2026-03-16T15:34:53.316Z In(166) vsansystem[2102248]: [vSAN@6876 sub=VsanSoapSvc.HTTPService.HttpConnection] Failed to read header; <io_obj p:0x000000b994f87e40, h:284, <TCP '127.0.0.1 : 9096'>, <TCP '0.0.0

.

0 : 0'>>: N7Vmacore15SystemExceptionE(Connection reset by peer: The connection is terminated by the remote end with a reset packet. Usually, this is a sign of a network problem,  timeout, or service overloa

d.)

...where '##.##.##.##' is the vCenter Server IP address.

Resolution

Validate Connectivity: From an ssh session to the ESXi host, verify the path to vCenter from command line:

# vmkping -I vmk# <vCenter IP address>

PING ##.##.##.## (##.##.##.##): 56 data bytes

64 bytes from ##.##.##.##: icmp_seq=0 ttl=64 time=0.978 ms

64 bytes from ##.##.##.##: icmp_seq=1 ttl=64 time=1.009 ms

64 bytes from ##.##.##.##: icmp_seq=2 ttl=64 time=1.001 ms

Reset Management Interface: If pings fail or latency is high, toggle the management interface:

# esxcli network ip interface set -e false -i vmk#

# esxcli network ip interface set -e true -i vmk#

NOTE: Be sure to replace 'vmk#' with the appropriate management vmkernel port.

Reboot Host: If the management connection remains unstable, perform a graceful reboot of the affected host to re-establish a clean connection to vCenter.

Additional Information

For more information on verifying and resolving network connectivity issues, see KB: Troubleshooting network and TCP/UDP port connectivity issues on Hosts