How to Set Up a Two-Node Proxmox Cluster for Live Migration

Setting up a two-node Proxmox cluster gives you shared resource pools, live VM/LXC migration without downtime, and automatic failover—all with just one extra machine on your desk. The real work is in the storage configuration that makes clustering actually useful rather than just decorative. Here's how to do it right from day one.

Key Takeaways

• Redundancy — A cluster gives you live migration between nodes so maintenance windows and hardware failures don't mean downtime
• Storage matters most — Shared NFS or iSCSI storage is what actually enables clustering; without it, your two nodes are just independent servers with a fancy dashboard
• DNS isn't optional — Proper reverse DNS resolution across cluster members prevents subtle HA migration failures that only show up under load
• Start small — Two identical Proxmox hosts sharing one NFS volume gets you 90% of clustering benefits for the cost and complexity of just three servers

What Exactly Does a Cluster Give You?

A single Proxmox VE install is perfectly fine for many workloads. But once your resource usage approaches capacity, or when downtime costs matter (whether that's losing an hour of Plex transcoding or taking down production services), clustering stops being optional. With two nodes connected as a cluster, the main benefits fall into three buckets:

1. Live migration — Move VMs and LXCs between hosts without interrupting them using qm migrate under the hood
2. Shared storage access — Both nodes read from (and write to) the same datastores so migrated guests don't need their disks copied over
3. High availability scheduling — The cluster manager can automatically restart failed VMs on surviving hosts

The HA scheduler is particularly useful for homelab setups where you're running a handful of critical containers and want them back online if one node reboots unexpectedly. For production environments, this scales up nicely—more nodes means more redundancy without needing to over-provision each individual host.

Setting Up Your First Cluster: The Steps That Matter Most

The actual setup is straightforward once you know the sequence. Install Proxmox VE on both machines using any of the methods from How to Ditch Bare Metal and Run Everything on Proxmox — ISO, PXE boot, or even a fresh install via Ansible playbooks as covered in Automate Proxmox VE with Ansible Full VM Playbooks.

Once both nodes are up and running, pick one node to be your "primary" (it doesn't really matter which) and join the second:

# On Node 1 — verify cluster status first
pvecm status

# On Node 2 — get an auth token from Node 1 via its GUI or CLI
# Then run this command on each additional node:
pvecm add <node1-ip> --link0 <ip-of-node2-on-link-0>

The --link0 flag ensures you're using the correct network interface for cluster communication. If your management and data networks share a bridge, skip it; otherwise make sure link 0 (the default cluster heartbeat channel) is on the right subnet or you'll get HA split-brain issues that are harder to debug than they sound.

Storage: The Real Reason Clustering Matters

Here's where most people trip up — clustering without shared storage gives you a nice dashboard but very limited redundancy in practice. If your VMs live on local disks and one node fails, those guests stay down even though the other host is healthy. You need to migrate them manually after recovery. The options for shared storage fall into three tiers:

Storage Type	Best For	Complexity	Live Migration Support
NFS mount on existing NAS/SMB share	Homelab, small setups	Low	Yes (with proper permissions)
iSCSI from TrueNAS SCALE or similar	Medium production use cases	Moderate	Excellent — block-level access
Ceph distributed storage	Larger clusters with high availability needs	Higher	Native to Proxmox HA scheduler

For a homelab getting started, NFS is the pragmatic choice. Set up an NFS export on any Linux box (or even one of your existing VMs), mount it identically on both cluster nodes in /etc/fstab, and point your Proxmox datastores at that path:

# On each node — add to /etc/fstab for persistence
<server-ip>:/exports/prox-data  <mount-point> nfs defaults,_netdev,noauto,x-systemd.automount,hard,intr,rsize=8192,wsize=8192,tcp,nosuid,nodev,retry=0,sloppy  0 0

# Mount and verify
systemctl start systemd-automount@<mount-point>
df -h <mount-point>

The key flags here are hard (so NFS clients wait for server response rather than returning errors) and _netdev so the mount waits until network is available during boot. Without these, you'll see intermittent I/O hangs that look like storage failures but aren't.

For iSCSI users, iSCSI Block Storage on Proxmox from TrueNAS SCALE covers the configuration in detail — essentially the same idea at a lower level where both nodes see identical block devices rather than mounted filesystems.

DNS Resolution: The Hidden Requirement Most People Skip

Cluster operations depend on hostname resolution working correctly across all members, and this is one of those things that works fine until it doesn't under load when you're migrating VMs or running HA checks simultaneously. Both forward (hostname → IP) and reverse (IP → hostname) lookups must resolve consistently:

# Verify DNS from each node — run on both hosts
dig @<dns-server> <node1-hostname>.domain.local +short
host <ip-of-node2> | awk '{print $NF}'  # should return correct forward name
nslookup <node-ip-1> | grep 'canonical'   # verify reverse resolves properly

# If DNS isn't available, use /etc/hosts as a stopgap:
cat >> /etc/hosts <<EOF
<ip-of-node2>    node2.localdomain
<ip-of-node3>    node3.localdomain
EOF

The gotcha I've hit repeatedly: if your DHCP server hands out different hostnames than what Proxmox expects, HA migrations fail silently. Set static DNS entries or configure the cluster to use IP addresses consistently by setting cluster_name in /etc/pve/corosync.conf.

When Clustering Actually Makes Sense (and When It Doesn't)

I've seen homelabbers set up clusters with three identical nodes and then wonder why they're not getting much benefit. The answer is usually the same: most of their workloads are small enough to fit on one node, so clustering overhead outweighs redundancy gains. Consider these scenarios where a cluster genuinely pays off versus when you should probably just stick with Backup Server (Automated Backups with Proxmox Backup Server for that use case):

Set up a cluster if:

• You run VMs or LXCs that need to stay online during maintenance windows (live migration is the killer feature)
• Your storage can't handle all your workloads on one node at peak load simultaneously
• You want automatic failover without manual intervention when nodes go down

Stick with a single Proxmox host if:

• Everything fits comfortably under 60% CPU and RAM usage (leaves room for growth)
• Your backups are reliable enough that losing an hour of service is acceptable
• Adding another node would mean more complexity than the redundancy provides — this happens often when you're already running Cloudflare Tunnel on Proxmox for Zero-Trust Remote Access and managing everything through Cockpit (Cockpit on Proxmox: Manage KVM, LXC, and Docker in One UI)

The Tradeoff You're Accepting

Every additional node adds complexity. With two nodes sharing storage via NFS or iSCSI, you get redundancy but also a dependency chain: if your shared storage goes down (or the switch connecting it to both hosts fails), all VMs on that datastore are affected regardless of which Proxmox host is running. This isn't unique to clustering — any dual-node setup has this property — but it's worth understanding before you spend money and time setting up a cluster only to discover your real bottleneck was storage, not compute.

A practical approach: start with two nodes on NFS (or even local disks if you're just starting), verify that live migration works reliably for your workload patterns using qm migrate --live <vmid> <target-node> — and once you've confirmed the cluster is actually useful rather than decorative, consider adding a third node or migrating to iSCSI/Ceph.

Conclusion

A two-node Proxmox cluster with shared storage gives you live migration without downtime, automatic failover for critical workloads, and room to grow as your homelab scales up from that convert-an-old-laptop into a real server. The setup itself is straightforward — install two hosts, join them with pvecm add, configure shared storage — but the tricky part is getting DNS and mount options right so everything works when you actually need it to. Start small with NFS on an existing NAS or VM, verify your migration paths work under load, then expand from there as your workload patterns reveal what redundancy level makes sense for you.