When PDM is the wrong answer · Proxmox VE

Five lessons of capability, and now the lesson that decides whether any of it applies to you.

This is not a ritual disclaimer. PDM solves one specific problem — humans losing track of an estate spread across several independent clusters — and it solves it well. Estates that do not have that problem, or that have already solved it another way, get a new host to patch, a new credential store to protect, and a second place where the numbers might disagree.

Three situations where the answer is no.

Wrong answer one: you have one cluster

A Proxmox VE cluster already has a unified interface. Log into any node and you see every node, every guest, every storage, one task log, one ACL database, one set of users, one subscription view, one updates panel. That interface is live, not collected, and it can do everything — create guests, edit configuration, manage Ceph, edit firewall rules, configure HA, define backup jobs — where PDM can do a documented subset.

Put PDM in front of a single cluster and you get, honestly, a worse version of what you already have:

	The cluster’s own interface	PDM in front of one cluster
Freshness	Live	Collected, with a last-seen fallback
Guest creation	Yes	Not offered
Ceph	Full management	Read-only
Firewall	Full management	View only
Backup jobs	Full management	Not offered
HA configuration	Full management	Not offered
Roles available	Many, plus custom roles	Three, no custom roles
Additional hosts to run	None	One
Additional credential stores	None	One, holding a cluster token

There is one genuine exception, and it is worth knowing because it is the only thing PDM does that a single cluster cannot: views granted without resource access. If you need to give a NOC, an application team or a manager a dashboard over the cluster without giving them an account on the cluster, PDM’s /views/{id} permission model does that cleanly and PVE has no direct equivalent.

Weigh it honestly, though. A PVE account with PVEAuditor scoped through a resource pool covers a large fraction of the same need without a new host. Reach for PDM here when the read-only consumers genuinely must not have a cluster account at all — a contractual boundary, an auditor, an external support partner — and not merely because a custom dashboard would be nice.

The other legitimate reason is anticipation: you have one cluster today and a funded plan for the second one this quarter. Standing PDM up early, against one remote, is a reasonable way to have the trust model settled before it matters.

Wrong answer two: your provisioning is scripted

Part XX built a different answer to the multi-cluster problem: talk to the API. pvesh, the REST API directly, Proxmox modules for Ansible, Terraform against each cluster’s provider, Python through a client library. If that is how your estate is built, routing anything through PDM makes it worse in four specific ways.

PDM cannot create. No documented guest-creation workflow exists in 1.1.7, and “basic guest configuration beyond snapshots, lifecycle and migration” is a roadmap item. Your provisioning must talk to PVE regardless. PDM would be an additional path, not a replacement one.

PDM is a cache. Lesson 3 established that everything you read from PDM comes from a collection run whose interval is not documented, with a last-seen fallback for unreachable remotes. Automation that makes decisions from cached inventory makes decisions from the past. A script that reads “VM 141 is stopped” from PDM and acts on it is acting on a photograph. Read state from the cluster that owns it.

PDM collapses attribution. Every action PDM takes on a cluster arrives as the single token in remotes.cfg. A pipeline that talks to PVE directly can give each system its own privilege-separated token — terraform@pve!prod, ansible@pve!patching, backup-verify@pve!nightly — and the cluster task log then says which system did what. Route them through PDM and every one of them becomes the same identity in the cluster’s log.

PDM adds an indirection with no capability gain. Two APIs to learn, two credential lifecycles to manage, two things to version-track, in exchange for functionality that already exists one layer down.

Where PDM genuinely helps an automated estate

The argument above is against putting PDM inside the pipeline. Alongside it, PDM earns its place for the things automation is bad at, which are all human-facing:

Discovery for a person. “Which cluster is that guest on” answered from a filter box, with tag: and remote: qualifiers, instead of a script.
Fleet reporting for a human question. remote subscriptions and the update overview answer “is everything subscribed and patched” across the estate in one place.
An incident timeline. The aggregated task log across clusters, at a moment when nobody wants to write a query.
Occasional cross-cluster migration. The one capability with no clean scripted equivalent, and the reason many automated estates run PDM at all.

The rule of thumb is a clean one: machines talk to PVE, humans talk to PDM. Keep the pipeline pointed at the source of truth and let PDM be the window people look through.

Wrong answer three: you already have an orchestration layer

The third case is the expensive one, because it fails slowly.

An estate with Terraform or a similar tool for provisioning, Ansible for configuration, a CMDB or asset register, Prometheus and Grafana for metrics and alerting, a log pipeline, and a ticketing system with change records has already built answers to every question PDM answers. Adding PDM does not remove any of those. It adds a parallel answer.

Parallel answers do not stay equal:

