How to set up automatic failover and HA in Proxmox
Learn how to build a Proxmox cluster with high availability to ensure seamless virtual machine and container migration during hardware failures.
Summary
- Proxmox clusters rely on Corosync to monitor node health in real time
- The PVE-HA subsystem automatically migrates workloads when a physical server crashes
- Quorum requires a majority of active nodes to prevent split-brain scenarios
- Fencing with STONITH ensures unresponsive nodes are powered off before migration
- Shared storage via Ceph or NFS enables continuous access to virtual disks
What is high availability and how Proxmox protects your data
When managing virtualization servers, the ultimate nightmare is a sudden hardware failure. A burning processor or a motherboard shutting down out of nowhere can take down dozens of critical systems in seconds. In practice, high availability (or HA) acts as an automatic rescue mechanism, detecting physical drops and restarting affected machines on another server in the pool. In Proxmox, this operational magic combines cutting-edge virtualization with well-established open cluster tools, as we explore in our guide on how to sync Proxmox nodes under high network latency to maintain operational integrity even under network stress.
Understanding cluster architecture and the importance of quorum
For a failover environment to run without human intervention, we need at least three physical servers working together, forming a cluster. The core of this communication is Corosync, a real-time messaging service that sends continuous heartbeat signals between nodes to check who is alive. This ecosystem also ensures internal traffic security, preventing routing issues from compromising the infrastructure, much like the care we take when isolating container network failures with iptables to shield production environments. Without this constant exchange of signals, the system wouldn't know when a network peer suffered an electrical failure or merely lost connection temporarily.
Preventing split-brain scenarios with node fencing or STONITH
One of the greatest dangers in distributed systems is the split-brain scenario, where the cluster splits into two isolated halves, each believing it is the sole master authority. To prevent two servers from attempting to write to the same virtual disks simultaneously and corrupting everything, Proxmox uses fencing. The technical term STONITH, which stands for Shoot The Other Node In The Head, represents physical or logical power devices that forcibly shut down the frozen machine before releasing its migration. In practice, the system prefers to isolate and shut down a suspicious server drastically rather than allow corrupted data to destroy your customer base.
Configuring shared storage for lossless migration
It is useless to transfer a virtual machine to a new server if it cannot see the same disk files it used before. That is why automatic failover requires a shared storage layer, such as Ceph clusters, NFS storages, or dedicated block-based SANs. When a failure occurs on the original host, the new server takes over the virtual machine by mounting the exact same disk volumes instantly. To ensure that this storage and physical resilience infrastructure supports power spikes without catastrophic drops, many administrators adopt electrical redundancies inspired by principles of how to design N+1 power redundancy in blade servers, ensuring end-to-end stability.
Step-by-step guide to enabling HA in the Proxmox panel
After building the cluster with three nodes and configuring shared storage, enabling automated failover requires only a few adjustments in the web interface or via terminal. The following process demonstrates the basic commands for managing high availability resources using the official Proxmox command-line tool.
- Check the current cluster status and confirm that all nodes are visible by running the check command in the terminal:
pvecm status - Add the desired virtual machine or container to the high availability management group by defining the default state:
ha-manager add vm:100 -state started - Confirm that the resource has been successfully integrated into Proxmox's continuous HA monitoring table:
ha-manager status
Monitoring and testing failover in practice
Configuring the tool is only half the job; validating resilience in a controlled environment is what separates a reliable system from an empty promise. Perform simulated tests by unplugging one of the physical nodes in the cluster while running workloads on guest virtual machines. The ecosystem should identify the lack of response in a few seconds, isolate the compromised node, release the disk resources, and restart the services on the adjacent healthy server. This automated process cuts downtime from hours to just a few minutes, shielding your operation against hardware unforeseen events.
Final considerations on resilience and preventive maintenance
Implementing high availability with Proxmox transforms a fragile infrastructure into a robust environment capable of absorbing physical failures without operational panic. Although automatic failover resolves unexpected incidents, it does not replace the need for rigorous external backup routines and proactive monitoring of temperature and disk wear. Keeping firmware updated and regularly testing fencing triggers ensures your cluster reacts exactly as planned when the worst happens in your server room.