Proxmox HA Cluster in 2026: Requirements, Storage, and Failover

A Proxmox HA cluster automatically restarts selected VMs and containers on another node after a host failure. In Proxmox VE 9.2, HA can also use dynamic load information to improve guest placement, but the core requirements have not disappeared: reliable quorum, storage available on surviving nodes, predictable Corosync communication, spare capacity, and tested fencing behavior.

The simplest reliable design uses three nodes. Two-node HA is possible with an external QDevice, while guest storage can come from shared storage, Ceph, or supported ZFS replication with an accepted recovery-point gap. None of these designs removes the need for backups.

This guide focuses on the architecture and the decision: what a Proxmox HA cluster requires, which topology fits, when HA is worth deploying, and what to test before relying on automatic failover.

Proxmox HA cluster requirements

Requirement	What it means in practice
Cluster quorum	Prefer three nodes; two nodes need an external QDevice for higher availability.
Reliable Corosync network	Latency below 5ms between all nodes; independent links are strongly recommended for important HA deployments.
Guest storage available after node failure	Shared storage, Ceph, or supported ZFS storage replication with an accepted non-zero RPO.
Compatible nodes	CPU model, network bridges, storage IDs, device mappings, and guest dependencies must exist on every eligible target.
Spare capacity	Surviving nodes need enough CPU, memory, storage IO, and network capacity to restart failed workloads.
Watchdog and fencing	Verify the watchdog path and test failure behavior before relying on HA.
Backups	HA does not replace PBS or tested restore procedures.
Maintenance plan	Use node maintenance and Proxmox VE 9.2 HA Arm/Disarm correctly.

Every row is a hard dependency of a working Proxmox HA cluster. A Proxmox HA cluster that satisfies seven of eight is not 87% highly available; it fails at the missing one, usually at the worst possible moment.

What HA protects, and what it does not

Proxmox HA uses the Cluster Resource Manager, Local Resource Managers, quorum, and a watchdog-based fencing path to ensure a guest is not started on a second node before the failed owner is considered safely isolated. See how Proxmox HA and fencing work for the detailed failure sequence, service states, and recovery timeline.

Proxmox uses the watchdog interface for self-fencing. If no hardware watchdog is configured, it falls back to the Linux kernel softdog. Softdog is practical and widely used, but it is not independent of the host kernel and hardware in the same way as a correctly configured hardware watchdog.

What HA does not do:

• It does not protect against application-level failure inside a guest. If a database corrupts itself, HA restarts the corruption on another node.
• It does not eliminate downtime. Proxmox documents typical HA error detection and failover at about two minutes. Application availability can take longer because the guest still has to boot, services must start, and dependent systems may need to reconnect.
• It does not protect against storage failure. If shared storage becomes unavailable, HA resources cannot restart successfully anywhere.
• It does not replace backups. HA protects uptime; backups protect data. HA does nothing for accidental deletion, ransomware encryption, guest filesystem corruption, or a mistaken rm -rf on shared storage. Any production setup needs both, so pair HA with a Proxmox backup and restore plan.

The mental model worth keeping: a Proxmox HA cluster is a node-failure response system, not an uptime button.

2-node vs 3-node Proxmox HA cluster

Quorum design: use three cluster nodes for the simplest reliable HA architecture. A two-node cluster can use an external QDevice, but it adds another dependency and does not provide the same compute capacity or failure behavior as three full nodes.

A QDevice runs on an external qnetd host and contributes a vote; it does not run cluster workloads. Place it outside the failure domain that is most likely to take both cluster nodes down together. A small local Linux system is usually easier to reason about than a WAN-dependent VPS, because loss of the WAN path introduces another quorum dependency.

Odd node counts often provide better failure tolerance per voting node, but even-sized clusters are fully valid. A four-node cluster should not be reduced to three simply for voting symmetry if the fourth node provides needed capacity. Evaluate quorum, failure domains, maintenance capacity, and whether a QDevice improves the intended partition behavior.

