Proxmox

Building a Proxmox Cluster From Mini PCs

Three small boxes, one web UI, and VMs that restart themselves. The decisions that matter, in the order you need to make them.

By Brandon Sheley · Updated Oct 19, 2026

Short answer: use three mini PCs (or two plus a QDevice), give them final hostnames and IPs, a dedicated network port for cluster traffic if they have one, and ZFS on each so Proxmox can replicate VM disks between them. Then create the cluster on one node and join the others while they're still empty.

My own homelab is a single Proxmox cluster spread across three nodes. The requirements and commands below are from Proxmox's own Cluster Manager documentation; the storage advice is what actually fits hardware with one or two NVMe slots.

How Many Mini PCs Do You Need?

Three is the real minimum if you want high availability. A Proxmox cluster decides what's running by majority vote (quorum). With three nodes, one can die and the other two still have a majority, so they keep running and can restart its VMs. With two, losing either one leaves a single vote out of two, which isn't a majority, and the survivor stops letting you start or change guests.

Two nodes plus a QDevice is the supported way around that. A QDevice is a tiny external vote, the corosync-qnetd service running on something else that's always on: a Raspberry Pi, a NAS, a small VM on another machine. Proxmox recommends it for every 2-node cluster.
A cluster without HA is still useful. Even two nodes give you one web UI for everything and the ability to move guests between machines, which is most of what a homelab wants day to day.

Before You Create the Cluster

Most cluster problems come from things that are hard to change after nodes join. Get these right first:

Same Proxmox version on every node, fully updated (how to update from the command line).
Final hostnames and IP addresses. Changing either after a node has joined is painful, and the cluster name can't be changed at all.
Empty nodes. A node that joins can't have any VMs or containers on it, because their IDs could clash with ones already in the cluster. Build the cluster first, then create guests, or back them up and restore them afterwards.
Network: nodes need to reach each other on UDP 5405-5412 (corosync) and TCP 22 (SSH), with time synced on all of them.
A separate network for cluster traffic, if you can. Corosync is sensitive to latency, not bandwidth. Proxmox recommends a dedicated NIC for it, so a backup job or a live migration saturating the main link can't make nodes lose contact. Mini PCs with two onboard ports are ideal: one for VMs and storage, one just for corosync.
Same CPU vendor for live migration. Online migration only works between nodes with CPUs from the same vendor. With mixed Intel generations, leave VMs on a generic CPU type (the x86-64-v2-AES default) instead of host, or a VM may not start on an older node.

Creating the Cluster and Joining Nodes

In the web UI: on the first node, go to Datacenter → Cluster → Create Cluster, name it, and pick the cluster network link. Click Join Information and copy it. On each other node, go to Datacenter → Cluster → Join Cluster, paste it, and enter the first node's root password.

Or from the shell:

# on the first node
pvecm create homelab

# on each node joining it (10.0.10.11 = first node, 10.0.20.12 = this node's
# address on the dedicated cluster network)
pvecm add 10.0.10.11 --link0 10.0.20.12

# check from any node
pvecm status

Join one node at a time and wait for it to show up green in the UI before adding the next.

Storage: The Decision That Decides Everything Else

Moving and restarting VMs between nodes needs their disks to be somewhere the other node can use. Mini PCs usually have one or two NVMe slots, which rules some options in and others out:

Option	How it works	Good fit for mini PCs?
Local ZFS + replication	Each node has a ZFS pool with the same name; Proxmox copies VM disks to the other nodes on a schedule (every 15 minutes by default).	Usually the best fit. Works with one NVMe drive per node. If a node dies, HA restarts its VMs from the last replica, so you can lose up to one interval of changes.
Shared NFS or SMB from a NAS	VM disks live on the NAS; every node mounts it.	Good, and simple. Migration is fast because nothing is copied, but the NAS is now a single point of failure, and you want at least 2.5GbE to it.
Ceph	Every node's disks form one replicated storage pool.	Usually not. Ceph wants three or more nodes, several disks each, and a fast dedicated network (10GbE). On one NVMe per node over gigabit it's slow and fragile.

Local ZFS replication needs ZFS on every node, which is worth knowing at install time: the default installer layout on a single disk is ext4 with LVM-thin. I cover the trade-off in ZFS vs LVM-thin on Proxmox.

Turning On High Availability

Once you have quorum and storage every node can use, HA is a few clicks: Datacenter → HA → Add, then pick the VM or container. If its node stops responding, the cluster waits for that node to fence itself (a watchdog reboots any node that loses quorum, so a VM can't run in two places at once) and then starts the guest on another node.

Two things to know before relying on it. HA reacts in minutes, not seconds, so it's for "the DNS server came back by itself," not zero-downtime. And a guest on local storage without replication can't be restarted elsewhere, so check every HA guest's disks are on replicated or shared storage.

What I'd Use for the Nodes

Matching nodes make everything easier: same CPU vendor, same NIC layout, same pool name. Three used 1-liter business minis (OptiPlex Micro, EliteDesk Mini, ThinkCentre Tiny) with 32GB each are the classic budget cluster, and they idle around 12-16W apiece. A pair of Minisforum MS-01s plus a QDevice gets you 10GbE between nodes for faster replication and migration. Current prices for all of them are on the SFF tracker, and the mini PC guide covers what to check on each.

Related Resources

Best Mini PC for Proxmox

Which mini PCs make good cluster nodes, and what to check first.

ZFS vs LVM-Thin on Proxmox

The storage choice that decides whether replication is an option.

Proxmox Backup Server Setup

A cluster isn't a backup. Where the backups should go.

PegaProx Setup Guide

A dashboard for managing several Proxmox clusters at once.

Proxmox Updates

Updating nodes one at a time from the command line.

SFF & Mini PC Price Tracker

Live prices for cluster-node candidates.

Frequently Asked Questions

Can I make a Proxmox cluster with two mini PCs?

Yes, but add a QDevice. With only two nodes, losing either one means the survivor no longer has a majority vote and won't let you start or change guests. A QDevice is a third vote from a small always-on device running corosync-qnetd, such as a Raspberry Pi or a NAS, and Proxmox recommends it for every 2-node cluster.

Do I need shared storage for a Proxmox cluster?

Not to build one, but you do for high availability and quick migration. On mini PCs the usual answer is ZFS on every node with Proxmox storage replication, which copies VM disks between nodes every 15 minutes by default. Shared NFS from a NAS also works. Ceph generally needs more nodes, more disks and a faster network than mini PCs have.

Can a node with existing VMs join a Proxmox cluster?

No. A joining node can't hold any guests, because their IDs could clash with guests already in the cluster. Back them up, join the empty node, then restore them, or build the cluster before creating any guests.

Should corosync have its own network?

Proxmox recommends it. Corosync needs low, steady latency more than bandwidth, and heavy traffic like backups or live migration on the same link can make nodes lose contact with each other. A mini PC with two network ports can use one just for cluster traffic.