What Proxmox Datacenter Manager is, and is not

Everything else in this course has assumed one cluster. Part XI built it, Part XII made it fail over, Part VIII gave it storage, and Part XIX taught you to fix it at three in the morning. All of that material is written from inside a single /etc/pve, a single corosync ring, a single quorum, a single ACL database.

That assumption holds until the day you build the second cluster. Then it stops holding all at once, and nothing in the single-cluster material tells you what to do about it.

Why there is a second cluster at all

The instinct, when capacity runs out, is to add nodes. A Proxmox cluster does grow — but it grows against a ceiling, and the ceiling is not a licence limit or a supported-node count. It is the physics of the thing that makes a cluster a cluster.

Corosync wants low, predictable latency between every pair of nodes, because the totem protocol has to complete a round across all members before the cluster can agree on anything. pmxcfs replicates the whole of /etc/pve to every node, and every configuration write is a synchronous, quorate operation. Neither of those scales the way a stateless service does, and neither of them tolerates a wide-area link.

So the second cluster appears for one of four reasons, and it is worth naming which one you are in, because it changes what you need from a management layer:

• Geography. A second site, far enough away that corosync would be unreliable across it. This is the most common reason and the least negotiable.
• Blast radius. One pmxcfs is one failure domain. A cluster-wide corosync incident takes every guest on it into an unquorate state at once. Splitting a hundred nodes into four clusters of twenty-five converts one total outage into one quarter of an outage.
• Change isolation. You cannot upgrade half a cluster to a new major version. You can upgrade one cluster out of four and watch it for a month.
• Tenancy or compliance. A customer, a regulated workload, or an environment that is not allowed to share a control plane with the others.

Every one of those reasons is a reason the clusters should stay separate. That is the point worth holding on to before you meet PDM: the second cluster is not an accident to be undone. It is a deliberate boundary, and a management tool that dissolved the boundary would be destroying the thing you built it for.

The problem the second cluster creates

What the second cluster costs you is not capability. It is coherence. Each of the following was a single thing and is now N things:

None of these is dramatic on its own. Together they are the reason a two-cluster estate feels more than twice as much work as a one-cluster estate, and the reason a five-cluster estate has an operator whose whole job is knowing where things are.

What Proxmox Datacenter Manager is

Proxmox Datacenter Manager is a separate Proxmox product — its own ISO, its own Debian package set, its own host — that connects to Proxmox VE and Proxmox Backup Server instances and gives you one interface over all of them. In PDM’s vocabulary each connected instance, whether it is a single node or a twenty-node cluster, is a remote.

The architectural sentence that matters most is in the first paragraph of the official introduction: PDM acts as a high-level control plane while providing a transition — the documentation calls it an “escape hatch” — to the native web interface of each remote for granular configuration. The architecture is described as loosely coupled, so that the central manager does not become a bottleneck or a single point of failure for the operation of the underlying remotes.

That is not marketing softening. It is a design commitment with a testable consequence, and it is the single most important thing to understand about PDM:

PDM against PVE and PBS

Three products, three jobs. The confusion is worth killing early because two of the three have “manager” in their vocabulary.

The last row is not trivia. Three Proxmox products, three ports, and PDM’s is the one people get wrong because it does not follow the 800x pattern. PDM’s API daemon, proxmox-datacenter-api, exposes the whole API on TCP 8443 over HTTPS, running as www-data with limited permissions, forwarding anything privileged to proxmox-datacenter-privileged-api over a local UNIX socket at /run/proxmox-datacenter-manager/priv.sock. That two-daemon split is the same pattern PBS uses, and PDM inherits the REST/API stack from PBS wholesale.

What shipped, as of 1.1.7

This is the part that a course gets wrong most easily. A young product accumulates blog posts, forum threads and roadmap items that read like features, and six months later nobody can remember which ones exist. The list below is what the 1.1.7 documentation describes as present.

Inventory and visibility

• A cross-remote inventory of nodes, VMs, containers, storages and PBS datastores, searchable from one field.
• A global dashboard covering remote and resource state, running and stopped guest counts, datastore state, running tasks, CPU and memory, SDN zones, and subscription status.
• Views: custom dashboards over a filtered subset of resources, built from widgets, with permissions grantable on the view itself.
• Task aggregation across the whole estate, filterable, for auditing and incident work.
• A global repository and pending-updates panel across all remotes.
• RRD graphs for remotes and, since 1.1, for the PDM host itself.

Acting on things

