Interactive Troubleshooter

Published: Sep 1, 2026

VMware ESXi Host Not Responding: Recovery Steps

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An interactive root-cause diagnostic tree to systematically isolate and recover unresponsive VMware ESXi hosts in vCenter. Resolve management agent deadlocks, Purple Screen of Death (PSOD) kernel panics, storage APD/PDL lockups, and VMkernel network isolation.

Full Diagnostic Tree & Step-by-Step Overview

What is the physical host state and console status of the unresponsive ESXi host?

Host is marked 'Not Responding' in vCenter, but virtual machines are still running and SSH/DCUI is accessible
Physical host console displays a Purple Screen of Death (PSOD) kernel panic or hardware error dump
Host management IP is completely unreachable via Ping/SSH, or storage locks have completely frozen host I/O

What specific management agent or communication fault is preventing vCenter from syncing with the host?

ESXi host management daemons (hostd / vpxa) are deadlocked or failing due to RAM / log partition exhaustion
vCenter Agent (VPXA) heartbeat timing out on Port 902 or SSL certificate trust validation failure

Restart ESXi Host Management Services and Flush Exhausted Ramdisks

Solution:

Root Cause: Unresponsive Host Management Daemons (hostd / vpxa Thread Lock)

When an ESXi host shows as 'Not Responding' in vSphere while hosted Virtual Machines continue to function, the primary management daemon (hostd) or the vCenter agent daemon (vpxa) has deadlocked. This typically occurs due to high management API load, exhausted system ramdisk space (/tmp or /var/log), or thread lockup.

# Step-by-Step Fix:

Access ESXi via Direct Console (DCUI) or SSH:

Connect to the host using SSH or open the Out-of-Band console (iLO/iDRAC/KVM).

Check Ramdisk Space Utilization:

Verify that local ramdisks are not 100% full:

bash
   vdf -h

If /tmp or /var/log is full, clear old log files or temp dumps:

