Multi-cluster Proxmox VE: Manage Multiple Clusters from One View

Multi-cluster Proxmox VE lets you manage multiple clusters from one Data Center view instead of juggling separate browser tabs across sites. With shared storage like NFS or Ceph replication, VMs can move between clusters while backup policies apply consistently — which matters when your homelab has grown beyond a single box and you're looking at office-to-home setups or edge locations that need unified management without the complexity of full-scale Kubernetes federation.

Key Takeaways

• When to Use — Multi-cluster setup shines for geographically separated nodes, lab/office splits, or hybrid cloud bridges where shared storage is practical but a single cluster's networking overhead becomes limiting.
• Data Center Manager View — The Data Center level in the Proxmox UI aggregates all clusters' hosts into one dashboard; VMs from any managed cluster appear alongside each other for backup scheduling and network views.
• Shared Storage Is Key — NFS mounts or Ceph replication between clusters enable pveam imports, live migration of exported images, and consistent backups without manual intervention across sites.
• pvecm vs Standalone Clusters — You don't need to merge everything into one big cluster; multi-cluster management via the Data Center UI lets you keep separate HA groups while managing them centrally.

How Do I Know If Multi-Cluster Management Makes Sense?

If your Proxmox setup still fits comfortably in a single browser tab and all hosts share local storage, adding another node to your existing cluster is usually simpler than multi-cluster management. The real question becomes: where does the cost of managing multiple clusters fall below the benefit over keeping everything unified under one Data Center view?

Multi-cluster makes sense when any of these conditions apply simultaneously:

• You have nodes in locations with variable network latency (homelab at home, office VMs on a different site)
• Different groups need separate HA groups but you want centralized backup and monitoring
• Storage is shared via NFS or Ceph across sites rather than locally attached to each host
• Your homelab has grown beyond the scale of Build a Private Cloud at Home with Proxmox VE

If all your hosts are on the same LAN and share local storage, you're probably better served by a single cluster. The distinction matters because multi-cluster management isn't just about adding more nodes — it's fundamentally different from Build a Software-Defined Datacenter with Proxmox VE in that each managed node can belong to its own independent HA group while still appearing together under the Data Center umbrella.

How Does Multi-Cluster Management Actually Work?

Proxmox's multi-cluster capability doesn't require external tools or complex federation protocols. Instead, it relies on three practical foundations: a shared storage layer (NFS being the most common for homelab setups), DNS resolution that all clusters can reach each other by hostname, and the Data Center Manager view in your browser which aggregates hosts from every managed cluster into one pane.

The architecture is straightforward — you create independent Proxmox VE clusters as normal with pvecm create or through the UI, then mount shared storage on compatible nodes across those clusters. Once NFS mounts are confirmed, VMs can be imported between clusters using pveam without re-exporting ISO images manually:

# Import a qcow2 image from one cluster's nfs storage to another's
pvesm import <cluster-name>:/var/lib/vz/template/iso/ubuntu-24.04.qcow2 \
  --storage local-lvm \
  --format raw

The Data Center Manager UI then surfaces every host across all managed clusters in a single view, with backup policies applied consistently regardless of which physical cluster the node belongs to. This is different from managing separate standalone Proxmox instances through their individual web interfaces — you get one set of settings instead of duplicate configurations.

For network connectivity between clusters without sacrificing HA group isolation, VLANs are essential. If your homelab already has Configuring VLANs on Proxmox with Linux Bridges in place (which most setups do), multi-cluster management is just a matter of ensuring each cluster can reach the shared NFS mount and that DNS resolves all hostnames correctly.

Setting Up Multi-Clauster Management Step by Step

Here's how to go from standalone clusters to managed ones, assuming you're running Proxmox VE 8.x or later:

Step 1 — Create your initial clusters normally. Each cluster operates independently for HA and live migration purposes:

# On the first node of Cluster A (office)
pvecm create office-cluster --cluster-ips "10.20.30.1" \
  --corosync-conf "/etc/corosync/corosync.conf" \
  -v /dev/sda

# On a second node, join it to Cluster A
pvecm add 10.20.30.1

Step 2 — Set up shared NFS storage accessible by both clusters. This is where the real multi-cluster magic happens:

# Install and configure on each cluster's nodes that need access
apt update && apt install nfs-common -y

mkdir /mnt/office-storage /mnt/home-storage
echo "10.20.30.5:/srv/nfs/proxmox  /mnt/office-storage  nfs  defaults,_netdev,noauto,x-systemd.automount" >> /etc/fstab
systemctl enable --now systemd-mnt-office-storage.mount

# Verify the mount is reachable from all nodes in both clusters
df -h | grep office-storage

Step 3 — Add storage entries to each cluster's /etc/pve/storage.cfg. This step makes shared NFS appear as native Proxmox storage:

