How to build a Proxmox high availability homelab cluster
Learn how to plan and configure redundant physical nodes in Proxmox VE to ensure automatic failover and keep your home services online.
Summary
- High availability clusters require an odd number of physical nodes to prevent ties during quorum elections.
- The Corosync technology manages real-time communication and health status between cluster servers.
- The fencing system ensures a locked node is forcefully isolated to prevent shared data corruption.
- Shared storage via NFS or ZFS replication enables automatic migration of virtual machines.
- Testing simulated power outages on the bench validates resilience before putting the environment into production.
Why bring high availability inside your homelab?
When we start hosting our own services at home — such as media servers, home automation, and personal databases —, the impact of hardware failure stops being a mere annoyance and starts disrupting daily routines. In a traditional single-server setup, if the motherboard dies or the power supply fails, everything goes offline until the part is manually replaced. This exact problem is solved by High Availability (HA), which involves structuring infrastructure with multiple physical servers working together so that if one suffers a breakdown, systems automatically migrate to another healthy machine. In practice, this means your applications keep running without human intervention, even if an entire computer fails in the middle of the night.
To achieve this level of resilience without breaking the bank on enterprise servers, the tech community found a powerful, stable, and free tool in Proxmox VE. Proxmox is a virtualization platform built on Debian Linux that unifies the management of KVM-based virtual machines and LXC containers into a single web interface. By joining three or more of these nodes into a cluster, we create a distributed ecosystem where processing and memory resources become redundant. Just as we discussed when organizing robust architectures in decentralized software projects, eliminating single points of failure requires upfront planning of hardware, networking, and communication protocols.
The secret of quorum and hardware selection for the cluster
The first major myth we need to bust is the idea that we can build a high-availability cluster with just two computers. In theory, two nodes seem enough; in practice, they create a logical trap known as the split-brain dilemma. If the network cable connecting the two servers breaks, both believe the peer has died and attempt to take over the exact same virtual machines simultaneously, corrupting disks and databases within seconds. To prevent this disaster, consensus algorithms require an odd number of votes to make critical decisions. This is why a Proxmox cluster needs at least three physical nodes, or two nodes plus a small auxiliary device called a QDevice, which exists solely to break ties during voting if a failure occurs.
Regarding homelab hardware, we don't need loud, power-hungry rack servers. Compact mini PCs equipped with recent Intel Core processors, 32 GB of RAM, and gigabit or 2.5 Gbps network ports deliver spectacular performance with minimal electricity consumption. Additionally, it is crucial to ensure all nodes have access to a dedicated network or reliable switches for exchanging heartbeats, which are signals sent every second to confirm that servers remain alive and operational. If you want to optimize heavy processes and free up local resources in your lab, you can also check out tips on efficient hardware management and offloading applied to other infrastructure scenarios.
Configuring Corosync and the internal communication network
With physical nodes assembled and Proxmox installed on each of them, the next step is joining the servers via the main control panel. Under the hood, Proxmox uses a time-tested tool called Corosync, responsible for monitoring network integrity and instantly triggering the quorum mechanism. When you add a node to the cluster, Corosync creates an encrypted message ring where each machine reports its health status every millisecond. If a server stops responding for a few seconds, the others interpret that it has failed and start the automatic recovery process, preparing the ground for affected virtual machines to restart on surviving hardware.
To ensure this internal communication never suffers delays caused by user traffic or heavy downloads, it is highly recommended to isolate cluster traffic into a dedicated VLAN or use an exclusive network interface for Corosync. High latencies or packet loss in this layer can trick the system into thinking a server went down, causing unnecessary phantom migrations. After joining nodes in the web interface, you can verify service status directly in the terminal by running the cluster health check command:
pvecm statusThis command displays in detail which nodes are active, the current state of quorum voting, and whether the communication ring is perfectly synchronized, serving as the main thermometer for your home infrastructure's health.
Shared storage and the failover strategy
One of the most important pillars for automatic failover to work is how Proxmox handles virtual disks for your machines. If a server goes down, the neighboring server can only instantly power on the virtual machine if it has immediate access to the same disk files. In enterprise environments, this is solved with expensive SAN or NAS storages connected via Fibre Channel. In the homelab, we can use a centralized NAS server running TrueNAS or OpenMediaVault, exporting storage via NFS or iSCSI to all Proxmox nodes, or configure synchronous ZFS replication between the local disks of the nodes themselves.
When configuring high availability in the Proxmox panel, we define clear policies for each service, determining which virtual machines should automatically restart on another node and which can wait for manual intervention. It is important to remember that failover does not replace backup: an abrupt power outage corrupting the file system will still require restoring a recent safety copy. To maintain overall stability in your home server ecosystem, it pays to follow established practices for preventive maintenance and infrastructure organization, ensuring your environment remains clean and predictable over the months.
Conclusion
Building a Proxmox high-availability cluster in your homelab radically transforms the reliability of your home services, eliminating dependence on a single piece of physical equipment. Although the project requires a slightly higher initial hardware investment and a learning curve to master concepts like quorum and fencing, the reward is a resilient and automated environment.
By following best practices in network redundancy, traffic isolation, and proper storage, you gain the peace of mind knowing your infrastructure can heal itself in the face of unexpected hardware failures. Keep your backups updated, perform periodic simulated shutdown tests, and enjoy a truly professional homelab.