ESXi Host Disconnected in vCenter: Diagnosing and Fixing the Connection

vCenter reports two different states when it loses contact with an ESXi host, and they mean different things. "Disconnected" is a management-plane decision — vCenter suspended its relationship with the host. "Not responding" is a heartbeat failure — vCenter stopped receiving the UDP packets the host sends every 10 seconds on port 902. The diagnostic path depends entirely on which of those two states is showing.

Broadcom's documentation and Dell's support KB draw the line explicitly. A disconnected host has been disconnected from the vCenter side, whether manually by an administrator, by a transient failure after which vCenter failed to re-establish its management connection, or by a certificate problem. vCenter stops actively managing a disconnected host until it is reconnected. The host object remains in inventory, but normal management operations through vCenter are unavailable or limited. A not-responding host is one where vCenter has not received a heartbeat within its 60-second window. The host might be completely down, or it might be fine with only the management network unreachable. VMs keep running in both states.

How the heartbeat actually works

ESXi hosts send UDP heartbeat packets to vCenter on destination port 902 every 10 seconds. vCenter counts these and expects at least one to arrive within a 60-second window. If none arrives, the host transitions to "not responding." This is documented in Broadcom KB 318647 and KB 323612, and confirmed by independent investigation at xkln.net.

That means the root cause of any "not responding" state is one of three things. The host is actually down (hardware failure, purple screen, power loss). The host is up but its management agents are not sending heartbeats (hostd or vpxa crashed or hung). Or the host is up and sending heartbeats, but they are not reaching vCenter (network path, firewall, routing).

Figuring out which of those three you are dealing with is the entire diagnostic job.

Start with the fastest fix: restart the management agents

When a host shows as not responding or disconnected but the host hardware is up — ping responds, VMs on it are still serving traffic, iLO or iDRAC shows it powered on — the management agents are the first thing to check. The hostd daemon is the core ESXi management agent. The vpxa agent is the vCenter proxy that runs on each host and relays communication between hostd and vCenter. If either one crashes or hangs, heartbeats stop.

To restart both agents from the ESXi shell or SSH:

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

From the Direct Console User Interface, press F2 to log in, then navigate to Troubleshooting Options and select Restart Management Agents. This restarts hostd, vpxa, and several other management-related services. If SSH and the management network are both unreachable and you need physical console access, a crash cart or KVM console adapter gets you to the DCUI without relying on the network stack.

The services.sh restart command restarts all ESXi services at once. It is heavier-handed and takes longer, but resolves cases where multiple services have degraded. Broadcom KB 320280 documents all three restart methods.

I have seen hosts where hostd restart alone fixes the problem within 30 seconds and the host reconnects to vCenter automatically. I have also seen hosts where hostd restarts cleanly but the host stays disconnected because the underlying issue was a certificate problem or a stale network configuration. The agent restart is the starting point, not the guaranteed fix.

The UDP 902 firewall problem

If a host disconnects at consistent 60-second intervals — reconnects, runs for about a minute, then drops again — that pattern is the signature of UDP port 902 being blocked or rate-limited somewhere in the network path. Broadcom KB 323612 calls this out explicitly.

The classic heartbeat path runs over UDP port 902. ESXi sends small UDP packets to vCenter roughly every 10 seconds. If vCenter misses those heartbeats for the timeout window, the host transitions to not responding. Other management-plane failures, including DNS, TCP 443, vpxa, hostd, and vpxd issues, can produce similar symptoms, so treat the heartbeat path as one branch of the diagnostic tree, not the whole story.

To test TCP 902 reachability from the host:

nc -zv <vcenter-ip> 902

Do not treat a passing TCP netcat test as proof that UDP heartbeat traffic is passing. UDP is connectionless, so netcat results are ambiguous. For UDP verification, run a packet capture on the VCSA instead:

tcpdump -i any udp port 902 and host <esxi-management-ip>

If tcpdump shows no UDP 902 traffic from the expected ESXi management IP, either the host is not sending heartbeats from that interface or something in the path is dropping or filtering them. The packets are small and infrequent, so they do not trip bandwidth alarms. They just quietly disappear.