Question	Existing answer	PDM’s answer	What happens
What exists?	CMDB or Terraform state	Collected inventory	They diverge; nobody knows which is authoritative
How is it doing?	Grafana on scraped metrics	Dashboards on collected RRD	Two graphs, different numbers, arguments
What happened?	Log pipeline	Aggregated task log	Two timelines to reconcile in an incident
Who may do what?	IdP and pipeline permissions	PDM ACL	A second permission surface to review and to leave stale
What is patched?	Patch management tooling	Update overview	A second patch report to explain

None of those is a catastrophe on its own. Together they produce the outcome every experienced operator recognises: a screen somebody trusts that disagrees with a screen somebody else trusts, and thirty minutes of an incident spent establishing which one is right.

Two dashboards, one estate, different numbers

The disagreement is usually real and usually nobody’s fault.

Grafana scrapes each cluster every 30 seconds and shows a gap when scraping fails. PDM collects on an undocumented interval, skips delayed collection runs rather than queueing them, and shows a last-seen value when a remote is unreachable. On a healthy estate they agree. On a degraded one — which is when you are looking — one shows a hole and the other shows the value from before the hole.

Storage totals compound it. Lesson 3 covered how PDM 1.1 had to fix shared cluster storage being counted several times toward capacity, and aggregation across clusters involves a stack of judgement calls: thin provisioning, Ceph raw versus usable, PBS deduplicated versus logical. Two tools can both be defensible and disagree by twenty percent.

If you adopt PDM into an estate that already has observability, say in writing which system is authoritative for which question, and put PDM’s answer in the “indicative, for orientation” column. An unranked second opinion is worse than no second opinion.

The productive move in this situation is not to reject PDM outright but to scope it to its differentiator. Run PDM for the cross-cluster inventory lookup, the delegated views, and cross-cluster migration; leave alerting, provisioning and the system of record where they are; and grant its remote tokens at the visibility level from Lesson 5 unless migration is genuinely needed. That is a small, honest deployment that adds something and duplicates nothing.

Three more things PDM is not

Briefly, because earlier lessons made the arguments:

Not a monitoring system. Notifications for remotes are being evaluated, notifications for the PDM host itself are a roadmap item, and PDM has no high-availability architecture. It cannot page anyone.

Not disaster recovery. Cross-cluster migration requires the source cluster to be healthy enough to read every disk. DR is Part XIV.

Not a compliance boundary. This is the one people get wrong in the dangerous direction. PDM concentrates; it does not separate. If two environments are required not to share a control plane — a regulated environment and a development one, two customers, two security domains — then connecting both to one PDM is a control-plane join, however carefully you configure the ACL. The boundary you were asked for is a second PDM, or no PDM on one side.

Under the hood

Why is “just add it, it is read-only” not a sufficient argument?

Because read-only is a property of the grant, not of the software, and the grant can be changed by anyone with Access.Modify in PDM — while the consequences of having connected the remote persist regardless of the grant.

Connecting a cluster to PDM does three things that survive any subsequent tightening of the ACL:

A credential now exists on that cluster with whatever privileges you granted the token, held in a file on a different host. Narrowing PDM’s own ACL later does not narrow the token.
The estate’s shape is now recorded in one place. Names, tags, addresses, node counts, storage names, guest inventory. For an attacker, that map is valuable on its own, entirely separately from any ability to act.
A dependency forms in people’s heads within weeks. The installation documentation says it plainly: no managed remote depends on PDM to run, but you may find PDM becomes a convenient and critical tool in your operations fast enough. Removing it later is a process change, not an uninstall.

None of those is an argument against adopting PDM. They are an argument for adopting it as a decision with a design document, rather than as an experiment that quietly became infrastructure — which is how most single-purpose management VMs actually enter an estate.

The real cost of adoption

Write these into the design document, because the ones nobody wrote down are the ones that surprise a successor:

A host to run, patch and monitor, on apt full-upgrade because a rolling release on Debian breaks under apt upgrade.
A credential store to protect. remotes.cfg holds a working token for every cluster.
A backup with secret-bearing content, encrypted and access controlled.
A log to retain, because PDM’s task log is the only record of which human asked for a cluster action.
A version to track against remote versions, since feature availability varies by remote version — remote shell needs PVE 9.1 or PBS 4.1.
A subscription ratio to watch. Enterprise repository access needs at least 80% of configured remote nodes on Basic or higher, and the denominator includes anything you connect.
An unpublished end-of-life. The FAQ lists PDM 1’s EOL as TBA.
No high availability for PDM itself, with two side-by-side instances as the documented workaround.

That is not a long list, and none of it is unusual for an infrastructure component. It is simply longer than the list most people have in mind when they describe PDM as “just a dashboard”.

Should we run PDM? A five-question framework

Answer in order and stop at the first clear no.

