A Proxmox HA cluster can restart guests on another node when a host fails—but only if quorum, storage, and recovery dependencies line up. Joining a cluster enables centralized management and live migration, yet adding a guest to the HA resource configuration is a separate step. This guide connects the decisions that determine whether your small cluster can recover from a host failure and what downtime to expect.
Decide which guests need HA management
Cluster membership alone does not put a VM or container under HA management. You must add each guest to the HA resource configuration, either through the Datacenter → HA panel in the web interface or by running:
ha-manager add vm:100(or ct:100 for a container). Once added, ha-manager observes the guest and will restart it on another node if the host fails. Guests not in the HA configuration remain outside automatic recovery.
Check quorum before counting on failover
Proxmox VE uses a quorum-based technique to maintain a consistent cluster state. Quorum is the minimum number of votes required to authorize state changes—by default, one vote per node. In a network partition, the cluster switches to read-only mode if it loses quorum, and the HA manager cannot restart guests or relocate resources.
The Proxmox documentation states that you need at least three cluster nodes to get reliable quorum. With three nodes, the cluster can lose one and still hold two votes, preserving quorum. A two-node cluster loses quorum the moment one node fails, leaving the survivor unable to make HA decisions. Before you deploy HA, count the nodes and check whether the surviving partition will have more than half the total votes after a single failure.
Verify each guest's recovery dependencies
An HA resource can only run on nodes where all of its dependencies are available. The HA manager treats every cluster node as eligible by default, so a recovering guest must find its storage, network interfaces, and any device passthroughs on the target node. If the guest's disk lives on local storage that only the failed host can see, no other node can start it.
The baseline HA requirements call for shared storage accessible from all nodes—NFS, iSCSI, Ceph RBD, or another distributed backend. When every node can read and write the guest's disk image, the HA manager can pick any surviving node for recovery. Network dependencies also matter. If a guest is bound to a bridge or VLAN that exists only on the original host, the recovery will fail or leave the guest unreachable. Check that the new node has the same bridge names and network configuration, or restrict the HA resource to the subset of nodes that do by setting a node affinity rule.
Account for the replication data loss window
If you must use local storage, configure storage replication to a second node. The Proxmox storage replication documentation lists ZFS (local) as the supported storage type. Replication copies guest volumes at regular intervals—every minute to once a week—using snapshots to send only the changes since the last sync. When a host fails, the most recent replica is already on the target node, and recovery can proceed without copying the entire disk over the wire.
The HA documentation warns that when HA is combined with storage replication, there may be data loss between the last synced time and the time the node failed. If the replication interval is five minutes and the host crashes three minutes after the last snapshot, those three minutes of writes are gone. If a replication job encounters problems, it is placed in an error state and the configured intervals are suspended, so the possible loss extends back to the last successful sync. The guest restarts from the last consistent replica, and any changes made afterward do not appear.
Keep replication intervals short, ensure the target node has a storage configured with the same storage ID, and verify that the replication job is succeeding. HA with replication trades an asynchronous data-loss window for the ability to run on local storage. Using shared storage removes that replication gap, though the supplied sources do not guarantee continued access after a storage failure itself.
Expect an interruption during host recovery
When a node leaves the cluster quorum, its state changes to unknown. The cluster resource manager (CRM) on the remaining nodes attempts to secure the failed node's lock. If it succeeds, the CRM marks the node as fenced and places affected HA services into the recovery state. The HA manager then searches for a new node where each service can run, based on the list of online and quorate nodes and any affinity rules.
Once a suitable node is found, the guest is moved there and initially placed into the stopped state. If the guest's HA configuration requests the started state, the new node starts it. The Proxmox documentation states that ha-manager has typical error detection and failover times of about 2 minutes, and notes that this yields no more than 99.999% availability. That figure is typical, not guaranteed—the actual recovery time depends on how quickly the cluster detects the failure, how long fencing takes, and how fast the new node can read the guest's disk and boot the operating system.
During that period, the guest is unavailable. Applications sensitive to brief interruptions may time out or require manual reconnection. The HA manager will restart the guest automatically, but it does not resume in-memory state or preserve active network connections.
Keep a separate backup plan
HA restarts guests after a host failure; it does not protect against data corruption, accidental deletion, ransomware, or storage failures that affect all replicas. Proxmox VE provides a fully integrated backup solution using vzdump, and you can configure backup jobs to run on a schedule and store snapshots on a Proxmox Backup Server or file-level storage such as NFS. Schedule regular backups, verify that restores work, and keep backup storage separate from the cluster's production storage.
Check your cluster before a failure
Before you rely on HA, verify the configuration on a surviving node. Run:
pvecm statusto confirm quorum. Run:
ha-manager statusto list HA services and their state. If you use replication, run:
pvesr statusto confirm the last sync succeeded. Check that each HA guest's storage, network bridges, and device passthroughs exist on the nodes where recovery is expected. The supplied sources do not document a reproducible physical host-failure test or specific observed recovery times.
FAQ
Is a Proxmox cluster automatically highly available?
No. Cluster membership enables centralized management and live migration, but you must explicitly add each VM or container to the HA resource configuration for automatic restart after a host failure.
How many nodes does my HA design need?
With three nodes, the cluster can lose one and still authorize HA operations. A two-node cluster loses quorum when one node fails.
What storage must remain available after a host fails?
The recovering node must have access to the guest's disk image, network interfaces, and any device passthroughs. Shared storage (NFS, iSCSI, Ceph RBD) accessible from all nodes meets this requirement. If you use local ZFS storage, configure storage replication to a second node and accept the data-loss window between the last successful sync and the failure.
What will HA restart, and what downtime remains?
HA restarts the guest on another node after fencing the failed host. The documentation states typical error detection and failover times of about 2 minutes. During that period, the guest is unavailable, and active network connections and in-memory state are lost. The actual recovery time depends on failure detection, fencing, and how fast the new node can read the disk and boot the guest.
Verification status: Supported by official documentation only under the conditions below; not reproduced in a test environment by IGPROD. Checked 2026-10-25.
Conditions:
- The HA guide specifies at least three cluster nodes for reliable quorum.
- The remaining cluster partition needs quorum to make state changes.
- A recovery node must have access to the guest’s storage, network interfaces, and other configured dependencies.
- If HA uses storage replication, data written after the last sync may be lost.
Sources:
Leave a comment
Your email address will not be published. Required fields are marked *
