On this page
The moment my homelab outgrew a single Proxmox cluster, I started living in browser tabs. One for the four-node cluster in the office cupboard, one for the standalone box I was building for the house, one for the backup server. Checking “is everything healthy?” meant three logins and a lot of alt-tabbing.
Proxmox Datacenter Manager gives you one read-only pane over all of it — but only bother if you run more than one cluster. For a single cluster the native Proxmox VE interface already does this job, and PDM would just be a second thing to host and lock down. This guide is the two-clusters-and-up case: how I stood PDM 1.1 up in a container, connected my clusters with tokens that can only look, and the few rough edges I hit doing it.
Every address, hostname, and name below is an example. Swap in your own before you run anything: 10.0.0.x is a stand-in for your real subnet, pve-node1.homelab.lan and pbs.homelab.lan for your real hostnames, office-cluster for whatever you want to call each remote, and any CHANGE_ME / token value for a secret you keep in your own password store, never pasted into a note. Rule of thumb: if a value looks specific to one machine, it’s a placeholder to change — not a literal to copy.
What PDM actually is (and isn’t)
A Proxmox VE cluster fuses several nodes into one system: they share config and can shuffle guests between each other. PDM is a layer above that. It doesn’t join anything and it isn’t a cluster member — it’s a small standalone service that connects to your clusters and lone nodes as remotes and aggregates them into one screen. Each remote stays fully independent and hands PDM nothing but an API token.
That distinction is the whole security story. Because a remote only trusts a token, you decide exactly how much that token can do, and for a monitoring pane the answer is “read, and nothing else.”
Standing PDM up in a container
Proxmox ships PDM as an installable ISO or as Debian packages. Since everything else in my lab is an LXC container, I took the Debian route: a plain Debian 13 (“trixie”) container, then the packages on top. Give it modest resources; mine runs comfortably in 2 vCPU and 2 GB of RAM.
Inside the container, add the no-subscription repository and install the manager. The signing key and the exact repository line come straight from the official PDM installation docs:
# fetch the Proxmox signing key for trixie
wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
-O /usr/share/keyrings/proxmox-archive-keyring.gpg
# add the no-subscription repo (deb822 format)
cat > /etc/apt/sources.list.d/proxmox.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pdm
Suites: trixie
Components: pdm-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
apt update
apt install proxmox-datacenter-manager-container-meta
That pulls in two services (proxmox-datacenter-api and its privileged helper), and the web interface comes up on port 8443. Point a browser at https://<your-pdm-ip>:8443, log in as root@pam with the container’s root password, and you get the login screen every Proxmox admin will recognise:
PDM keeps its own users. The root@pam you log in with here is the container’s root account, not any account on the clusters you’re about to connect. Those get their own tokens, coming up next.
Connecting a cluster so it can only look
This is the part worth slowing down for. On each cluster you want to watch, create a dedicated user and a read-only token rather than handing PDM a real admin login. Proxmox VE has a built-in role called PVEAuditor that grants read access and nothing else — the same role I lean on when turning a hand-built cluster into code, and for the same reason: a credential that physically cannot delete a guest turns a whole category of mistakes into a harmless error.
On one node of the cluster:
# a dedicated user, then a read-only role for it on the whole tree
pveum user add pdm@pve
pveum acl modify / -user pdm@pve -role PVEAuditor
# a token for that user; --privsep 0 lets the token inherit the user's role
pveum user token add pdm@pve pdm --privsep 0
That last command prints a secret value once, so copy it into your password manager immediately; Proxmox will never show it again. On a Proxmox Backup Server the shape is identical, only the tool and role names change (Audit is PBS’s read-only role):
proxmox-backup-manager user create pdm@pbs
proxmox-backup-manager user generate-token pdm@pbs pdm
proxmox-backup-manager acl update / Audit --auth-id 'pdm@pbs!pdm'
Back in PDM, open Remotes → Add → Proxmox VE. The wizard’s first step, “Probe Remote,” asks for the server address and a certificate fingerprint:
Type the node’s address (https://pve-node1.homelab.lan:8006), let PDM fetch and show you the certificate fingerprint, then paste the token ID (pdm@pve!pdm) and the secret on the Settings step. I automated mine from the container’s admin CLI so I could rebuild it from a script — the same call the wizard makes under the hood:
proxmox-datacenter-manager-admin remote add \
--type pve --id office-cluster \
--authid 'pdm@pve!pdm' --token 'CHANGE_ME_token_secret' \
--nodes 'pve-node1.homelab.lan,fingerprint=AB:CD:EF:...'
Do the same with --type pbs for the backup server, and both show up in the remotes list, each with its audit token and pinned node:
Why the fingerprint step matters
Proxmox nodes use self-signed certificates by default, so there’s no public authority vouching for them. When you accept the fingerprint in that wizard, PDM pins it: from then on it will only talk to a node presenting that exact certificate. If the certificate ever changes without you re-approving it — a reinstall, or something malicious sitting in the middle — the connection breaks instead of trusting the impostor. Those pinned fingerprints live in /etc/proxmox-datacenter-manager/remotes.cfg, which also holds the token secrets, so treat that file as a secret in its own right.
The single pane — and the one tile that stays amber
With both remotes connected, the dashboard finally does what I wanted: every node, guest, and datastore across separate clusters on one screen, with aggregated CPU, memory, and storage gauges.
Notice the “Remotes” tile isn’t all green. That isn’t a deployment mistake; it’s the read-only choice showing its edges, which brings me to the rough parts.
Three rough edges, and which to ignore
None of these stopped the deploy. Two are non-issues you should expect; one is a real limitation to plan around.
A 403 in the log every cycle: ignore it. PDM keeps trying to fetch each node’s available-updates list, and reading that needs the Sys.Modify privilege. Your audit token doesn’t have it, so you get a benign 403 per node per cycle. That’s the least-privilege bargain working as intended, not a fault. If you genuinely want update visibility in the pane, grant Sys.Modify later, on purpose.
A read-only remote can’t populate every tile: expect it. On my Backup Server remote, PDM’s own resource-collection call comes back 403: permission check failed, so the backup node reads as offline in the dashboard even though the connection itself is fine (the CLI happily reports its version). A pure audit token is enough to register and reach a PBS, but some of the richer status views want a broader read scope than the base Audit role grants. Decide per remote whether you’d rather see the extra detail or keep the tighter token.
The 1.1.7 client CLI won’t do password-file auth: work around it. There’s a separate proxmox-datacenter-manager-client binary, and in 1.1.7 it rejects --user root@pam --password-file as unauthorized even when the exact same credentials succeed against the raw API. The web UI, the admin CLI, and the API are all fine, so don’t burn an afternoon on it like I nearly did; just use one of those instead.
If you later want PDM 1.1’s cross-cluster VM migration, remember these tokens can’t do it — migration writes to both clusters. Re-scope the tokens for that job specifically, rather than handing PDM standing write access it doesn’t need the rest of the time.
Tearing it back down
Because PDM joins nothing, removing it is clean: delete the remotes (or just destroy the container), then delete the pdm@pve and pdm@pbs users and their tokens on each cluster. Nothing on the clusters themselves depended on it, and that independence is the same reason it was safe to point at production in the first place.
For a single cluster, I’d still tell you to skip it. But the day you’re logging into three Proxmox tabs to answer “is everything up?”, PDM is the fix, and now you can stand it up in an afternoon with credentials that can’t hurt you.
Related posts:
- Building a 4-Node Proxmox Cluster on HP EliteDesk Mini PCs — the kind of cluster that becomes remote number one in PDM
- Turn a Hand-Built Proxmox Cluster Into Code Without Breaking It — where I first leaned on the PVEAuditor read-only role
- Proxmox Backup Server: Automated CT and VM Backups — the PBS that becomes a read-only remote here
- Proxmox Security Hardening: SSH Keys, Firewall, and Locking Down a New Cluster — the least-privilege posture this guide extends to tokens
- Proxmox Monitoring with Prometheus and Grafana — the metrics pane PDM complements rather than replaces
- The Complete Proxmox Homelab Guide (2026) — the starting point if you’re not yet at “more than one cluster”
Sources: Proxmox Datacenter Manager Documentation, PDM Installation Guide, Proxmox VE User Management — API Tokens and PVEAuditor, Proxmox Backup Server Documentation.
Comments
Comments are powered by GitHub Discussions — sign in with a GitHub account to join the conversation.