VM Guest Tools Heartbeat Lost – Quick Fix Guide

Server & Cloud Intermediate 👁 13 views 📅 Jun 17, 2026

VM heartbeat lost means the host can't talk to the guest. Check guest tools, VMXNET3 driver, and resource contention.

Quick answer

Restart the VMware Tools service inside the guest, or reinstall them if that doesn't work. If the VM still shows heartbeat lost, check the VMXNET3 vmxnet3 driver for timeouts and verify the host isn't under memory pressure.

Why this happens

The heartbeat is a periodic signal VMware Tools sends from the guest to the ESXi host. If the host doesn't see it for a few seconds, vCenter flags it as lost. The culprit here is almost always one of three things: the VMware Tools service itself crashed or got stuck, the VMXNET3 network driver wedged due to a guest OS network stack issue, or the host ran out of resources (CPU ready time or memory ballooning) and delayed processing the heartbeat. I've seen this most often after a kernel panic in Linux guests or a Windows update that broke the Tools service.

Step-by-step fix

  1. Check VMware Tools status in vSphere – If it shows "Not Running" or "Unmanaged", you've got a tools issue. Right-click the VM, go to Guest OS, select "Restart Guest Tools". Wait 30 seconds and refresh.
  2. Login to the guest – On Windows, open Services.msc, find VMware Tools, verify it's not stuck in "Starting" or "Stopped". Restart it if needed. On Linux, run systemctl restart vmtoolsd or /etc/init.d/vmware-tools restart for older distros.
  3. Check the VM's vmware.log – SSH to the ESXi host or browse the datastore. Open /vmfs/volumes/datastore/vm-name/vmware.log and grep for heartbeat or tools. Look for lines like tools: heartbeat lost or tools: timeout waiting for heartbeat. If you see repeated timeouts, the guest is choking.
  4. Update or reinstall VMware Tools – Uninstall from the guest (Windows: Add/Remove Programs, Linux: vmware-uninstall-tools.pl). Mount the Tools ISO from vSphere, install fresh, reboot. Don't skip the reboot – you'll just chase ghosts.
  5. Fix the VMXNET3 driver – If the heartbeat drops after network activity spikes, the vmxnet3 driver might be timing out. On Linux, check dmesg | grep vmxnet3 for errors. Upgrade the driver from the open-vm-tools package. On Windows, update the driver from Device Manager – right-click the VMXNET3 adapter, Update Driver, browse to the VMware Tools driver folder.
  6. Check host resource pressure – High ESXi CPU ready time (>10%) or memory ballooning (>5% of guest memory) can delay heartbeats. Look at vCenter performance charts for the host. If you see it, migrate the VM to another host with DRS or vMotion.

Alternative fixes

  • Disable and re-enable the network adapter – In the guest, disable the VMXNET3 adapter in Network Connections (Windows) or ifconfig down/up (Linux). This forces the driver to reset. I've fixed a dozen heartbeats this way without a reboot.
  • Increase the heartbeat timeout – This is a band-aid, not a fix. Edit the VM's .vmx file and add tools.heartbeatTimeout = 20 (default is 10 seconds). Only do this if you can't resolve the root cause immediately.
  • Swap to e1000e driver – If VMXNET3 keeps failing, switch the VM's network adapter to e1000e (VMware's emulated Intel card). It's slower but rock-stable. Edit VM settings, change adapter type, reboot guest. You'll lose 30% throughput, but the heartbeat will stay alive.

Prevention tips

  • Always run the latest VMware Tools – Match the version to your vCenter release. Don't let them drift more than a minor version.
  • Set a vCenter alarm on heartbeat – Create an alert that fires if heartbeat is lost for 30 seconds. It'll catch the problem before users complain.
  • Monitor host resources proactively – Use vRealize or even built-in vCenter performance charts. If you see consistent CPU ready > 5%, you're overcommitting. Add hosts or reduce VM density.
  • Use paravirtualized SCSI adapters – PVSCSI reduces storage latency, which can indirectly affect heartbeat timing if storage stalls the guest OS.
One last thing: if you're running Windows Server 2019 or 2022 with Secure Boot enabled, make sure VMware Tools is signed with the EV certificate. An unsigned driver will fail to load after a Windows update, and you'll get a silent heartbeat loss. I've seen that bite five people this year.

Was this solution helpful?