How many independent clusters and backup servers? One: almost certainly not, unless the delegated-views case applies or a second cluster is funded and imminent. Two: marginal, decided by question 3. Three or more: continue.
Do humans lose time to the fragmentation? Concretely: does anyone regularly ask “which cluster is that on”, or assemble an incident timeline from several task logs, or check subscriptions and patch state cluster by cluster? If not, the problem PDM solves is not the problem you have.
Is there an existing system of record and observability stack? If yes, PDM must be scoped to its differentiators and explicitly ranked below the existing systems for any question they both answer. Write that ranking down before deploying.
Is there a compliance or tenancy boundary that a shared control plane would cross? If yes, that boundary decides the topology: separate PDM instances, or no PDM on the sensitive side. This overrides convenience.
Can you commit to the cost list above? Patching, backup, log retention, token rotation, an unpublished EOL, and the design document that records the remote-token privilege level. If the honest answer is that this will be a VM nobody owns, do not build it — an unowned host holding a credential for every cluster is worse than the inconvenience it was meant to fix.

What happens when you decide to remove PDM?

Un-adopting is a real procedure, and doing it in the wrong order leaves credentials scattered across production.

Remove the remotes first, one at a time, from PDM.

Configuration changethe removal that also cleans up the cluster— --delete-token defaults to true, so the API token is removed from the remote as part of the removal. This is the behaviour you want; do not override it.

# proxmox-datacenter-manager-admin remote remove site-a

Then verify on each cluster that the token is actually gone — pveum user token list for the user PDM authenticated as — because a removal that failed partway looks the same from PDM as one that succeeded.

Only then destroy the PDM host. Deleting the VM first skips every step above and leaves a valid, privileged, unowned token on every cluster you ever connected. If that has already happened — and it happens most often when someone rebuilds PDM rather than when someone decommissions it — the remediation is to enumerate tokens on every cluster and remove the ones PDM created, working from the authid values in whatever copy of remotes.cfg you can still find.

Two more things to handle that are easy to forget. Any documentation, runbook or dashboard link pointing at PDM needs updating, or your successors will spend an incident wondering why the address does not answer. And any read-only consumer you delegated a view to now has nothing — those people had a PDM account precisely because they had no cluster account, so removing PDM removes their visibility entirely. Give them a replacement before you switch it off, not after.

Where PDM is the right answer

To finish honestly, because five lessons of caveats can leave the wrong impression. Adopt PDM when most of this is true:

Three or more independent clusters, or clusters plus backup servers, with no plan to consolidate them.
Human operators who work across all of them and currently pay a daily tax in tabs, lookups and context switching.
Geographic or organisational separation that makes a single cluster impossible rather than merely inconvenient.
A need to delegate visibility without access — the views case, which is the cleanest thing in the product.
Occasional planned cross-cluster moves, treated as changes with windows and rehearsals.
Willingness to own the host properly, including its credential store.

In that estate PDM is genuinely good, and the aggregated task log alone will pay for it during the first multi-cluster incident.

Key takeaways

One cluster: the cluster’s own interface is live, more capable, and needs no extra host. The exception is delegated views for people who must not have a cluster account.
Scripted estates: machines talk to PVE, humans talk to PDM. Routing automation through PDM costs creation ability, freshness and attribution, and gains nothing.
With an existing orchestration and observability stack, PDM creates parallel answers. Scope it to its differentiators and rank it explicitly below the system of record.
PDM is not monitoring, not DR, and never a compliance boundary — it concentrates control rather than separating it.
Adoption costs a patched host, a protected credential store, an encrypted backup, retained logs, a version to track, a subscription ratio to watch, and an EOL published as TBA.
Un-adopt by removing remotes first, with the default token deletion, and verifying on each cluster before destroying the host.

Knowledge check

Why this matters

There is a particular way management tools enter an estate. Somebody installs one to try it, connects a couple of clusters, shows a colleague, and it is useful. Nobody writes a design document, because nothing was decided — it was just tried. Three months later four people rely on it daily, it holds a token for every production cluster, it has never been patched, nobody backs it up, and its logs are the only record of who stopped that VM.

That is not a PDM problem. It is how every single-purpose management VM in the industry gets built, and the reason this lesson exists at the end of the part rather than the beginning: you cannot make the adoption decision honestly until you know what the tool actually does, what it does not do, and what it costs.

The decision itself is small. Three or more clusters, humans paying a daily tax, no boundary that forbids a shared control plane, and someone willing to own the host — build it, and it will be worth it. Any of those missing, and the answer is either no or a much smaller yes than the demo suggests.

What matters is that somebody makes the decision, writes down which of the five questions it turned on, and revisits it when the estate changes. A tool that arrived by decision can leave by decision. A tool that arrived by accident is the one still holding your credentials in three years, on a host that nobody remembers building.