Vote math, expected-votes configuration, pvecm status interpretation, no-quorum errors, and QDevice setup are covered in the Proxmox quorum and QDevice design guide. For the design decision here, the short version is: three nodes preferred, two nodes plus QDevice possible, and a partition that cannot prove majority will refuse to act.

Choose the storage architecture

A Proxmox HA cluster requires the guest disks to be available on a surviving node. Shared storage provides that directly. Proxmox storage replication provides another supported design for eligible local ZFS volumes, but recovery can lose changes made after the last successful replication cycle.

Storage design	Failover behavior	Main trade-off
NFS/iSCSI shared storage	Guest can restart from the same disks	Storage system can remain a major shared failure domain
Ceph	Distributed storage across cluster nodes	Requires enough nodes, disks, network capacity, and recovery planning
ZFS replication	Starts from latest replicated local volume	Non-zero RPO; recent writes may be lost
Local non-replicated storage	HA cannot restart the guest elsewhere	Manual restore or migration required

The failure that catches operators is the last row. Local non-replicated storage does not cause data loss by itself; it means the guest cannot automatically restart elsewhere because its disks are unavailable. HA looks configured, the GUI shows green, and nothing recovers.

Note that shared storage does not remove the failure domain, it relocates it. A single NAS behind a three-node cluster is still one box whose loss takes down every HA-managed guest at once. Compare the options in shared storage for Proxmox HA, and see choose Proxmox storage for HA for the backend trade-offs.

Corosync network requirements for a Proxmox HA cluster

Corosync needs a reliable LAN path with latency below 5ms between nodes. A dedicated or physically independent path is strongly recommended for HA and production workloads, especially when storage, migration, or backup traffic can congest the main network. A lightly loaded shared network can function, but it must be tested under the actual peak traffic conditions.

The Proxmox Cluster Manager documentation specifies UDP ports 5405-5412, time synchronization across all nodes, and multiple links for redundancy. Bandwidth is rarely the constraint. Predictable latency is.

Prefer native Corosync multi-link redundancy across independent paths when you need Corosync-specific failover visibility. A bond can still carry Corosync traffic, but its mode, carrier detection, switch topology, and failure behavior must be validated. A bond is not a substitute for independent Corosync failure domains.

• Corosync multi-link: preferred for independent path redundancy.
• Active-backup bond: possible, but understand the detection caveats.
• LACP bond: capacity and redundancy depend on the upstream switch domain.
• Two VLANs on one NIC: logical separation, not physical redundancy.

The wider point for any Proxmox HA cluster is that redundant links fail together whenever they share a hidden dependency: same subnet, same switch, same NIC, same power feed. Design the Corosync paths and validate them under load through the design the Corosync and cluster network guide.

Capacity and hardware compatibility

Quorum is not capacity. A three-node cluster can remain quorate after one node fails and still be unable to restart every guest if the remaining nodes do not have enough memory, CPU, storage throughput, or required hardware mappings. Size the cluster for the failure state, not only for normal operation.

This is the Proxmox HA cluster requirement most often skipped, because normal operation never reveals it. A cluster running at 75% memory across three nodes has no room to absorb a third of its workload onto two surviving nodes. HA will try, placement will fail, and the guests stay stopped. Use the size surviving nodes for N+1 capacity guide when planning the headroom.

Compatibility matters just as much as capacity. Every eligible failover target needs the same network bridge names, the same storage IDs, a compatible CPU model, and any device mappings the guest depends on. Mixed-hardware clusters fail here: a VM with GPU passthrough or a hardware-bound licence has exactly one node it can run on, which means HA has nowhere to put it.

HA placement rules in Proxmox VE 9.2

Older Proxmox guides describe HA Groups. Since Proxmox VE 9.0, HA Groups are deprecated and migrated to HA Node Affinity rules. Node Affinity controls which nodes an HA resource prefers or is allowed to use, while Resource Affinity and Anti-Affinity rules control whether selected HA resources should run together or remain separated.

