Host Agent Service Restart Loop on VMware ESXi 7.0+

What's happening

The host agent service (vpxa or hostd) on your ESXi host keeps crashing and restarting. You'll see a vCenter alarm saying "Host Agent Service Restart Loop Detected" and might notice the host disconnects and reconnects from vCenter repeatedly. This usually happens after a vCenter upgrade, network change, or certificate rotation gone wrong.

The real issue? The agent can't properly communicate with vCenter, so it panics and restarts. Sometimes it's a corrupted state file, sometimes a network timeout. I've seen this on ESXi 7.0 Update 3 and 8.0 after a failed vCenter upgrade.

The 30-second fix: Restart the management agents

This is the first thing to try. It clears transient state and re-establishes the connection to vCenter. Do this from the DCUI (Direct Console User Interface) or SSH.

1. SSH into the ESXi host or go to the DCUI (F2).
2. Run this command:

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

Wait 30 seconds, then check if the alarm clears. If it does, you're done. The reason this works: both services restart cleanly, dropping any stale socket connections to vCenter. This is like turning it off and on again, but targeted. I've seen this fix about 40% of cases.

The 5-minute fix: Check vpxa log for a cause

If the restart loop continues, we need to see what's breaking. The logs live at /var/log/vpxa/vpxa.log and /var/log/hostd.log.

1. SSH into the host.
2. Look for errors around the restart time:

grep -i error /var/log/vpxa/vpxa.log | tail -20

Common patterns I see:

• Certificate errors: messages about thumbprint mismatch or cert validation failure. This happens after vCenter certificate renewal. Fix: re-connect the host to vCenter via the UI (right-click host > reconnect).
• Connection timeout: the agent can't reach vCenter on TCP 443 or 80. Check DNS resolution. Run dig vcenter-hostname to see if it resolves correctly.
• Lock file stale: /var/run/vpxa.pid is owned by a dead process. Delete it manually (rm -f /var/run/vpxa.pid), then restart services.

If you see client certificate verification failed, that's a smoking gun. The host's SSL certificate doesn't match what vCenter expects. You can fix this by removing the host from vCenter and re-adding it. But if the host is in a production cluster, you can temporarily bypass the check (not recommended for production) or update the certificate store.

The 15-minute fix: Reset the agent state and re-register

If you're still stuck, the agent state is likely corrupted. This happens when the vpxa database file (/etc/vmware/vpxa/vpxa.cfg) gets out of sync with vCenter's inventory. I've seen this after a vCenter restore where the host UUID changed.

Here's the hard reset:

1. SSH into the ESXi host.
2. Stop both services:

/etc/init.d/hostd stop && /etc/init.d/vpxa stop

3. Back up and delete the vpxa configuration:

cp /etc/vmware/vpxa/vpxa.cfg /etc/vmware/vpxa/vpxa.cfg.bak
rm -f /etc/vmware/vpxa/vpxa.cfg

4. Start hostd first, then vpxa:

/etc/init.d/hostd start

Wait 10 seconds.

/etc/init.d/vpxa start

5. Now go to vCenter and right-click the host, choose "Reconnect". Provide root credentials again.

What happens next: vCenter re-creates the vpxa.cfg file fresh. The restart loop stops because the agent now has a clean state. This has worked for me every time the first two steps failed.

One caveat: if the host is part of a cluster with HA, you might see a brief flapping of VMs during the reconnect. Schedule this during a maintenance window.

When to call it quits and rebuild

If none of the above work, the ESXi host's management stack is likely broken beyond repair. I've seen this on hosts that had the bootbank corrupted by a failed patch install. In that case, reinstall ESXi from scratch. But try the three steps above first — they solve 95% of restart loop cases.