A VASA provider showing Connected in vCenter does not prove that every ESXi host has a usable session with it. Broadcom KB 459604 documents an ESXi 8.x case in which the provider invalidates its current session without communicating that change to ESXi. Hosts continue using a rejected session, and vVol operations fail while vCenter still shows the provider connected.
No provider, host, certificate or VM operation was changed for this source-only article. The commands below are unexecuted read-only examples; check exact installed help and authorised access before use.
Identify which relationship failed
A vVol investigation contains several identities: the vCenter, ESXi host, VASA provider, storage array, storage container and protocol endpoint. A healthy indication for one relationship should not be copied into the others.
In the documented session case, ESXi operations such as VM power-on, snapshot and migration fail. The host's vvold service records the provider communication problem. The question is therefore whether the affected host's request is accepted, not simply whether vCenter can list the provider.
Prerequisites are the failed task details, ESXi build, host identity, affected storage container/provider and approved access to existing host logs. Record when the failure began and whether it affects one host or several. Similar VM symptoms can arise from different storage failures.
Read the provider evidence on the host
The following queries are documented in KB 393805 for vSphere 8.0.3:
esxcli storage vvol vasaprovider list
esxcli storage vvol protocolendpoint list
esxcli storage vvol storagearray protocolendpoint list
They list state; they do not reset sessions, rescan adapters or change mappings. Their output can include infrastructure addresses and identifiers, so retain it privately and redact before sharing. On another build, verify that the same commands and fields are supported before relying on them.
For the provider, record its name, status and array identity. For protocol endpoints, correlate the host/LUN identifiers, storage container and Accessible/Configured fields. These checks help distinguish the provider-session question from an endpoint problem; they do not by themselves prove why a session was invalidated.
Then inspect the incident interval in /var/run/log/vvold.log. KB 459604 shows an initial “No VP available for array” message followed by repeated failures with:
INVALID_SESSION / Bad session state (Uninitialized)
Preserve the operation, provider and container surrounding that fragment. The generic “No VP available” line alone does not establish the documented cause. Match the same host and time to the failed VM task.
Worked interpretation
Consider a fictional vVol VM whose snapshot task fails on host esx-b. vCenter lists provider VP-A as connected. The host's existing vvold.log shows repeated getEvents failures naming VP-A and the same container, with the INVALID_SESSION fragment above.
Those observations explain how the two views can disagree: vCenter's connected status does not establish that esx-b's session remains valid. Retrying snapshots changes neither the identity of that session nor the provider's acceptance of it. The next decision is a qualified investigation of the host/provider session boundary and why the provider invalidated it.
Now change the evidence: a protocol endpoint is Accessible false and Configured false after an array-side deletion, without the session signature. KB 393805 documents that separate stale-endpoint case, including existing VMs continuing to run while other operations fail. It is not permission to transplant its endpoint-unmapping procedure into every VASA incident.
For the separate stale-endpoint branch, KB 393805 records “The object or item referred to could not be found”, “Module VMMon power on failed.” and provider Status: syncError. Correlate these with the Accessible/Configured endpoint fields and the array event; no single string proves stale endpoint ownership.
Choose the repair boundary carefully
KB 459604 documents reinitialising host/provider communication and, if necessary, restarting the host service, while asking provider support to investigate the invalidation. Those are operational changes, not read-only probes. This article supplies no reset or restart command because the required impact review and validation have not been performed.
KB 459604 reports host connectivity restored after a certificate refresh and documents host/provider session reinitialisation, followed by a service restart if needed. These are relevant vendor recovery actions, not off-target guesses, but require qualified change review and provider-side investigation. Unregistering a provider or remapping protocol endpoints is a different intervention and must not be inferred from this session diagnosis.
Acceptance and reversal
Diagnostic acceptance requires the affected host/provider/container identities, matched task and log timestamps, and evidence distinguishing session rejection from endpoint accessibility. Mark the cause provisional if the provider-side invalidation has not been confirmed.
After a separately reviewed repair, functional acceptance would require a valid host/provider relationship and successful completion of the originally failing operation under an approved test plan. vCenter's Connected label alone remains insufficient. No task was run for this article.
Reading inventory requires no rollback. A service restart or session reset has no meaningful “undo” that recreates the original session; it needs an impact and recovery plan. Storage mappings and certificates must not be altered as speculative reversal steps.
Learning notes
- vCenter connectivity and an ESXi provider session are different evidence.
- Match INVALID_SESSION to the exact host, provider and failed operation.
- A stale protocol endpoint is a separate failure, even when symptoms overlap.
References
- A20-S2: ESXi hosts disconnect from VASA Provider and lose access to vVOL datastore
- A20-S1: Various VM operations (VM Migration, snapshot operations, VM power on, etc) fail on VVOL datastore