bash
   rm -f /tmp/*.log

Restart Management Agents via Shell:

Execute the unified management restart script:

bash
   /sbin/services.sh restart

Alternatively, restart specific daemons independently:

bash
   etc/init.d/hostd restart
   etc/init.d/vpxa restart

Reconnect Host in vCenter:

Right-click the host in vSphere Client > Host > Connection > Reconnect.

Re-establish VPXA Agent Heartbeat and Renew Host SSL Certificates

Solution:

Root Cause: Disrupted VPXA Heartbeat (UDP/TCP Port 902) or SSL Certificate Mismatch

vCenter server monitors ESXi hosts by sending regular heartbeat packets over UDP Port 902. If firewall rules block Port 902, or if host SSL certificates expired or desynchronized after a vCenter rebuild, vCenter disconnects the host even if hostd is healthy.

# Step-by-Step Fix:

Verify Port 902 Connectivity between ESXi and vCenter:

Test TCP port 902 outbound from the ESXi host shell to vCenter:

bash
   nc -z -v <vCenter_IP_or_FQDN> 902

Force Re-registration of VPXA Agent:

Remove temporary vCenter configuration files on the host:

bash
   /etc/init.d/vpxa stop
   rm -f /etc/opt/vmware/vpxa/vpxa.cfg
   /etc/init.d/vpxa start

Renew Host SSL Certificates via vSphere Client:

In vSphere Client, right-click the disconnected host > Certificates > Renew Certificate.

Force Host Re-connection:

Right-click host > Connection > Reconnect to re-download the vCenter trust bundle.

What type of kernel dump or hardware crash details are displayed on the purple console screen?

Hardware Machine Check Exception (MCE), NMI panic, or Memory ECC crash
Driver stack crash (e.g., qcnic, ixgben, megaraid_sas) or ESXi native driver purple screen

Extract Core Dump and Replace Faulty Hardware Components

Solution:

Root Cause: Hardware Machine Check Exception (MCE) or Uncorrectable RAM Failure

A Purple Screen of Death (PSOD) displaying Machine Check Exception (MCE), NMI Interrupt, or PCPU failure indicates that the physical server motherboard, CPU, or ECC RAM experienced an unrecoverable hardware fault, forcing the VMkernel to crash to protect data integrity.

# Step-by-Step Fix:

Document PSOD Exception Data:

Record the exact failure strings on the screen, specifically lines starting with PCPU, Failed at, and backtrace register dumps (CR0, CR3).

Audit System Event Log (SEL) in Server Management Controller:

Check System Event Log and Memory Diagnostics for physical DIMM location errors or CPU socket voltage drops.

Extract Coredump Diagnostic Log Post-Reboot:

Reboot the server and extract the dump partition logs using ESXi shell:

bash
   esxcli system coredump partition list
   esxcli system coredump file list

Replace Degraded Hardware:

Replace the failing physical RAM module or CPU identified in the hardware logs before placing host back into production.

Update or Rollback Faulty ESXi Hardware Device Drivers (VIBs)

Solution:

Root Cause: Device Driver Stack Panic (NIC / Storage HBA VIB Instability)

Incompatible, corrupted, or bug-ridden Network Interface Card (NIC) or Host Bus Adapter (HBA) native drivers can cause a VMkernel exception. The PSOD backtrace will explicitly reference driver modules such as ixgben, qcnic, lpfc, or lsi_msgpt3.

# Step-by-Step Fix:

Identify the Crashing Driver VIB from PSOD Backtrace:

Note the topmost driver module listed in the PSOD call stack sequence.

Reboot Host into ESXi Safe / Recovery Mode (If Host Boot Loops):

During host startup on the ESXi loading screen, press Shift + R to enter Recovery Mode and roll back to the previously installed ESXi hypervisor build.

Audit Installed Driver Version via SSH:

bash
   esxcli software vib list | grep -E "ixgben|qcnic|lpfc|megaraid"

Install Updated Vendor-Certified Driver Pack:

Download the VMware Certified driver VIB from VMware Customer Connect and install via CLI:

bash
   esxcli software vib update -d /vmfs/volumes/DatastoreName/driver-offline-bundle.zip

Cross-Check VMware Compatibility Guide (VCG):

Ensure host card hardware firmware matches the exact supported driver version in VCG.

What physical layer or storage path failure is causing the host lockup?

All-Paths-Down (APD) or Permanent Device Loss (PDL) on SAN/NAS storage datastores
Management VMkernel interface (vmk0) network link down or incorrect VLAN tagging

Clear Storage APD/PDL Conditions and Restore Storage Pathing

Solution:

Root Cause: Storage Array All-Paths-Down (APD) Lockup on Management Volume

When Fibre Channel, iSCSI, or NFS storage arrays drop connectivity without a clean unmount, the ESXi host enters an All-Paths-Down (APD) state. Storage I/O retries block ESXi management threads (hostd), causing the entire host to report as 'Not Responding' in vCenter.

# Step-by-Step Fix:

Identify Devices in APD or PDL State via ESXi Shell:

Query storage device availability states:

bash
   esxcli storage core device list | grep -i State

Enable APD Timeout to Prevent Infinite Host I/O Lockup:

Verify that APD timeout parameters are active (default 140 seconds):

bash
   esxcli system settings advanced list -o /Misc/APDTimeout

Force Unmount or Abort Dead Storage Paths:

Turn off dead storage devices to free trapped system threads:

bash
   esxcli storage core device set --state=off -d <NAA_Extension_ID>

Rescan Storage Adapters Once SAN/NAS Fabric is Restored:

Re-establish storage fabric link and trigger host adapter rescan:

bash
   esxcli storage core adapter rescan --all

Reset VMkernel Management Network via Console (DCUI)

Solution:

Root Cause: VMkernel Management Network Disconnection (vmk0 Isolation)

If the primary management interface (vmk0) loses physical uplink connectivity, suffers incorrect VLAN tagging, or undergoes a bad vSwitch configuration change, the ESXi host becomes unreachable on the network while local VMs continue running.

# Step-by-Step Fix:

Access Server via IPMI/iLO/iDRAC Console:

Open virtual console and press F2 to enter the Direct Console User Interface (DCUI).

Navigate to Network Settings:

Go to Configure Management Network > Network Adapters and verify physical uplinks (vmnic0, vmnic1) are checked and reporting Connected status.

Verify VLAN ID Configuration:

Select VLAN (optional) and verify the correct management VLAN tag is assigned.

Run Network Test Diagnostic:

Select Test Management Network. Verify ping success to default gateway and vCenter IP.

Execute Management Network Reset:

If ping fails, select Restart Management Network or use Restore Network Settings to reset vmk0 to factory defaults.

Related Diagnostic Guides

Google Account Suspicious Activity? How to Check for Unknown Devices

Microsoft Account Hacked? How to Recover and Secure Your Account

Fast Charging Not Working? How to Check USB PD and Quick Charge Support

Laptop Using Integrated Graphics Instead of Dedicated GPU? Here's How to Fix It

Google Family Link Not Blocking Apps? Here's How to Fix It

Subscribe to StepDiag

Embed Guide on Your Website