The question comes up in every VMware exit conversation, usually within the first ten minutes: does Proxmox have a vCenter? Until the end of 2025 the honest answer was no. Proxmox Datacenter Manager reached its first stable release in December 2025 and its second point release in May 2026, so the answer is now a qualified yes.
The qualification is the whole point. PDM solves a specific problem well and deliberately leaves several others alone, and the boundary between the two is exactly what you need before you commit to a migration plan. This guide covers what PDM does, what it does not, where to run it, and how to attach your first cluster.
Before you start
- Proxmox Datacenter Manager 1.1, based on Debian 13 "Trixie". Earlier 1.0 installations upgrade in place through apt.
- Remotes must run at least Proxmox VE 8.4 or Proxmox Backup Server 3.4.
- A host or VM for PDM. Official minimums are 4 GiB of RAM and more than 10 GB of disk, and those are evaluation figures, not production ones.
- Network reachability from PDM to every node you intend to manage, and about thirty minutes.
What Proxmox Datacenter Manager actually is
PDM is a separate appliance that connects to independent Proxmox VE clusters and Proxmox Backup Server instances and presents them in one interface. Each connected environment is called a remote. The appliance holds no workloads of its own; it holds credentials, collects metrics, and issues API calls.
The web interface listens on HTTPS port 8443, deliberately different from Proxmox VE's 8006 and PBS's 8007, so all three can coexist without confusion. The whole stack is written in Rust, with a WebAssembly front end, and the backend reuses the API framework from Proxmox Backup Server.
What you get from a single pane: an aggregated view of nodes, guests and storage across every remote; a central panel listing available updates across the whole estate, with the ability to apply them without leaving the interface; shell access to any managed remote; and guest migration between remotes that do not share a cluster network. That last capability is the one that changes architecture decisions, because it decouples "clusters I can move a VM between" from "clusters that share a Corosync ring".
Five things it is not
It is not a cluster. Adding two Proxmox VE clusters as remotes does not merge them. Quorum, high availability, fencing and the shared configuration filesystem all remain strictly per-cluster. PDM gives you a view across the boundary; it does not move the boundary.
It is not a dependency. This is the reassuring part, and the documentation states it plainly: no managed remote or resource depends on PDM to run. If the appliance is down, every cluster keeps serving workloads exactly as before. What you lose is visibility and central control, not availability.
It is not a replacement for the per-cluster interface. PDM handles overview and common operations; for anything deeper it gives you a link straight to the remote's own web UI. In practice you will keep both open, and that is the intended design rather than a gap.
It is not a monitoring and alerting stack. You get live metrics and recent history, which answers "what is happening now". Long-term retention, thresholds, alert routing and on-call escalation are a different job, and Prometheus, Zabbix or the equivalent still do it.
It is not version-agnostic. Remotes below Proxmox VE 8.4 or Proxmox Backup Server 3.4 are out of scope. If part of your estate is still on Proxmox VE 7, PDM is a reason to plan those upgrades, not a way to avoid them.
Where to run it, and where not to
The rule is short: do not run PDM on a cluster that PDM manages.
The reasoning is not availability, since we have just established that no remote depends on it. The reasoning is diagnosis. The moment you most want a cross-cluster view is the moment a cluster is misbehaving, and that is exactly when a PDM instance hosted on that cluster becomes unreachable. You end up troubleshooting blind, with the tool that was supposed to help you sitting inside the problem.
Reasonable placements, in order: a small dedicated physical host; a VM on a separate management cluster; a VM on a single standalone Proxmox VE node kept outside the managed estate. The appliance is light enough that a modest host is sufficient.
On sizing, treat the official 4 GiB minimum as what it says it is: an evaluation figure. For a real estate, 8 GiB of RAM, 4 vCPUs and 80 GB of disk is a comfortable starting point, and the appliance stores metrics history, so disk grows with the number of remotes and the retention you keep.
Deploying it as a virtual machine
Upload the PDM ISO to a storage that accepts ISO images, then create the VM. From the shell of the Proxmox VE node that will host it:
qm create 900 \ --name pdm \ --memory 8192 \ --cores 4 \ --ostype l26 \ --scsihw virtio-scsi-single \ --scsi0 local-lvm:80 \ --net0 virtio,bridge=vmbr0 \ --ide2 local:iso/proxmox-datacenter-manager.iso,media=cdrom \ --boot 'order=ide2;scsi0'
Adjust the ISO filename to match what you uploaded, and the storage identifiers to match your setup. Then start it and open the console:
qm start 900
The installer is the familiar Proxmox one: licence, target disk and filesystem, locale and timezone, root password and notification address, then network. Two points on that last screen are worth care.
Give PDM a static address and a resolvable FQDN. It is a management endpoint that other things will point at, and a DHCP lease that moves is an avoidable outage of your own visibility. And leave "pin network interface names" enabled, so interface naming survives reboots.
Once it reboots, confirm it is answering before you open a browser:
curl -sk -o /dev/null -w "%{http_code}\n" https://pdm.example.internal:8443/
A 200 means the API daemon is up. Then log in at the same address with the root account and the PAM realm.
Adding a cluster: the fingerprint and the token
PDM identifies a remote by the SHA-256 fingerprint of its TLS certificate. Since Proxmox VE ships a self-signed certificate by default, this is what prevents PDM from happily connecting to something that merely answers on the right address.
Read the fingerprint on the Proxmox VE node itself rather than trusting what a wizard shows you:
pvenode cert info
Or, vendor-neutrally, from any machine that can reach the node:
openssl s_client -connect pve-node1.example.internal:8006 </dev/null 2>/dev/null \ | openssl x509 -fingerprint -sha256 -noout
In PDM, go to Configuration, then Remotes, then Add, and choose Proxmox VE. The wizard first probes the address and asks for that fingerprint. Compare it against what you read above; if they differ, stop and find out why before proceeding.
The next screen offers two authentication modes. "Login and create token" takes a username and password once, then creates an API token on the remote and uses that token from then on. "Use existing token" takes a token you created yourself in Proxmox VE.
Prefer a token in both cases, and prefer creating it yourself for anything that matters. A token created by hand can be scoped to a dedicated user with only the privileges PDM needs, it appears under a name you chose in the remote's own audit trail, and it can be revoked without touching the root account. Letting the wizard use root and mint its own token is convenient and appropriate for a lab; it is a broad grant for production.
Endpoints: add every node, not just one
The last step of the wizard asks for endpoints, and it is tempting to accept the single node you probed and move on. Do not.
An endpoint is an address PDM can use to reach the cluster. With one endpoint configured, PDM loses sight of the entire cluster when that one node reboots, even though the cluster itself is perfectly healthy and the other nodes would answer the same API calls. Adding all nodes lets PDM fail over between them.
Each endpoint carries its own fingerprint, because each node has its own certificate. Collect them the same way, one node at a time. It is five minutes of tedium that removes a class of false alarm.
After finishing, the remote appears with its aggregated dashboard: node and guest counts, host CPU, memory and storage usage, resources allocated to guests, and a tree of the datacenter's resources. Clicking a node gives its own metrics, its Proxmox VE version and kernel, and a button that opens the node's native web interface.
What 1.1 changed
Version 1.1 arrived in May 2026 on Debian 13.5, with Linux kernel 7.0 and ZFS 2.4, aligning the appliance with the rest of the current Proxmox family. The upgrade from 1.0 is an apt upgrade, not a reinstall.
The additions worth knowing about: an integrated automated installation workflow, which turns PDM into a provisioning server for new hosts using per-installation bearer tokens; subscription status handling across the estate; unified Ceph cluster monitoring, so hyperconverged clusters report their storage health into the same view; and broader central management of guests and snapshots across remotes.
The Ceph addition is the one that matters most for hyperconverged estates, because it removes a reason to keep a second tool open. If you are still deciding on cluster shape and capacity, that decision comes first: our guide to sizing a Ceph cluster for production covers the arithmetic.
Is it enough to replace vCenter for you?
That depends on which vCenter you are actually using.
If vCenter is your inventory, your update mechanism, your migration console and your single login across sites, PDM covers that ground. If you depend on DRS-style automated placement, vCenter's permission model applied uniformly across everything, or the ecosystem of third-party tools that integrate against the vCenter API, then PDM 1.1 does not replace those, and pretending otherwise turns a migration into a surprise.
The honest framing is that PDM removes the largest operational objection to Proxmox at scale, which was the absence of any cross-cluster view at all. It does not yet match a mature product that has had two decades of feature accretion. For most estates that is enough; for some it is not, and the way to find out is to inventory what you actually use rather than what is on the datasheet.
That inventory is the first thing we do in a VMware exit engagement, and the platform design that follows it is covered under private cloud and virtualisation.
What this guide does not cover
Installing PDM on an existing Debian system through the package repositories rather than the ISO, which is supported and sometimes preferable when you already have a host provisioning pipeline. The automated installation workflow introduced in 1.1, which deserves its own treatment. The privilege model and how to scope PDM users and API tokens properly, which is where a production deployment differs most from a lab one. And replacing the self-signed certificate with a proper one, whether from an internal authority or through the built-in ACME support.
If you are attaching remotes that are still on Proxmox VE 8.x, note that the 8 series reaches end of life on 31 August 2026. PDM will manage them until then, but the upgrade is the more urgent piece of work.
