Proxmox Datacenter Manager 1.1: What Changes Beyond One Cluster
PDM 1.1 adds automated host installation, subscription handling, Ceph monitoring and expanded guest management. Here is what that means for multi-cluster operations.
One Proxmox cluster can be managed as a platform. The operating picture changes when a second cluster, backup server or site appears.
At that point, the difficult questions are rarely about whether an administrator can open another browser tab. They are about whether the team can see the same information, apply the same standards and assign clear ownership across every location.
Proxmox Datacenter Manager 1.1, released on 28 May 2026, is an important step in that direction. The release adds automated installation workflows, centralized subscription handling, unified Ceph monitoring and expanded guest and snapshot management.
What PDM 1.1 adds
Centralized automated installation
PDM 1.1 can act as the configuration server for unattended Proxmox installations. Administrators can maintain answer-file configurations centrally, serve the correct installation parameters to new hosts and track installation progress from the PDM interface.
The workflow also uses dedicated authentication tokens, and a prepared answer can carry an optional Proxmox subscription key. This gives infrastructure teams a practical way to make host builds more repeatable across locations.
The useful question is not only, "Can we automate the installation?" It is, "Which build standard should every new host receive?"
That standard should define at least:
- Host naming and site conventions
- Network, DNS and time configuration
- Storage and cluster role
- Subscription assignment
- Update channel and ownership
- Post-install validation
Automation makes a standard repeatable. It does not decide the standard for you.
A central subscription registry
The new subscription registry keeps a central pool of Proxmox VE and Proxmox Backup Server subscription keys. Administrators can assign keys to remote nodes, clear assignments and review node subscription status from one place.
This is a small operational detail until several clusters and backup servers are involved. Then it becomes part of asset control. The registry can reduce manual key handling, but the team still needs an owner for renewals, entitlement reviews and changes to the node estate.
One view of Ceph health and capacity
PDM 1.1 collects Ceph clusters from connected hyper-converged Proxmox VE remotes into a central view. Operators can review health, raw capacity, available capacity, service state, OSD status, pools, CephFS and relevant cluster flags without opening each cluster separately.
The current Ceph integration is read-only. It is designed for visibility and triage. Changes still take place in the native Proxmox VE interface.
That boundary is useful. Central visibility can show where attention is needed, while local management keeps destructive storage actions close to the cluster being changed. It also means the operating process should define who responds to a Ceph warning, how it is escalated and when a storage change is approved.
Expanded guest and snapshot operations
PDM provides a cross-remote view of QEMU virtual machines and LXC containers. Teams can filter and sort guests, perform common lifecycle actions and manage snapshots from the central interface.
This helps when a guest name, owner or location is not immediately known. It also makes naming discipline more important. A central inventory is far more useful when workload names, tags, service owners and environments are consistent across sites.
Visibility is not the same as an operating model
PDM 1.1 brings more of the distributed estate into one interface. That is valuable, but a dashboard cannot settle every operational decision.
Before the second or third cluster becomes routine, teams should agree on:
- Who owns the host and cluster build standard
- How networks, storage and naming are kept consistent
- Which roles can view, operate and change each remote
- How updates are reviewed, tested and scheduled
- How backup jobs and restore tests are checked
- What triggers a capacity review
- Who responds to failed tasks or Ceph health warnings
- Where runbooks and change records are maintained
Without these decisions, central management can become a cleaner view of inconsistent infrastructure.
Treat Proxmox as an infrastructure stack
Distributed Proxmox operations are not only a PDM question. The management layer sits above Proxmox VE, storage, network design, Proxmox Backup Server, identity, monitoring and the team responsible for day-two work.
A practical multi-site design therefore needs to consider the complete stack:
- Proxmox VE cluster design and workload placement
- Ceph, ZFS or external storage architecture
- Proxmox Backup Server placement, retention and verification
- Network conventions and inter-site connectivity
- Identity, roles and administrative access
- Monitoring, updates and incident ownership
- Documentation and recovery procedures
PDM is most useful when those layers already follow a shared operating model, or when the organization is ready to create one.
The next review to run
If your Proxmox estate is moving beyond one cluster, start with an operating review before adding more management tooling.
Map every cluster, node, datastore, backup server and site. Record the owner, version, update status, capacity position, backup relationship and escalation path for each one. The gaps in that map will usually show where the operating model needs work.
Computer Port IT Solutions is a Proxmox Silver Partner. We help organizations design and operate Proxmox VE, Proxmox Backup Server, Ceph or ZFS storage, networking, monitoring and multi-cluster management as one infrastructure stack.
Discuss your Proxmox infrastructure requirements.