Multi-cluster management with Proxmox Datacenter Manager

Moving a running guest between clusters is a different operation from moving it between nodes of one cluster. Inside a cluster, nodes share configuration through the Proxmox Cluster File System, so every node already knows about the guest's configuration, storage definitions and network setup. Across clusters, the source and target each keep their own configuration, storage definitions and network layout, and nothing guarantees that they agree. A migration that works between two nodes can fail between two clusters for reasons that have nothing to do with the hypervisor. Treat each cross-cluster move as a comparison of two independent environments, and check the guest against the target before any move is scheduled.

The dependencies to check are storage, network, CPU and guest configuration. Storage is the first gate: confirm which storage the guest uses on the source and whether the target can reach that same storage, or whether disks must be copied across the link, which changes both duration and downtime. For network, the bridges or SDN zones the guest's interfaces reference must exist on the target with matching names and VLAN behavior, or the guest will start without working connectivity. For CPU, confirm that the processor model and features the guest depends on are available on the target hardware. Finally, check the guest configuration itself: VM IDs, passthrough devices, firewall rules, HA group membership, tags and backup jobs that refer to the source cluster.

Several things cannot be assumed. Central views in Datacenter Manager show resources from many clusters, but they do not make those resources identical, so an SDN zone or user realm that appears in both places may still differ in detail. High availability and fencing on the source cluster do not protect the guest after it lands on the target, which needs its own HA configuration and quorum. Supported migration paths, their prerequisites and their limits change between releases, so confirm them in the Datacenter Manager and Proxmox VE documentation for the exact versions you run. Also confirm how snapshots, replication jobs and backup retention behave after a move, since those features are tied to the cluster that created them.

Migration planning should start from the guest storage design, not from the list of guests that need to move. The storage design determines which paths are possible, how long each move takes, and what happens to snapshots and replication. Build a per-guest record that lists the source storage, the target storage, the network dependencies, the CPU model and the backup and HA settings. Use that record to decide three things: whether a guest should move live at all, whether a planned restore from Proxmox Backup Server is the safer route for it, and which guests need a maintenance window. Ask your implementation partner or your own platform team to validate this record before the first move.

The decision comes down to where you want the failure domain and the configuration domain to sit. A stretched cluster keeps one configuration domain: every node joins one Proxmox VE cluster and shares the Proxmox Cluster File System, which replicates configuration to all nodes in real time. Separate clusters coordinated by Proxmox Datacenter Manager keep independent failure domains, with each cluster holding its own quorum and its own guests. Neither design is correct in general. The right choice depends on the latency, storage replication and failure scenarios your team must design for, so start by writing those down before comparing products.

Proxmox VE high availability sets a hard floor for a stretched design. It needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing, so a failed node is reset before its guests restart elsewhere. Across two sites, the open questions are where the third vote lives and what happens to quorum when the sites lose contact. Confirm the supported options for a third site or quorum device in the vendor's high availability documentation. Also confirm how your chosen shared storage behaves across the link, because guests cannot recover onto a storage pool the surviving site cannot reach.

A WAN fault affects the two designs differently. In a single stretched cluster, a link failure splits the membership into partitions, and only the partition holding quorum continues HA recovery. Guests on the other side may stop being managed or be fenced, so the outage spans both sites. With separate clusters, each cluster keeps running its own guests and its own HA while the link is down. What you lose is the cross-cluster view and cross-cluster live migration, which the manager depends on. Test both cases in a lab with the WAN cut deliberately, and record what each partition does.

Operational blast radius and administrative overhead pull in opposite directions. A bad change to a stretched cluster's shared configuration reaches every node at once. Separate clusters contain that change to one cluster, but they multiply the work: each cluster needs its own upgrades, backups, monitoring and access reviews, and the manager becomes a shared dependency that needs its own protection. Before deciding, ask your vendor which features the manager supports in your release, and write a decision matrix that scores both designs against your failure scenarios, your upgrade cadence and the staff who will run them.

Write the acceptance criteria before the first test runs, and have the people who will own the outcome sign them off. Without written criteria, a test that ends with a guest running on the target cluster can look like a pass even when its network path, storage mapping or backup coverage is wrong. For each move, define what must be true afterward: the guest keeps its intended network reachability and firewall behavior, its disks are attached and writable from the target, it boots with the same firmware and boot order, and its configuration matches the source except for expected changes. Add backup criteria, such as a backup from the target appearing in the Proxmox Backup Server view and restoring to an isolated network. Confirm the exact move prerequisites in the Datacenter Manager documentation for your release, because supported storage types and network mappings are the first things to check.

Run the plan on a non-production copy of the environment: a test cluster, a test Datacenter Manager instance and a Proxmox Backup Server with a throwaway datastore. Register the test cluster in Datacenter Manager and confirm it shows the expected nodes, guests and storage. Pick a non-critical KVM virtual machine that matches a production pattern, such as a bridged network with VLAN tags and a disk on the same storage type you use in production. Record a baseline before the move: bridge and VLAN configuration, IP addresses, storage identifiers, boot mode and boot order, and the results of a simple reachability and service check. Repeat the same checks after the move and compare them line by line. Repository choice belongs in this setup as well. The no-subscription repository suits test environments, while production nodes should use the enterprise repository with a valid subscription key, as the Proxmox package repository guidance recommends.

Repeat the move with failure injection, because the interruption is where the risk sits. Break the cluster link between source and target during the transfer, using a firewall rule or an interface shutdown on a test network. Then record the guest's state: running on the source, stopped, or in an unclear state with a lock on its configuration. Check whether Datacenter Manager reports that state accurately, and whether the guest can be recovered by following your documented runbook. If any guests in scope are managed by high availability, include that in the test. Proxmox VE HA needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing, so observe how a failed node is fenced and how its guests recover instead of assuming it. Repeat each failure at least once and record who makes each recovery decision.

Finish with backup visibility and role checks. Confirm that backups of the test guest, taken in the source cluster, appear from the target-side view and that the Proxmox Backup Server datastore is reachable through the expected storage definition. Restore one backup to an isolated network, boot it, and verify application data, not only that the operating system starts. Then test access control. Create a test user in each authentication realm you plan to use, whether Linux PAM, LDAP, Active Directory or OpenID Connect, and enable the second factor you will require. Check that each role can perform the actions it should and nothing more, including moves and restores. Confirm the role names and privileges in the Datacenter Manager documentation for your release before you script these checks, and keep the results with the acceptance criteria so the decision to go to production rests on evidence.