Common culprits include a firewall rule added between segments, a routing change, an IPS that started flagging the traffic as anomalous, or a switch ACL that does not forward UDP 902 across a VLAN boundary. Run tcpdump from both sides to narrow down where the drop happens.

If tcpdump on the VCSA shows no traffic from the ESXi host's IP on port 902, the packets are being dropped somewhere in between. Check physical switches, firewalls, distributed switch port group security policies, and any network virtualization overlay that might be filtering UDP.

A related trap: if a host was added to vCenter by IP address and that IP changes through the DCUI, vCenter keeps trying the old address. If DNS or FQDN updates do not resolve it, disconnect and remove the host from vCenter and re-add it using the correct FQDN or IP.

Certificate expiry: the silent disconnect

ESXi hosts use SSL certificates for the management interface, and these certificates expire. When a host's certificate expires or becomes invalid, vCenter may refuse the connection and mark the host as disconnected. Broadcom KB 414244 documents this failure mode.

This has become more frequent since vSphere 8.0 because VMware moved to two-year certificate validity for ESXi host certificates by default. Environments that deployed 8.0 in 2023 or 2024 are hitting the expiration window now. The vSphere Client shows a "Host Certificate Status" alert before expiration, but it is easy to miss among other alarms.

To check a host's certificate dates from SSH:

openssl s_client -connect localhost:443 -showcerts 2>/dev/null | openssl x509 -noout -dates

To renew from vCenter: select the host, go to Configure, then System, then Certificate, and click Renew. On vCenter 8.0 Update 3 and later, Broadcom improved the renewal workflow through the vSphere Client GUI. If renewal fails from the GUI — which it sometimes does when the cert is already fully expired — Broadcom KB 377969 describes a manual process: disconnect the host from vCenter, renew the certificate via shell, then reconnect.

After any certificate replacement, restart vpxa on the host:

/etc/init.d/vpxa restart

If vCenter itself is having certificate issues after a replacement, the vpxd service on the VCSA may need a restart:

# On VCSA shell
service-control --stop vpxd
service-control --start vpxd

For a broader look at VCSA lifecycle and management workflows, the vCenter Server Appliance deployment guide covers initial setup and the certificate plumbing that matters when hosts start dropping.

License and entitlement checks

Licensing is rarely the first explanation for a host that suddenly goes not responding. ESXi does not immediately stop running workloads just because a subscription renewal is late. Under Broadcom's subscription model, the main risks are compliance, support, updates, and upgrade rights, not a hard shutdown of the host.

That said, license assignment problems can still create vCenter alarms or management friction, especially after a migration from perpetual keys to subscription entitlements. If a host remains disconnected after you have checked agents, network, DNS, and certificates, verify the assigned license in vCenter under Administration, Licensing, Assets. Confirm the host is assigned the intended vSphere edition and that the entitlement matches the contract. For shops that moved from perpetual to subscription, a transition that ended new perpetual sales in early 2024, this is worth checking after any licensing change.

PowerCLI can inventory host states across the cluster, which surfaces license-related alarms alongside other states:

Connect-VIServer -Server vcenter.yourdomain.local

Get-VMHost | Sort-Object ConnectionState, Name |
    Select-Object Name, ConnectionState, PowerState, Version |
    Format-Table -AutoSize

For proactive compliance reporting, the license expiration PowerCLI guide and the license compliance automation article cover scheduled report setups that flag upcoming expirations before they become operational surprises. For the contract mechanics behind entitlement changes under Broadcom, the broader licensing breakdown is the reference.

When the host is truly unreachable

If the host does not respond to ping, SSH, and the DCUI is inaccessible through iLO or iDRAC, the host is genuinely down. The causes break into a few categories.

Hardware failures are the first thing to rule out. Power supply, motherboard, CPU, or memory faults will all take a host down. Check the iLO or iDRAC event log for hardware faults before dispatching anyone to the datacenter. The lights-out controller often has the answer before anyone touches the server.

