VMware ESXi Host Not Responding – Fix It Now

When You See This Error

You're staring at vCenter, and one of your ESXi hosts is greyed out with the status "Not Responding." Maybe it happened after a network glitch, a power outage, or a recent patch. You try to right-click and power it off—nothing. You SSH into the host? Connection refused. It's not just a UI hiccup—it's a full management plane failure.

I've lost count of how many times I've seen this after a flapping network switch port or a failed DNS resolution during vCenter reconnection. The host itself is still running your VMs, but you're blind to it. That's the scary part.

Root Cause in Plain English

The ESXi management network (the vmkernel port for vCenter communication) lost connectivity. This can happen because:

The physical NIC or cable went bad.
The vSwitch or port group config got corrupted (rare, but yes).
The host's management agent (hostd or vpxa) crashed or hung.
DNS or hostname resolution broke—vCenter can't match the host's IP to its FQDN.
The host ran out of memory or swap space, killing its management stack.

In most cases, it's not that the host is dead—it's that the channel between vCenter and ESXi is down. You need to restore that channel without rebooting the host (and taking all VMs with it).

Fix It in 5 Steps

Step 1: Check Physical Connectivity

Walk over to the host (or use iLO/iDRAC/DRAC if you have out-of-band management). Log into the DCUI (Direct Console User Interface) by pressing F2. Check the network adapters and their link status. If you see no link light, that's your culprit. Swap cables, try a different switch port.

If you can't get into DCUI, use the ESXi shell via SSH (if it's enabled). But if SSH is also down, you're stuck with physical access.

Step 2: Restart Management Agents

Still in DCUI or SSH, run these commands to restart the management stack without a full reboot:

# Check which services are running
esxcli system mgmt services list

# Restart vpxa (vCenter agent) and hostd (ESXi host agent)
/etc/init.d/vpxa restart
/etc/init.d/hostd restart

Wait 30 seconds. Check if the host appears back in vCenter. This works about 60% of the time. If not, move on.

Step 3: Verify DNS and Hostname Resolution

On the host, run:

esxcli network ip dns server list

Make sure the DNS server is reachable. Then check that the host's FQDN resolves to the correct IP:

hostname -f
nslookup your_hostname

If the forward and reverse lookups don't match, update your DNS records or change the ESXi host's DNS settings via DCUI. This is a classic cause—vCenter tries to connect to the host's FQDN, and if that doesn't resolve, it gives up.

Step 4: Check Management Network via DCUI

In DCUI, go to Configure Management Network → Network Adapters. Make sure at least one adapter is selected. Then go to IPv4 Configuration and verify the IP, subnet mask, and gateway are correct. If the host's IP changed (e.g., due to DHCP expiry or manual change), fix it here and restart the management network.

To apply changes, press Esc and reboot the management network (not the host). The host will briefly drop all network traffic—your VMs will lose connectivity for a few seconds, so plan accordingly.

Step 5: Force vCenter to Reconnect

Back in vCenter, right-click the host (even though it's greyed out) and choose Reconnect. If that's not available, use the vSphere CLI:

vicfg-hostops --server vcenter_ip --username admin --action reconnect

Or, use PowerCLI:

Connect-VIServer vcenter_ip
Get-VMHost -Name hostname | ForEach-Object { $_ | Set-VMHost -State Connected }

Sometimes the host is actually fine but vCenter's polling just timed out. This forces a fresh handshake.

What To Check If It Still Fails

You've done all the above. The host still won't respond. Now you need to get aggressive:

Check the host's resource usage via DCUI: Go to System Customization → View System Logs → hostd.log. Look for out-of-memory errors or swap exhaustion. If the host is out of memory, you can't run any management commands—you'll need to manually power cycle the host through the hardware management interface (iLO/DRAC).
Temporarily disable the firewall on the host (not recommended in production, but for diagnostics):
```
esxcli network firewall set --enabled false
```
Then try the reconnect again. If it works, re-enable the firewall and check which rule is blocking the connection.
Check for a stuck vCenter task: If vCenter has a pending task (like a VMotion or snapshot) that's stuck, it can block the host from responding. Restart vCenter services or reboot vCenter (as a last resort).
Consider a full host reboot: I hate to say it, but if nothing else works, schedule a maintenance window, safely shut down all VMs (or vMotion them off if you can), and reboot the host. When it comes back up, it should reconnect cleanly.

Remember: this error is almost never a hardware failure. It's almost always a network or agent hiccup. Stay calm, work through the steps, and you'll have that host back in the green in under 15 minutes.