• Node Affinity: restrict or prefer eligible nodes for a guest.
• Positive Resource Affinity: keep related resources together where appropriate.
• Negative Resource Affinity: separate redundant services across nodes.
• Dynamic Load Balancing: rebalance HA-managed guests while respecting these rules.

Use explicit rules for hardware-bound workloads, licensing constraints, failure-domain separation, and services that must not land on the same node. Two DNS servers that both fail over onto the same host are not redundant DNS.

HA now also influences active workload placement. Proxmox VE 9.2 can dynamically rebalance HA-managed guests using current CPU and memory usage. This does not replace capacity planning, but it means Proxmox HA cluster design now includes both failure placement and optional ongoing rebalancing behavior.

Planned maintenance in Proxmox VE 9.2

Use node maintenance mode when servicing one node and you want HA resources moved or handled through the normal HA workflow.

For cluster-wide maintenance, Proxmox VE 9.2 adds HA Arm/Disarm. The freeze mode preserves current resource placement while the HA stack is disarmed; ignore changes how resources are treated during the maintenance window. Consult the official HA documentation for the exact choice between them, because the behavior differs in ways that matter during a live maintenance window.

Re-arm HA only after cluster communication, storage, and node state have been verified. This workflow is what makes switch firmware upgrades, VLAN migrations, and NIC driver changes survivable on an HA cluster. Without it, planned network work on a live HA cluster is how operators discover fencing behavior for the first time.

Test the HA design before production

• Move one HA guest into maintenance and back.
• Test planned node shutdown using node maintenance mode.
• Test loss of one Corosync link while the second link remains active.
• Test a full node failure during controlled conditions.
• Confirm the failed guest starts only once on an eligible target.
• Measure detection, restart, guest boot, and application recovery separately.
• Confirm surviving nodes remain within CPU, memory, and storage limits.
• Test storage failure separately from compute-node failure.
• Verify backups and perform an isolated restore test.
• Document how to disarm and re-arm HA during cluster-wide maintenance.

Test with backups verified and a maintenance plan in place, not by pulling a power cable to see what happens. The evidence for what actually occurred lives in the cluster logs, so review Corosync and HA logs after each test rather than judging by whether the guest came back.

What can still go wrong

Risk	Possible result
Loss of every Corosync path	Quorum loss; HA recovery or fencing depending on partition state
Congested shared network	Increased latency and jitter, membership instability
Misconfigured redundant links	Both links may fail through the same physical or routing dependency
Storage unavailable	HA resources cannot restart successfully
Insufficient target capacity	Resources remain stopped or placement fails
Untested watchdog or maintenance workflow	Unexpected node resets or delayed recovery

These are possible outcomes, not guarantees. The common thread is that Proxmox HA cluster failures are rarely about the HA stack itself. They trace back to cluster network design, capacity assumptions, and procedures that were never rehearsed.

When a Proxmox HA cluster is not worth it

HA is not the right answer for several setups that get sold on it:

• Workloads that tolerate a 15 to 30 minute restore. PBS restore is simpler and reaches the same business outcome.
• Single-node homelabs. Adding nodes purely to enable HA spends real budget for theatrical reliability.
• Mixed-hardware experiments. Different CPU generations, storage backends, or device mappings leave HA with no valid failover target.
• Storage that is not actually available cluster-wide. Without shared storage or replication, HA cannot restart the guest anywhere.
• Clusters with no spare capacity. Quorate and unable to place workloads is a worse position than a clean single-node restore.
• Operators who will not test failure. Untested HA fails when you need it, predictably.

The honest rule of thumb: a Proxmox HA cluster earns its complexity when mean time to manual recovery is meaningfully higher than the roughly two minutes of documented detection and failover, and the hardware, network, and storage design actually supports the requirements. Otherwise, cold standby plus tested restore produces better real-world availability.