The Purple Screen of Death means ESXi hit an unrecoverable error and halted. The purple diagnostic screen stays on the console with a stack trace. Photograph the full PSOD before rebooting, because the log is also captured in /scratch/log/vmkernel.log on persistent storage if the host comes back on its own.

Storage path loss is sneakier. If the host loses all paths to its storage, VMs may freeze and hostd can hang trying to enumerate datastores. Broadcom KB 416237 documents cases where FC HBA path issues cause hosts to disconnect and VMs to enter a hung state. The KB specifically calls out devloss tmo events on WWPNs, pointing to SAN switch port problems. Check zoning, LUN masking, and HBA firmware.

Network saturation is the last common cause. If the management network is saturated by a VM gone rogue (backup job, replication storm, malfunctioning NIC teaming), heartbeats cannot get through even though the host and agents are healthy. Check physical switch port utilization on the management VLAN.

Batch diagnosis and programmatic reconnect

When multiple hosts disconnect simultaneously, manual troubleshooting one host at a time is slow. PowerCLI can inventory the entire cluster's state and flag patterns:

Connect-VIServer -Server vcenter.yourdomain.local

Get-VMHost | Sort-Object ConnectionState, Name |
    Select-Object Name, ConnectionState, PowerState,
        @{N='UptimeDays';E={
            if ($_.ExtensionData.Runtime.BootTime) {
                [math]::Round(((Get-Date) - $_.ExtensionData.Runtime.BootTime).TotalDays, 1)
            } else { 'N/A' }
        }},
        @{N='Version';E={$_.Version}} |
    Format-Table -AutoSize

This shows which hosts are down, how long they have been up, and their vSphere version — enough to group the problem by cause. If four hosts on the same top-of-rack switch all went not responding at the same time, the switch is the suspect, not the hosts.

To reconnect a host programmatically:

# Reconnect a disconnected host that vCenter still knows about
Set-VMHost -VMHost esxi-04.lab.local -State Connected

# If that fails, disconnect fully and re-add with credentials
Set-VMHost -VMHost esxi-04.lab.local -State Disconnected
Connect-VIServer -Server esxi-04.lab.local -User root -Password 'yourpassword'
Add-VMHost -VMHost esxi-04.lab.local -Location 'Production Cluster' -Force

Adjusting the heartbeat timeout

Some administrators increase vCenter's heartbeat timeout via advanced configuration to reduce false alerts:

config.vpxd.heartbeat.notRespondingTimeout

The default is 60 seconds. MW: Tech's blog documents setting it to 120 or 240. This reduces noise from transient network blips, but it also delays detection of real host failures. Do not assume the change is harmless. It may reduce noisy vCenter alarms, but it does not fix HA isolation, management network, or heartbeat problems. vSphere HA has its own failure-detection mechanisms through FDM agents and datastore and network heartbeating, so validate HA behavior separately before changing timeout values in production.

If constant false disconnects are the problem, increasing the timeout is treating the symptom. The network issue dropping heartbeats is the actual problem. The timeout adjustment works as a temporary measure during investigation, not as a permanent configuration.

The post-patch disconnect

A pattern reported in community threads: hosts disconnect from vCenter after applying ESXi or VCSA patches. Administrators have noted this around vSphere 8.0 Update 3-era updates. Treat this as a known pattern to check after patching, not as proof that a specific patch is defective. The fix reported by multiple administrators is logging into the host via SSH and restarting the management network or the management agents:

# Bounce the management network interface
esxcli network ip interface set -e false -n vmk0
esxcli network ip interface set -e true -n vmk0

# Or restart the management agents
/etc/init.d/hostd restart
/etc/init.d/vpxa restart

This suggests the patching process does not always cleanly restart the management networking stack. If you are deploying patches via vSphere Lifecycle Manager, check each host's status immediately after it completes remediation rather than waiting for the whole baseline to finish. For VCF environments, the VCF PowerCLI guide covers lifecycle workflows that can catch these post-patch issues during orchestrated updates rather than discovering them the next morning when someone notices a host is greyed out in the inventory.