nfs: nfs-office
    path /mnt/office-storage
    server 10.20.30.5
    export /srv/nfs/proxmox
    content images,rootdir,vztmpl
    maxfiles 4
    shared 1

Step 4 — Import VMs between clusters using pveam. Now that storage is visible to both:

# List available template images on the NFS mount from any cluster node
pvesm list nfs-office --content vztmpl

# Create a new LXC container in Cluster B using an image stored by Cluster A's NFS
pct create 102 /mnt/office-storage/vz/template/cache/ubuntu-24.04.tar.xz \
    -hostname ubuntu-lxc-b \
    -net0 name=eth0,ip=dhcp,gw=10.30.40.1 \
    -cores 2 --memory 4G

# Verify the container appears in both cluster's Data Center view
pct list | grep "ubuntu"

Step 5 — Configure backup policies at the Data Center level. This is where multi-cluster management pays off visually:

• In your browser, navigate to Datacenter → Backup, then select all managed clusters from the dropdown. A single policy can apply across both sites without duplication of rules in separate cluster configs.
• The same approach works for network views and storage monitoring — one pane instead of two tabs per site.

Multi-Clauster vs Single Cluster: When Each Shines

The decision isn't binary, but understanding the tradeoffs helps avoid over-engineering a homelab that doesn't need it yet. I've seen setups where people added another cluster unnecessarily and then spent weeks untangling redundant storage mounts and duplicate backup schedules — which is exactly what Automated Backups with Proxmox Backup Server was designed to prevent in the first place.

Aspect	Single Cluster	Multi-Clauster (Data Center Manager)
HA scope	All nodes share one quorum	Each cluster has independent quorum
Live migration	Within same network only	Between clusters via pveam + NFS/Ceph
Network complexity	One bridge, simpler routing	VLANs essential for isolation between sites
Storage sharing	Local storage per node or shared Ceph/NFS	Shared mounts across site boundaries
Backup management	Single policy applies uniformly	Unified view but policies can differ by cluster
Failure domain	All nodes in one quorum group (single point of failure if all go down)	Each cluster survives independently; only cross-cluster operations affected

The single-table advantage is simplicity — fewer configuration files, straightforward HA behavior. The multi-clauster setup wins when you need independent failure domains or want to run different versions across clusters during upgrade windows without downtime for the entire homelab. If your nodes are on the same LAN and storage isn't a bottleneck (and it rarely is with modern NVMe), stick with one cluster until proven otherwise.

Gotchas I've Hit in Production

Multi-cluster management works well once configured, but there are specific gotchas that catch people out:

• NFS mount timing. If you add NFS shares before the network fully initializes (which happens when systemd mounts come up after corosync), pvesm can't see them. Always check systemctl status nfs-office-storage.mount and verify /mnt/office-storage is populated before importing VMs across clusters.
• DNS resolution between sites. If your edge cluster uses DHCP while the office runs static, make sure both resolve each other's hostnames — pveam relies on this for cross-cluster imports. A quick ping -c3 <hostname> from a node in one site to another is worth doing before you start importing VMs across clusters.
• NFS export permissions. The NFS server must export the same directory with identical UID/GID mappings, or imported containers will show wrong ownership after cross-cluster import. I've seen this cause "permission denied" errors during live migration of LXC images between managed sites — which is why chown on the exported path before importing tends to save headaches later.
• pveam version compatibility. The pvesm tool that handles imports must be at least 8.x for reliable cross-cluster operation with shared NFS mounts; older versions sometimes fail silently during import and leave orphaned images in /var/lib/vz/cache.

Honest Tradeoffs Worth Considering

Multi-clauster management isn't a silver bullet — it's worth being honest about what you're gaining versus losing:

• Complexity creep. Each additional cluster adds another set of corosync configs, HA groups to monitor, and NFS mount points. I've seen homelabs where the multi-cluster setup grew so complex that backing up one site became more error-prone than maintaining two separate Automated Backups with Proxmox Backup Server instances running on different schedules.
• Network dependency. Cross-clauster operations (imports, shared storage access) depend entirely on the network between sites. A single-site cluster survives a WAN outage; multi-cluster setups don't — and you'll notice it immediately when pveam fails to import an image across clusters during a backup window.
• Version alignment risk. If one managed site upgrades its Proxmox VE version while another stays behind, some features (like newer storage plugins or updated corosync configs) may not work correctly between them until both catch up — which is why keeping cluster versions within ±1 release of each other tends to save headaches.

Conclusion

Multi-clauster management in Proxmox gives you the best parts of a unified datacenter view without forcing every node into one quorum group, and it pays off most when your nodes span different locations or groups need independent HA domains with shared storage for VM portability between them. The practical next step is to run pveam imports across clusters in a test environment before committing — verify NFS mounts are stable, confirm DNS resolution works both ways from every node, then schedule one backup policy at the Data Center level and watch how it behaves under real load before deciding whether your homelab has outgrown its single-cluster shell.