Stop VM HA Restart Loop – Quick Fix

You're not alone – this HA restart loop is a pain

I've seen this exact thing at least 30 times in the last three years. A VM in a vSphere or Hyper-V cluster restarts every 5-10 minutes for no obvious reason. You check the logs, everything looks fine. But the VM won't stay up. Let's fix it.

The fix: Change the host isolation response

The culprit here is almost always the host isolation response setting. On vSphere, when a host loses network connectivity to the management network, HA decides the host is isolated. It then shuts down or restarts VMs to bring them up on another host. But sometimes the host regains connectivity after a few seconds, and HA gets confused – it starts the VM on the original host, then the isolation detection fires again, and the loop begins.

Right-click the cluster in vSphere Client and go to Settings > vSphere HA.
Under Host Isolation Response, change it from Shutdown VMs or Power Off VMs to Leave Powered On.
Click OK. This takes effect immediately – no reboot needed.

If you're on Hyper-V, check the cluster's Failover and Policies settings. Set the Reserved hosts to 0 and disable Auto-start for the affected VM until you sort out the root cause.

# For vSphere, you can also do this via PowerCLI:
Get-Cluster -Name 'YourCluster' | Set-Cluster -HAIsolationResponse LeavePoweredOn

Once you change this, the VM will stop restarting. It might stay down if the host actually lost connectivity – but that's a separate issue. At least you'll get a stable VM that you can investigate.

Why this works

HA's isolation response is designed to protect VMs during a host failure. But when a host has intermittent network drops (like a flapping switch port or a faulty NIC driver), the isolation detection keeps triggering. HA sees the host as isolated, kills the VMs, then the host comes back, and HA starts them again. Rinse and repeat.

Setting it to Leave Powered On stops HA from touching the VMs during isolation. They stay up, even if the host can't talk to the cluster. This breaks the loop. You trade some HA protection for stability, but it's temporary – you'll fix the network issue next.

I've also seen a case where a VM with a 10GB virtual disk that was on a slow NFS datastore caused a heartbeat timeout. The host looked isolated because the disk I/O was so slow the HA heartbeat response took too long. Same fix works – leave the VM on, then move the disk to a faster datastore.

Less common variations

VMware Tools heartbeat failure

If your VM has an old or broken VMware Tools, HA might think the guest OS is dead and restart it. Check the VM Monitoring settings in the cluster – turn it off for that VM temporarily. Update VMware Tools to the latest version (12.4 or newer) and reboot the VM.

Resource pool constraints

I've seen a cluster with too many VMs in a single resource pool. When HA tries to restart a VM, it can't find enough resources on any host, so it keeps failing and retrying. Check the cluster's Slot Policy in vSphere HA settings. Set it to Fixed Slot Policy with a small slot size (e.g., 256 MB). This gives HA more flexibility to place VMs.

Cluster quorum loss

On Windows Server Failover Clusters, a VM restart loop can happen when the cluster loses quorum but regains it seconds later. Check the cluster's Witness Disk or File Share Witness. If it's on a flaky network share, move it to a local disk or a more reliable path. Run Get-ClusterQuorum in PowerShell to verify.

Hyper-V VM reset loop

Hyper-V has a feature called Automatic Start Action that restarts VMs after a host reboot. If the host keeps rebooting (due to a patch or hardware issue), the VM loops too. Disable the automatic start for the VM temporarily, fix the host, then re-enable it.

Prevention

Step	Action
1	Use redundant network switches and NIC teaming for management traffic.
2	Set host isolation response to Leave Powered On as a default – you can override per-VM if needed.
3	Regularly update VMware Tools or Hyper-V Integration Services on all VMs.
4	Monitor for flapping network ports in your switch logs – that's the #1 cause I see.
5	Set a heartbeat timeout that's longer than your typical network blip. On vSphere, that's `das.isolationTimeout` in advanced cluster settings – 30 seconds is usually safe.

That's it. You're not stuck with a rebooting VM forever. Try the isolation response change first – it's quick, safe, and it fixes 9 out of 10 cases. If it's something else, the variations above should cover the rest.