High availability in Proxmox means one thing in practice: when a node dies, the VMs that were running on it come back up on another node automatically, without you getting paged at 3 a.m. It’s not magic and it’s not instant, but once it’s set up correctly it turns a dead host from an emergency into a minor blip.
The catch is that HA only works when several other pieces are already in place — a real cluster, shared storage, and healthy quorum. People enable HA expecting it to be a single switch, then discover it does nothing because the foundation isn’t there. This guide explains what HA actually does, what it needs underneath it, and how the moving parts fit together, all aimed at someone setting it up for the first time on Proxmox VE 8.x.
If you don’t have a cluster yet, that comes first — start with creating a Proxmox cluster, because HA is built on top of clustering.
What HA does and doesn’t do
It’s worth being precise here, because the word “availability” gets stretched.
HA gives you automatic recovery. A monitored VM whose host fails is restarted on a surviving node. There’s a short outage while it reboots, typically a minute or two, but no human has to notice and act.
HA does not give you continuous uptime. The VM stops and starts; it doesn’t keep running across the failure. That’s a different feature.
HA vs live migration — they solve different problems
| High Availability | Reacts to unexpected failure. Restarts the VM on another node. Short downtime while it boots. |
|---|---|
| Live migration | Handles planned work. Moves a running VM between nodes with no downtime. You trigger it. |
You use both. Live migration empties a node before you reboot it for maintenance; HA catches the node that dies when you weren’t planning for it.
The foundation HA is built on
HA is the top layer of a stack. Each layer below it has to be working, or HA has nothing to stand on.
Requirements for Proxmox HA
- A cluster of at least 3 nodes (or 2 nodes plus a QDevice)
- Quorum that survives a single node failure
- Shared storage reachable from every node (Ceph, NFS, or iSCSI)
- A reliable, low-latency network for corosync
- A hardware or software watchdog for fencing (usually automatic)
The non-negotiable one is shared storage. HA restarts the VM somewhere else, and that somewhere has to be able to read the same disk. If your VM’s disk lives only on the failed node’s local drive, no other node can start it — there’s nothing to recover from. The disk has to sit on storage that every node reaches: Ceph, an NFS share, or a SAN over iSCSI.
Quorum: why HA cares so much about voting
Quorum is the rule that the cluster only acts when more than half its votes are present. HA leans on quorum heavily, because making recovery decisions without a majority is how you get two nodes both trying to run the same VM.
With three nodes, losing one leaves two votes — still a majority, so the cluster stays quorate and HA can act. With two equal nodes, losing one drops you to a single vote, below majority, and everything freezes. That’s why HA effectively needs three nodes, or two plus a QDevice for the third vote.
Fencing: making sure the dead node is really dead
This is the part beginners skip over, and it’s the reason HA is safe rather than dangerous.
Before a surviving node starts a VM that was running elsewhere, the cluster has to be certain the original node isn’t still running it. If both ran the same VM against the same shared disk, the disk would corrupt almost instantly. Fencing is the mechanism that guarantees the failed node is out of the picture.
Proxmox fences using a watchdog timer. Every node arms a watchdog that it has to keep resetting. A node that loses quorum — because it crashed, lost its network, or got isolated — can no longer reset the watchdog, so the watchdog reboots that node automatically after a set interval. Only after that fencing window passes does the HA manager consider it safe to recover the node’s VMs elsewhere.
This is why you’ll see a delay of a couple of minutes before HA recovers VMs: the cluster is waiting out the fence window to be sure the old node self-rebooted.
HA groups: controlling where VMs land
By default, HA can restart a recovered VM on any available node. Often that’s fine. But sometimes you want control — a VM that needs a GPU should only run on the node that has one, or you want a workload to prefer your beefier host. That’s what HA groups are for.
An HA group is a named set of nodes with optional priorities. You assign a VM to a group, and HA only places it on nodes in that group, preferring higher-priority ones.
HA group settings
| Nodes | The nodes this group is allowed to use. A VM in the group only runs on these. |
|---|---|
| Priority | A number per node. Higher wins. The VM prefers the highest-priority available node. |
| restricted | If set, the VM runs only on group nodes and stays stopped if none are available, rather than running anywhere. |
| nofailback | If set, the VM won't automatically move back to a higher-priority node when it returns, avoiding a second outage. |
The nofailback option is the one worth understanding early. Without it, when a failed preferred node comes back online, HA migrates the VM back to it — which means a second brief outage right after you’ve recovered. For many workloads it’s better to leave the VM where it is once it’s running happily, and set nofailback so it doesn’t bounce back automatically.
Setting up HA in the web interface
With a cluster, shared storage, and quorum in place, turning on HA for a VM is quick.
- Make sure the VM’s disk is on shared storage. Migrate it there first if it isn’t.
- (Optional) Create an HA group under Datacenter → HA → Groups if you want to control placement.
- Go to Datacenter → HA, click Add under Resources, and pick the VM.
- Set the Request State to
started, optionally assign your group, and save.
From the command line, the same thing:
# protect VM 101 with HA, desired state started, max 3 restart attempts
ha-manager add vm:101 --state started --max_restart 3
# check what HA is managing and the current state of each resource
ha-manager statusha-manager status is the command you’ll come back to. It shows each managed resource, which node it’s on, and its current HA state. After you add a VM, you should see it listed as started on its current node.
Understanding HA resource states
When you watch ha-manager status, you’ll see resources move through states. Knowing what they mean saves a lot of confusion during a real event.
Common HA resource states
| started | The desired and normal state — the VM should be running, and HA keeps it that way. |
|---|---|
| stopped | HA is told to keep it off. It won't be started automatically. |
| fence | The node hosting it is being fenced. HA is waiting for the failed node to self-reboot before recovering. |
| recovery | HA is moving the resource to a healthy node after fencing completed. |
| error | Something went wrong (often a failed start). Needs manual attention; clear it once fixed. |
An error state doesn’t clear itself. If a VM lands there — say it failed to start because its storage was briefly unavailable — you fix the underlying issue and then tell HA to retry, usually by disabling and re-enabling the resource or setting its state back to started.
Where to go from here
Proxmox HA is the payoff for building the cluster properly: shared storage, odd-numbered quorum, and a clean network. Get those right and HA quietly does its job, restarting VMs on a healthy node when hardware fails while you’re asleep. Get them wrong and HA either does nothing or, worse, can’t fence safely.
The natural next steps are the layers underneath. If your cluster isn’t built or you’re fuzzy on quorum, read creating a Proxmox cluster. For the shared storage HA depends on, the local-vs-shared trade-offs are in Proxmox LVM vs LVM-Thin vs ZFS, and an NFS target is covered in adding NFS storage to Proxmox. For more walkthroughs, browse the Proxmox guides.