Final decision matrix

Architecture	Best fit	Main risk
3 nodes + external NFS/iSCSI	Small SMB with existing resilient storage	Shared storage remains a central failure domain
3+ nodes + Ceph	Hyperconverged cluster	Higher hardware, network, and operational requirements
2 nodes + QDevice + shared storage	Limited compute footprint	Less spare capacity and additional quorum dependency
2-3 nodes + ZFS replication	Local storage with accepted RPO	Recent writes can be lost after sudden node failure
Single node + PBS restore	Most homelabs and non-critical workloads	Manual recovery and longer downtime

Final verdict

A Proxmox HA cluster is a legitimate, well-engineered system that solves a real problem: automatic recovery from node failure with bounded downtime. Proxmox VE 9.2 makes it stronger, with Node Affinity rules replacing deprecated HA Groups, dynamic rebalancing of HA-managed guests, and a cluster-wide Arm/Disarm workflow that finally makes planned maintenance a first-class operation.

It is still an architectural commitment rather than a checkbox. Three nodes, storage that survives a node loss, Corosync paths that are independent in the routing table and not just on the diagram, capacity sized for the failure state, and a tested failure drill. Miss one and the cluster manufactures outages the single-node setup never had.

The questions worth answering honestly: is manual recovery meaningfully slower than automatic failover for these specific workloads, does the storage design support restarting a guest elsewhere, and will the failure modes actually get tested? If yes, a Proxmox HA cluster earns its complexity. If no, cold standby with tested restore produces better availability than a partial HA deployment. Sometimes the right outcome of understanding HA is “not yet.”

FAQ

How many nodes does a Proxmox HA cluster need?

Three is the simplest reliable design. A two-node cluster can run HA with an external QDevice providing a tie-breaking vote, but it carries less compute redundancy and one more quorum dependency. Two nodes with no QDevice cannot maintain quorum through a split, so neither side will act.

Does Proxmox HA require shared storage?

HA requires the guest disks to be reachable on a surviving node. Shared storage such as NFS, iSCSI, or Ceph provides that directly. Supported ZFS storage replication is the other valid path. Local non-replicated storage means HA cannot restart the guest elsewhere at all.

Can Proxmox HA use ZFS replication?

Yes, for eligible local ZFS volumes, and it is a documented supported design. The trade-off is a non-zero RPO: failover starts the guest from the last successful replication cycle, so changes written after that point are lost. Match the replication interval to what the workload actually tolerates.

How much downtime does a Proxmox HA cluster have?

Proxmox documents typical error detection and failover at about two minutes. Application availability takes longer, because the guest still has to boot, services must start, and dependent systems may need to reconnect. Storage latency, concurrent resource count, and target node capacity all extend it. HA delivers fast bounded downtime, never zero.

Does Corosync require a dedicated NIC?

Not as an absolute software requirement, but a dedicated or independent path is the safer HA design. The hard requirement is a reliable network with latency below 5ms. If Corosync shares links with storage, migration, or backup traffic, validate latency and packet loss under peak load rather than only when the cluster is idle.

Is a four-node Proxmox cluster a bad design?

No. With default votes, a four-node cluster normally requires three votes and tolerates one node loss, the same node-loss count as a three-node cluster. The fourth node can still add useful compute and storage capacity. Use a QDevice only after evaluating the exact failure and partition behavior you need; do not remove a working node solely to make the cluster odd-sized.

How do I pause HA for maintenance in Proxmox VE 9.2?

For a single node, use ha-manager crm-command node-maintenance enable NODE. For cluster-wide windows, Proxmox VE 9.2 adds ha-manager crm-command disarm-ha freeze to disarm the HA stack while preserving placement, and ha-manager crm-command arm-ha to re-enable it. Verify cluster communication, storage, and node state with ha-manager status before re-arming.

Last updated: July 2026 – verified against Proxmox VE 9.2.