Setting up a three-node Proxmox cluster with quorum and live migration gives you the smallest reliable topology for true high availability in Proxmox VE. In this guide I walk you through the exact configuration I use in my own homelab and small production environments, from network planning and cluster creation to quorum tuning and a successful live migration test.
If you have ever lost a VM because a single hypervisor died, you already know why clustering matters. Three nodes is the sweet spot: enough redundancy to survive a failure, simple enough to manage without enterprise tooling.
Table of Contents
Prerequisites and Hardware Requirements
Before you install a single package, make sure every node meets the baseline. Proxmox clusters are unforgiving when hosts drift in versions or capabilities.
Hardware baseline for each of the three nodes:
64-bit CPU with hardware virtualization (Intel VT-x or AMD-V) and recommended IOMMU support
Minimum 16 GB RAM, ideally 32 GB or more for production VMs
Two NICs minimum: one for management and Corosync traffic, one for VM traffic and optionally migration
Local storage of at least 100 GB for the Proxmox installation and local VM disks
Reliable server-class ECC memory if you plan to enable HA fencing
Network topology and IP planning matter more than people expect. Pick a private subnet for Corosync traffic, ideally a separate VLAN or physical network. I use 10.10.10.0/24 for the cluster link and keep VM traffic on a separate VLAN. Document every IP before you start; you will thank yourself later when debugging.
Software versions should match across all three nodes. Run pveversion -v on each host and confirm the Proxmox VE version, kernel, and corosync package versions are identical. Mismatched versions are a top cause of split-brain and join failures.
Shared storage is required for true live migration without downtime. Your options include Ceph, NFS, iSCSI, or ZFS over iSCSI. Ceph is the most common because it ships with Proxmox and integrates cleanly. For homelab clusters, a single NFS share on a fourth box is often the fastest path.
Network Configuration for Cluster Communication
Cluster communication rides on Corosync, and Corosync is sensitive to latency and packet loss. Treat the cluster network like a SAN: dedicated, low-jitter, and watched.
The Corosync link should be on its own subnet with at least 1 Gbps. Avoid routing Corosync across WAN links or busy office networks. Multicast or unicast transport works, but I prefer unicast (UDPU) because it traverses routed networks cleanly and avoids IGMP issues on cheap switches.
A dedicated migration network is the single biggest performance win for live migration. Configure a separate NIC on each node, give it a private subnet like 10.20.20.0/24, and assign it as the migration network in the cluster configuration. This keeps memory pages from saturating your main LAN during a VM move.
VLAN and MTU tuning: if you tag your cluster or migration VLANs, set the MTU to 9000 (jumbo frames) on every switch port, NIC, and bridge in the path. Mismatched MTU is a silent killer that only shows up under load.
How to Create a Three-Node Proxmox Cluster Step by Step?
This is the part everyone wants: the actual commands. Run everything below as root, on each node, in order.
Step 1: Install Proxmox VE on all three nodes. Use the official ISO and configure static IPs on every node before continuing. Hostnames must resolve via /etc/hosts or DNS in both directions.
Step 2: Initialize the cluster on the first node. SSH into node1 and run:
pvecm create mycluster --link0 10.10.10.1
This command creates the cluster filesystem (pmxcfs), generates the Corosync configuration, and starts the cluster services. The --link0 flag binds Corosync to the dedicated cluster NIC.
Step 3: Join the second node. From node2, run:
pvecm add 10.10.10.1 -link0 10.10.10.2
You will be prompted for the root password of node1 and a cluster join password. Within seconds the second node should appear in the Datacenter tree of the web UI.
Step 4: Join the third node the same way. Use its own cluster IP as -link0:
pvecm add 10.10.10.1 -link0 10.10.10.3
Step 5: Verify cluster membership. Run on any node:
pvecm status
You should see three nodes, three votes, and an active quorum. If votes show only two, check that all nodes have joined and that firewall rules allow UDP 5404 and 5405 on the cluster subnet.
Quorum Configuration and How Voting Works
Quorum is the safety mechanism that prevents split-brain. In a three-node Proxmox cluster, every node holds one vote, and the cluster needs a majority (two of three) to make decisions. This is why three nodes is the minimum for clean HA without workarounds.
How voting works: Corosync exchanges heartbeat messages over the cluster link. If a node stops responding, the remaining nodes recalculate. With two of three nodes still talking, they hold quorum and continue running your VMs. The lost node gets fenced off by the HA manager to avoid duplicate VM instances.
Vote distribution across three nodes is simple out of the box: each node has one vote. You can see this with pvecm status or in /etc/pve/corosync.conf. The expected_votes value should equal the number of nodes that can possibly vote, which in a healthy three-node cluster is 3.
Corosync totem and transport settings live in /etc/pve/corosync.conf. The totem section controls consensus parameters like token timeout and consensus timeout. The transport can be udpu (unicast) or udp (multicast). I default to udpu for routed networks and udp for single-VLAN deployments.
If you want to add resilience without a fourth server, Proxmox supports a QDevice: a lightweight Corosync arbitrator that contributes an extra vote. It does not run VMs but it tips quorum in your favor when one node fails. Useful when you only have three physical servers but want extra safety.
Live Migration Setup, Testing, and Troubleshooting
Live migration moves a running VM from one node to another without dropping the network connection or pausing the guest for more than a few seconds. It depends on three things: shared storage, compatible CPU features, and a fast enough migration link.
Preparing shared storage for live migration: your VM disk must live on storage that all three nodes can read and write. NFS shares, Ceph RBD, iSCSI LUNs, and ZFS over iSCSI all work. Local-only storage will force offline migration because the disk cannot follow the VM.
Performing a test migration is non-negotiable. Pick a non-critical VM, right-click it in the UI, choose Migrate, and select another node. Watch the task log. A healthy migration shows steady memory copy progress and finishes in seconds for small VMs, or minutes for VMs with lots of dirty RAM.
You can also migrate from the command line:
qm migrate 100 node2 --online
Replace 100 with your VM ID and node2 with the destination.
Common migration errors and fixes:
“storage not available on target node” means the storage is local or not configured on the destination. Add the shared storage on every node.
“CPU type not compatible” requires enabling the same CPU type or using
x86-64-v2-AESas a baseline.Migration stalls near the end usually indicates a slow migration link. Move to a dedicated migration network.
“permission denied” on
/etc/pve/storage.cfgedits points to a sync issue; restartpvestatdon the target.
HA Group Configuration for Automatic Failover
Clustering without HA gives you centralized management and live migration. Enabling HA adds automatic failover: if a node dies, its VMs restart on a surviving node within seconds.
Enabling the HA Manager: on each node, make sure the pve-ha-manager service is running and the LRM (Local Resource Manager) is active. The Datacenter > HA panel in the web UI confirms everything is healthy.
Creating HA groups lets you prioritize which node should run which VM. From the UI: Datacenter > HA > Groups > Create. Give the group a name, list the nodes in priority order, and choose a restriction mode (normal, restricted, or failover).
Adding VMs as HA resources: select a VM, click Add, choose the HA group, and set the request state to “started.” The HA manager now watches the VM. If its host fails, HA Manager fences the node and restarts the VM on the next-priority host in the group.
Best practice: use restricted groups so a VM only runs on specific nodes. This avoids the situation where failover puts a license-bound VM on a host that lacks the right features.
2-Node vs 3-Node vs QDevice: Which Setup Fits You?
The choice between a 2-node, 3-node, or QDevice-augmented setup depends on how much hardware you have and how much downtime you can tolerate.
2-Node: Quorum needs a QDevice or tie-breaker. VMs stop without a third vote. Best for lab testing and non-critical workloads.
3-Node: Native majority (2 of 3). Automatic failover works out of the box. Best for small production and homelab HA.
3-Node + QDevice: Majority with an extra vote. Survives two-node loss better. Best for stretch clusters and remote sites.
If you only own two physical servers, a 3-node cluster plus QDevice is the cleanest path. The QDevice runs on a Raspberry Pi, a tiny VM on a third box, or even a small cloud VM, and contributes a vote that breaks ties.
Frequently Asked Questions
What is Proxmox High Availability?
Proxmox High Availability (HA) automatically restarts virtual machines on a healthy node when their original host fails. It uses the HA Manager together with Corosync quorum to detect failures and fence off dead nodes so no two nodes run the same VM at once.
How do I create a 3-node Proxmox cluster?
Install Proxmox VE on all three nodes with static IPs, then run pvecm create on the first node and pvecm add on the second and third nodes pointing at the first node’s cluster IP. Verify with pvecm status, which should show three nodes and three votes.
What are the requirements for Proxmox cluster quorum?
You need three or more nodes with reliable network connectivity between them, identical Proxmox versions, and UDP ports 5404 and 5405 open between the cluster IPs. For clean HA, three nodes is the minimum because majority requires two of three votes.
How does live migration work in Proxmox clusters?
Live migration copies a running VM’s memory and CPU state from one node to another while the VM keeps running. It requires shared storage that all nodes can access, compatible CPU flags, and a fast enough network link to keep the memory copy ahead of new writes.
What happens if a Proxmox cluster loses quorum?
If the surviving nodes cannot agree on a majority, the cluster stops management operations and may fence off nodes to protect data. VMs continue running on the nodes that still hold quorum, but you cannot start, migrate, or reconfigure them until quorum is restored.
Final Thoughts and Next Steps
Setting up a three-node Proxmox cluster with quorum and live migration is one of the highest-leverage projects you can tackle 2026. You get centralized management, automatic failover, and zero-downtime VM moves on commodity hardware.
Start with the prerequisites and network design, validate with a test migration before adding HA groups, and always keep an offline backup of /etc/pve/corosync.conf. Once your three-node Proxmox cluster is healthy, the rest of your virtualization stack becomes dramatically easier to operate.