• Power operations on nodes and guests: start, stop, shutdown, reboot, and an explicit resume for paused or suspended QEMU guests.
• A cross-remote guest list — flat table or tree grouped by remote — with filtering, sorting, and per-guest actions.
• Snapshot management for QEMU and LXC guests: create, roll back, delete, edit description, shown as a parent/child tree with the running state marked as a NOW entry.
• Guest migration within a remote and between remotes.
• Applying updates to remotes, which PDM does by leveraging remote shell access.
• Remote shell access to nodes, which requires PVE 9.1 or PBS 4.1 or later, because that is the release in which API tokens gained the ability to request shell access.

Estate management added in 1.1

• A subscription registry: a central pool of PVE and PBS keys, assignment and clearing per node, an auto-assign proposal that picks the smallest covering key by socket count, and an adopt action that imports keys already live on a node into the pool.
• Automated installation management: PDM stores answer files and serves them to new installations, tracks installation progress in its interface, and protects the process with a token system.
• Ceph monitoring across hyper-converged PVE remotes.
• SDN: a status overview of zones across remotes, and EVPN zone and VNet configuration across multiple remotes.

What PDM cannot do

Shorter list, higher value. Each of these is a thing an operator has assumed and been wrong about.

Ceph is read-only. The documentation is unambiguous: the Ceph integration surfaces state for monitoring and triage but does not create, change or destroy Ceph resources. There is an “Open Web UI” button precisely so you can go and do the management operation on the cluster itself.

Firewall is a view. The Remotes area has a Firewall tab that shows the configured rules and settings for each PVE remote, its nodes and its guests. Showing. Firewall management appears on the roadmap, expected alongside the later SDN work.

No guest console. “A console for remote resources (nodes and guests)” is a roadmap item. You get a shell on a node, and you get an “Open in PVE UI” action that hands you to the cluster’s own interface for a guest console.

No cross-cluster HA. Nothing in PDM restarts a guest somewhere else when a cluster fails. HA is a PVE feature, bounded by a single cluster’s quorum, and Part XII’s limits are unchanged by PDM’s existence. The roadmap mentions off-site replication copies of guests for manual recovery, and takes care to add “(not HA)”.

No backup job management. PBS remotes give you datastore contents and usage. A backup-job overview with last-execution status is a roadmap item, as is prune retention and datastore content browsing beyond what is there today.

No bulk actions across guests. Selecting fifty guests and stopping them is a roadmap item. Today the per-guest actions are per guest.

No Proxmox Mail Gateway. PMG as a remote is on the roadmap. PDM manages PVE and PBS.

Reading the maturity honestly

PDM is young, and the release history is short enough to read in full:

Two years from alpha to the second minor release. For comparison, PVE has been shipping since 2008. That difference is not a criticism; it is a planning input, and it shows up in three specific places.

The support window is unpublished. The FAQ carries a version-support table, and for Proxmox Datacenter Manager 1 both the Debian EOL and the PDM EOL columns read TBA. Every other Proxmox product publishes a supported-until date. If your change-management process requires a documented support lifetime for a production dependency, PDM does not have one yet, and you should say so in writing rather than discover it at audit time.

There is no HA story for PDM itself. The roadmap says an active-standby architecture for PDM is being evaluated, and notes that two instances side by side already cover this in practice at the cost of doubled metric collection. That is a workaround, honestly labelled, and it is the current answer.

Features are landing fast, which cuts both ways. The 1.1 changelog includes a fix for a flaw where an attacker could manipulate a panic display to run arbitrary code in a user’s browser context, and hardening of the Markdown viewer’s HTML sanitiser. Both are good — they were found and fixed. Both also tell you this is a codebase still finding its edges, and that keeping PDM patched is not optional.

# proxmox-datacenter-manager-admin versions --verbose

Key takeaways

• A second PVE cluster exists because a single cluster has a real ceiling — corosync latency, one pmxcfs failure domain, one upgrade unit, one tenancy boundary. PDM manages across that boundary; it does not remove it.
• PDM is a control plane, not a cluster and not a hypervisor. Every remote runs identically whether PDM is up or down.
• PDM 1.1 ships inventory, dashboards and views, task aggregation, guest power actions and snapshots, cross-remote migration, update rollout, remote shell, a subscription registry, automated-installation answer files, read-only Ceph monitoring, and cross-remote EVPN.
• PDM does not manage Ceph, does not manage firewalls, does not give a guest console, does not do cross-cluster HA, does not manage backup jobs, does not do bulk guest actions, and does not manage PMG.
• The product reached 1.0 in December 2025 and publishes TBA for its own end-of-life. Treat that as a planning fact, not a footnote.

Knowledge check