Does vCenter Server automatically invalidate its inventory cache after an ESXi host network partition?

Question

Goal: Determine whether vCenter Server automatically purges stale inventory cache entries when an ESXi host loses network connectivity, or whether it relies solely on the cache expiration timeout to remove outdated data.

Constraints: The behavior may vary between vCenter Server Appliance and Windows‑based installations, across different vSphere releases (e.g., 7.0 Update 3 vs. 8.0 with the fast cache), and in Linked Mode configurations where cache propagation adds latency.

Uncertainty: VMware documentation does not explicitly guarantee immediate cache invalidation for network partitions, leaving the mechanism as an implementation detail that administrators have observed to require a manual refresh or service restart to correct stale VM power‑state displays.

Does vCenter Server immediately invalidate cache entries upon detecting a host network loss? Is the cache expiration timeout the only mechanism for removing stale data after a partition? Does Linked Mode affect the timing of cache invalidation across linked vCenter instances?

Tasadduq Burney · Answer

Short answer: no. vCenter Server does not document or guarantee immediate inventory-cache invalidation when an ESXi host loses management connectivity. On detecting the partition it marks the host disconnected or not responding and deliberately retains the last-known inventory state, including VM power states, until the host reconnects and inventory re-syncs. Most "stale cache" reports after a partition are this last-known-state behavior, not a cache defect.

The three sub-questions

Immediate invalidation on network loss?

No. Detection changes the host's connection status; it does not purge inventory. Retaining the host and its VMs while unreachable is intentional — vCenter keeps the record so management can resume on reconnect. I know of no documented purge-on-disconnect mechanism in vSphere 7.0 or 8.0.

Is an expiration timeout the only removal mechanism?

The premise does not hold. To my knowledge there is no documented TTL that expires a disconnected host's inventory entries; inventory, including last-known state, persists in the vCenter database. Stale values are corrected by reconnection and resync, not expiry. Caveat: vpxd's internal caches are undocumented implementation details, so I cannot rule out internal caching — treat any specific TTL claim as unverified.

Does Linked Mode affect invalidation timing?

Not as the question implies. Host inventory is authoritative per vCenter instance. Enhanced Linked Mode on 7.0/8.0 replicates SSO, tags, roles, and licenses across the embedded Platform Services Controllers, but a partition affecting hosts managed by vCenter A is not pushed to vCenter B as an invalidation. B's view of A's host is served from A, so there is no cross-instance cache-propagation delay to manage.

Version assumptions

Windows-based vCenter ended with the 6.7 line; 7.0 Update 3 and 8.0 are appliance-only, so the appliance-versus-Windows variable does not apply to those releases. I also cannot confirm a documented "fast cache" feature in vSphere 8.0 — treat that premise, and any version-specific cache behavior, as unverified until checked against current Broadcom documentation for your exact build.

Where the staleness actually lives

Stale power-state displays usually involve three layers, each with a different remedy:

vSphere Client (browser): stale rendering; a hard refresh fixes this layer.
vpxd in-memory inventory: the inventory Refresh action prompts a re-read, but an unreachable host has nothing new to return.
Last-known state in the vCenter database: survives client refreshes and even a vpxd restart — which is why restarting vpxd does not "fix" the display while the host is down. The last observed state is the best data vCenter has.

The practical consequence: if the host is unreachable, no amount of cache clearing reveals the true current state. Truth returns when the host reconnects and vCenter re-syncs, which happens automatically in the normal case. If agent state is inconsistent after the partition heals, an explicit Reconnect host action forces a clean resync.

Steps for this case

Note how the host is displayed: disconnected/not responding, or connected with stale data. This distinction changes the recommendation.
If disconnected: restore management connectivity (management VMkernel interface, DNS, firewall) and let vCenter reconnect and resync on its own.
If connected but stale after connectivity returned: browser hard refresh first, then the inventory Refresh action; a vpxd restart only as a last resort, since it briefly interrupts vCenter management.
Lab-verify if needed: disconnect a test host's management network, note when the client flips to disconnected, and how quickly inventory resyncs after connectivity returns.

One diagnostic detail would sharpen this: does your host show as disconnected, or as connected while displaying stale data? A disconnected host retaining last-known state is expected behavior; a host that shows connected but stale after connectivity returned suggests a resync problem worth a support case, with your exact version and build attached.