A Proxmox cluster lets you manage every Proxmox VE node from one web interface, move VMs and containers between them, and turn on high availability so a guest restarts on another node when its host goes down. This Proxmox cluster setup guide creates the cluster, joins the other nodes, migrates a VM and adds HA, and you don’t need any firewall rules by hand to do it.
The steps are checked against the Proxmox VE 9.2 documentation (October 2026). The screenshots are from an older release, but the buttons are where they were, and where something has changed, the text says so.
What Is a Proxmox Cluster?
A PVE cluster is a group of Proxmox VE nodes that share one configuration. Proxmox clustering is built on Corosync, which the cluster file system uses to replicate /etc/pve to every node in real time. That’s why you can log in to any node, manage all of them, and migrate guests between hosts.
Each node gets one vote, and the cluster needs a majority of votes (quorum) to make changes. A node that cannot see a majority switches to read-only, which stops two halves of a split cluster from both starting the same VM. For HA, you don’t need three Proxmox nodes, but you do need three nodes voting.
On two nodes, a QDevice provides that third vote without running Proxmox, and running a QDevice on a two-node cluster has its own guide, so the HA steps here assume three or more nodes.
Do You Need a Proxmox Cluster?
Truthfully, a lot of home labs don’t. By June 2026, I’d replaced a two-node cluster with a single mini-ITX server, and when I audited what mattered, only around six important VMs and three important LXCs really needed to stay. The move took roughly 2 hours to install Proxmox, move everything, recreate network interfaces, and validate, so I’d expect recovering from a failure to take about the same.
The trade-off is that one server is a single point of failure: if it’s down, everything is down. Backups don’t replace redundancy, but for my use case, they should be good enough. You should choose a two- or three-node cluster if uptime matters more than simplicity, you want maintenance flexibility or live migration, or other people depend on the services you host.
Proxmox Cluster Requirements
Some of these can’t be changed later, so check them first:
- Proxmox installed on every node, on the same version, with the time synchronized.
- The final hostname and a static IP on each node. Neither can be changed after the cluster is created, and neither can the cluster name.
- Latency under 5 ms between nodes.
- UDP ports 5405-5412 and TCP port 22 open between nodes, for Corosync and the SSH tunnel.
- No VMs or containers on a node you’re joining. Its configuration is overwritten, storage list included, so create the cluster on the node that already runs your guests, and back up guests on other nodes to restore under new IDs after joining.
- The root password of an existing node, which you enter when joining.
- At least three nodes for HA, or two and a QDevice.
Ideally, Corosync gets its own physical network, and Proxmox says not to share it with storage traffic. A dedicated 1 Gbit NIC is enough in most situations, and Corosync supports up to 8 links, so a second network can be a backup link. Without a spare NIC, you can configure VLANs in Proxmox to separate cluster traffic logically, though it still shares the NIC.
How to Set Up a Cluster in Proxmox
The cluster is created once, on the first node, and every other node joins it. Log in to that first node’s web interface.
1. Select Datacenter, then Cluster, and finally, Create Cluster.
2. Enter a Cluster Name (it cannot be changed later). Under Cluster Network, pick the address for Link 0, which defaults to the IP of the node’s hostname, and select Add if you have a second network for a backup link. Then select Create.
3. Wait for TASK OK, then close the window. The Cluster page now shows the cluster with one node.
From the shell, this does the same thing:
pvecm create CLUSTERNAMEDo You Need Firewall Rules for a Proxmox Cluster?
No. Earlier versions of this guide had you add three rules by hand (UDP 5404, UDP 5405 and TCP 22) before joining a node, and that step is gone. If the Proxmox firewall is enabled, ACCEPT rules for Corosync are generated automatically, and its built-in rules already allow the cluster’s Corosync, API and SSH traffic. The firewall is off by default, so if you have never enabled it, there’s nothing to add. Security changes between releases, though, so nothing here is guaranteed.
How to Join a Node to a Proxmox Cluster
To join a node, paste a cluster node’s Join Information into Join Cluster on the new one, one node at a time.
1. On the first node, select Datacenter, then Cluster, and finally, Join Information. Select Copy Information, which copies the IP address and fingerprint.
2. On the node you’re adding, select Datacenter, Cluster, and Join Cluster.
3. Paste the text into Information, and with Assisted join checked, the Peer Address and Fingerprint fill in. Enter the existing node’s root Password, pick the network under Cluster Network, and select the Join button, which shows your cluster’s name.
4. The node’s certificate is replaced, so the session drops after a few seconds. Reload, log in again, and both nodes show under Datacenter.
From the joining node’s shell, the command below does the same. On current releases it authenticates against the existing node’s API with its root@pam password and fingerprint, so root SSH login isn’t needed.
pvecm add IP-ADDRESS-OF-AN-EXISTING-NODERun the command below on any node to see the membership and quorum. To take a node out later, move its guests off, delete its replication jobs, and power it off, then follow the steps to remove nodes.
pvecm statusMigrating a VM Between Nodes
Test migration first, ideally with a test VM. It is not high availability, since you’re the one moving the guest, but it proves the nodes work together.
1. Right-click a virtual machine, then select Migrate.
2. Pick the Target node and select Migrate. A running VM migrates live and a stopped one migrates offline, and local disks get copied across, which takes a while.
3. When it finishes, the VM shows under the target node.
Live migration is only supported between CPUs from the same vendor, so moving a running VM between Intel and AMD hosts is not guaranteed to work. A VM set to the host CPU type should only move between identical CPUs, and the default for new VMs (x86-64-v2-AES) is the safer choice. The target also needs the same or newer Proxmox VE packages. A passed-through PCI or USB device blocks live migration, and offline migration needs a resource mapping on both nodes.
Backups in a Cluster
Backup jobs live under Datacenter, then Backup, and one job can cover every node. The target can be a Proxmox Backup Server datastore, which Proxmox recommends on a dedicated host, or an NFS share on a Synology NAS. Here’s how to back up VMs and Containers, and how to run Proxmox Backup Server with NFS storage.
When I moved off a cluster onto one server in 2026, the restores worked on the new hardware, but the VMs didn’t start until I recreated the VLAN and bridge networks.
Proxmox High Availability (HA)
If a node goes down, the HA manager restarts its guests on another node, with typical detection and failover times of about 2 minutes. A Proxmox HA cluster needs at least three votes, the guest’s disk available on the node it moves to, and fencing, which Proxmox handles. A node running HA guests that loses quorum can’t reset its watchdog, so it reboots itself after 60 seconds, which makes it safe to start its guests elsewhere.
When I built a three-node cluster on GMKtec NucBox G3 mini PCs in April 2024 (Proxmox VE 8.1.10), the only thing I really cared about was Home Assistant coming back up within a few minutes if it ever went down. That was the one VM I put under HA, and for most people that’s the right way to choose: the guests you’d notice being down, not every guest.
The VM’s disk has to exist on the node it fails over to. In general, I’d say shared storage is the better overall option, but the hardware requirements are significantly higher. You need a device where that storage lives or Ceph, preferably on a 10 Gb network, and those mini PCs didn’t have a 10 Gb NIC. So I used ZFS on every node and set up replication as a shared-storage alternative, with Home Assistant replicating to the other two nodes every 2 hours.
Replication needs local ZFS on each node, and a failover can lose whatever changed since the last sync. If that’s a problem for the guest, add shared storage like the NFS share below.
1. Select Datacenter, then Storage, and finally, Add and NFS.
2. Enter an ID, the Server and Export, and leave Nodes on All. The first section of this tutorial covers the NFS share itself on a Synology NAS.
3. The storage shows Yes under Shared, which is what HA needs.
4. Move the VM’s disk onto it: select the VM, then Hardware, the disk, Disk Action and Move Storage, pick the NFS storage as Target Storage, and check Delete source.
Adding a VM to High Availability
1. Select Datacenter, then HA, check that the status shows quorum OK, and under Resources, select Add.
2. Pick the VM or container, leave Request State on started and the rest on the defaults, and select Add.
On Proxmox VE 9.x, this dialog no longer has a Group field, because HA groups were replaced by affinity rules (below).
3. To test it, shut down the node the VM is running on. Pulling its network cable works too, but that node then resets itself, with every guest on it.
4. Within a couple of minutes, the VM shows as running on another node.
On the mini PC cluster in April 2024, I disabled networking on mini-pve-1 instead, and the high availability worked: the first node went offline and it immediately switched over to the second node (and by immediate, I mean a few minutes), with Home Assistant booting on mini-pve-2.
HA Affinity Rules Replaced HA Groups in Proxmox VE 9
Through Proxmox VE 8, HA groups controlled which nodes a guest could run on, and that’s what I used in 2024 (one group with all three nodes at different priorities). Proxmox VE 9.0 (August 2025) deprecated groups in favor of node affinity rules, and existing groups migrate automatically once every node runs Proxmox VE 9.
A node affinity rule keeps a resource on one of the listed nodes, with priorities, and it’s a preference unless you make it strict. A resource affinity rule keeps guests together on one node or apart on separate nodes, like two DNS servers. Both are added under Datacenter, HA, Affinity Rules, and the old nofailback option is now Failback on the HA resource.
Load Balancing With the CRS in Proxmox VE 9.2
Proxmox VE 9.2 (May 2026) added dynamic load balancing to the Cluster Resource Scheduler (CRS), which migrates HA-managed guests automatically, within your affinity rules, when node CPU and memory usage get out of balance. To turn it on, select Datacenter, then Options, and edit Cluster Resource Scheduling. Set the Scheduling Mode to Dynamic Load (Basic is the default), then check Automatic Rebalance. The Imbalance Threshold defaults to 30 %.
Final Thoughts on Setting Up a Proxmox Cluster
If you do build one, it’s worth it even without HA: one interface for every node, and VMs you can move between them. If you add HA, start with the one or two services you’d actually notice being down (Home Assistant was mine), and test the failover before you trust it.
