An ESXi 8.0 host intermittently enters a Not Responding or Disconnected state in vCenter Server. VMs continue to run but are shown as disconnected. The host may auto-recover without intervention after several hours.
Specific log signatures include:
/var/run/log/hostd.log: error hostd[ID] [Originator@6876 sub=Default] DJGetComputerDN: 0x9cb9: The domain is offlinewarning hostd[ID] [Originator@6876 sub=Default] hostd performance has degraded due to high system latencyinfo hostd[ID] [Originator@6876 sub=Default] hostd detected to be non-responsive
/var/run/log/syslog.log: lwsmd[ID]: [netlogon] CLDAP ping to cached DC #### failedlwsmd[ID]: [netlogon] CLDAP timed out: ####.COMlwsmd[ID]: [lsass] Found domain '####.COM' to be offline while resolving its objects.
/var/run/log/vpxa.log: error vpxa[ID] [Originator@6876 sub=vpxavpxaInvtHost] [VpxaInvtHost::QueryNetworkHint] Failed to query network hint: vmodl.fault.HostCommunicationwarning vpxa[ID] [Originator@6876 sub=Default] [VpxaHalCnx] No connection to hostd; [Connection reset by peer]
ESXi 8.0
This issue occurs when the ESXi hostd management agent triggers its periodic ValidatePermissions() background task (typically every 90 minutes). If the Active Directory (AD) Domain Controllers are unreachable or experiencing high latency via the Likewise (lwsmd) service, hostd threads may hang while waiting for a response from the domain. This leads to a mutex deadlock that renders the management agents unresponsive.
The host auto-recovers once the network path to the AD environment is restored or the internal Likewise timeouts are reached, releasing the blocked threads.
There is no specific ESXi configuration change to prevent the ValidatePermissions() task from reaching out to AD if the host is domain-joined. The permanent fix involves ensuring stable network connectivity to the Active Directory environment.
VCF Environments:
For VCF deployments, ensure that the management network has redundant paths to the Domain Controllers and that firewall rules permit traffic on the required ports (88, 389, 445).
Non-VCF / Standard ESXi:
If the issue persists despite stable networking, consider implementing the lwisOomCheck service (available in ESXi 8.0 Update 3e and later) to monitor Likewise health.
If the host is able to reach AD and still issue persists after successful checks as mentioned above, Engage Broadcom support for further assistance.