Proxmox Datacenter Manager 1.1 Automated Host Provisioning

Proxmox Datacenter Manager 1.1 ships two features that make it worth running alongside a production cluster: automated bare-metal node installation driven entirely from the web UI, and a unified Ceph monitoring panel that aggregates OSD and pool health across every registered node. If you tested the alpha build and shelved it because it was read-only, version 1.1 is the release to revisit. By the end of this walkthrough you will have PDM 1.1 running, a PXE-based provisioning workflow configured, and Ceph data from all your nodes surfaced in one place.

Key Takeaways

• Automated provisioning: PDM 1.1 PXE-boots and installs Proxmox VE 9.1 on bare-metal hardware from the dashboard — no manual ISO required.
• Unified Ceph view: OSD status, pool utilization, and cluster health for every managed node appear in a single PDM panel.
• Answer-file driven: Provisioning uses the same answer-file format as proxmox-auto-install-assistant, so existing templates migrate directly.
• Standalone deployment: PDM runs as a VM or LXC outside the clusters it manages, keeping it available even when a managed cluster has quorum issues.
• Free to use: PDM is AGPL-3.0 open-source and available from the Proxmox no-subscription repository.

What Changed Between PDM Alpha and 1.1

The alpha gave you a read-only inventory view and basic task scheduling. Genuinely useful for auditing a multi-node estate — you could see what existed across all your nodes without opening six browser tabs — but it could not touch infrastructure.

PDM 1.1 adds three substantive capabilities:

• Host installation jobs: A wizard-driven workflow that defines a target host, selects a Proxmox VE ISO, generates and serves an answer file, and tracks installation progress in real time.
• Ceph monitoring integration: Any cluster registered with PDM now exposes Ceph health status, OSD tree, pool statistics, and throughput graphs directly inside the PDM interface — no separate Ceph Dashboard login.
• API-token node registration: Nodes can be added via Proxmox API tokens instead of root credentials, which fits the security posture most shops already use for Terraform and Ansible.

What is still missing: live migration management, VM-level provisioning wizards, and billing or chargeback modules. PDM is infrastructure management, not cloud orchestration. If you need those things, you are still looking at OpenStack or a commercial overlay.

How to Install or Upgrade to PDM 1.1

PDM ships in the same repository infrastructure as Proxmox Backup Server and Proxmox Mail Gateway. If you are coming from the alpha or 1.0, an in-place upgrade works cleanly. For a fresh install, run PDM as a Debian 12 VM or LXC on one of your existing nodes — ideally not inside the cluster it will manage, so PDM stays available during cluster maintenance.

Fresh Install on Debian 12

# Add the Proxmox no-subscription repo for PDM on Debian 12 (Bookworm)
echo "deb [arch=amd64] http://download.proxmox.com/debian/pdm bookworm pdm-no-subscription" \
  > /etc/apt/sources.list.d/pdm.list

# Import the Proxmox signing key
wget -qO- https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg \
  | tee /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg > /dev/null

apt update && apt install -y proxmox-datacenter-manager
systemctl enable --now pdm-daemon pdm-proxy

The web UI is reachable on port 8443 about 15 seconds after the service starts. Log in with root@pam and the system root password.

Upgrading from Alpha or PDM 1.0

apt update && apt full-upgrade
systemctl restart pdm-daemon pdm-proxy

Use full-upgrade, not upgrade. PDM 1.1 replaces several package names from the alpha series, and plain upgrade will hold the old packages back rather than transitioning. The full upgrade completes in under two minutes on a minimal VM.

If apt throws a conflict on pdm-alpha, purge it first:

dpkg --purge pdm-alpha
apt install -y proxmox-datacenter-manager

Firewall Rules for the PDM Host

PDM needs outbound HTTPS to each Proxmox node's API on port 8006, inbound port 8443 for your browser, and — if you use PXE provisioning — TFTP (UDP 69) and HTTP (TCP 80) reachable from the provisioning VLAN.

# ufw rules on the PDM host
ufw allow 8443/tcp comment "PDM web UI"
ufw allow 69/udp  comment "TFTP for PXE boot"
ufw allow 80/tcp  comment "HTTP for answer-file serving"

Registering Your Proxmox Clusters in PDM

Each Proxmox cluster appears in PDM as a "Remote." You need a Proxmox API token with at minimum the PVEAuditor role for read-only monitoring, or Administrator if you want PDM to execute provisioning tasks.

# On any Proxmox node in the target cluster — create a dedicated PDM service account
pveum user add pdm-service@pve --comment "Proxmox Datacenter Manager"
pveum acl modify / --users pdm-service@pve --roles Administrator

# Generate a token — copy the secret immediately, it is shown only once
pveum user token add pdm-service@pve monitoring --privsep 0

In the PDM web UI:

1. Navigate to Remotes → Add
2. Enter the cluster VIP or any node's IP with port 8006
3. Paste the token string in the format pdm-service@pve!monitoring=<secret>
4. Click Test Connection, then Save

PDM polls the remote every 60 seconds. All nodes, VMs, and containers populate within the first poll cycle.

Setting Up Automated Host Provisioning

This is the headline feature. PDM 1.1 can install Proxmox VE 9.1 on a bare-metal machine from scratch using PXE boot and a generated answer file. The answer-file format is identical to what proxmox-auto-install-assistant produces, so if you already have templates from that tool, they transfer directly — PDM just adds a UI and a built-in HTTP server to serve them dynamically.

Prerequisites

• A DHCP server that supports setting next-server (the TFTP server IP) to the PDM host.
• Target machines configured for PXE boot in BIOS or UEFI.
• A Proxmox VE 9.1 ISO uploaded to PDM via ISOs → Upload (or accessible via URL).
• No IP conflicts between your DHCP lease range and the static IP you plan to assign the new node.

Creating a Provisioning Job

Navigate to Provisioning → New Job and fill in the wizard:

Field	Example Value
Target hostname	pve-node-04.lab.internal
Static IP address	192.168.10.24/24
Gateway	192.168.10.1
DNS server	192.168.10.1
Primary storage disk	/dev/nvme0n1
Filesystem	ZFS RAID-1 (if two drives detected)
Post-install cluster join	Select from registered remotes

PDM generates the answer file, serves it over HTTP to the PXE-booted target, and streams installation progress in real time. On NVMe-to-NVMe hardware, expect the full install — from PXE boot to a reachable Proxmox node — to complete in 4 to 6 minutes. After installation, PDM can optionally execute the pvecm add join automatically.

The gotcha to watch for: if your DHCP pool includes the static IP defined in the answer file and hands it out as a lease during the PXE boot phase, the first-boot network configuration will fail silently and the node will come up with a DHCP address instead of its intended static one. Add the target IP to your DHCP exclusion range before starting the job.

Verifying Provisioning Job Logs

# On the PDM host — stream daemon logs
journalctl -u pdm-daemon -f --since "1 hour ago"

# Pull job status via the REST API
curl -sk \
  -H "Authorization: PVEAPIToken=root@pam!admin=<secret>" \
  https://localhost:8443/api2/json/provisioning/jobs \
  | jq '.data[] | {id: .id, state: .state, node: .node, started: .starttime}'

Monitoring Ceph Across the Cluster from PDM

Once your Proxmox cluster remote is registered and it runs Ceph, PDM 1.1 surfaces a Ceph panel without any additional configuration. Navigate to Remotes → [your-cluster] → Ceph.

You will see:

• Health status — HEALTH_OK, HEALTH_WARN, or HEALTH_ERR with the full detail string (e.g., 1 slow ops, 1 MDSs report slow requests)
• OSD tree — each OSD listed with its host, up/in status, and raw capacity
• Pool list — utilization percentage, PG count, and replication factor
• Throughput graphs — read/write IOPS and bandwidth over the past hour

This is monitoring, not management. You cannot create pools, adjust CRUSH rules, or reweight OSDs from PDM 1.1. For anything beyond read-only visibility you still need to SSH into the node or use the Proxmox VE Ceph Dashboard directly. If you are running a hyper-converged setup as described in building a software-defined datacenter with Proxmox VE, PDM's Ceph view is a meaningful quality-of-life improvement — one pane of glass instead of per-node tabs.

Integrating PDM with Your Automation Stack

Every action available in the PDM UI has a corresponding REST API endpoint under https://<pdm-host>:8443/api2/json/. Here is a quick example — listing all nodes across all registered remotes:

curl -sk \
  -H "Authorization: PVEAPIToken=root@pam!admin=<secret>" \
  https://pdm.lab.internal:8443/api2/json/remotes \
  | jq '.data[].id' \
  | xargs -I{} curl -sk \
      -H "Authorization: PVEAPIToken=root@pam!admin=<secret>" \
      "https://pdm.lab.internal:8443/api2/json/remotes/{}/nodes" \
  | jq '[.data[] | {node: .node, status: .status, uptime: .uptime}]'

For Ansible users, you can trigger PDM provisioning jobs via uri tasks and poll for completion in a loop — no custom module required. This complements existing Proxmox Ansible VM playbooks cleanly: Ansible handles guest-level configuration once the node exists; PDM handles getting the node onto the network in the first place.

The API is also useful for inventory: a short cron job that queries PDM and writes a dynamic Ansible inventory file means you never manually update host lists when you add a node.

When PDM 1.1 Is Worth Deploying

PDM is the right tool when:

• You manage three or more Proxmox nodes and the friction of opening individual UIs or SSH sessions is real.
• You provision new nodes more than occasionally — one-off installs don't justify standing up a PXE environment.
• You run Ceph in production and want health aggregated without a separate Grafana stack.
• You want API-token scoped access to your cluster inventory for CI pipelines without granting root SSH.

It is overkill for a single three-node homelab where you know every VM by name and add hardware twice a year. In that scenario — whether you are building a private cloud at home or running a scrappy single-node setup — the overhead of maintaining a separate PDM instance outweighs the benefit. Stick with direct node access and answer files for occasional installs.

Common PDM 1.1 Issues and Fixes

Nodes show as unreachable after upgrading from the alpha: The alpha used a different authentication header format. Delete each remote and re-add it — saved credentials from alpha builds are not automatically migrated to 1.1.

PXE boot starts but installer hangs at "Loading answer file": The installer fetches the answer file over plain HTTP on port 80 at boot time. Confirm the PDM host firewall allows inbound TCP 80 from the provisioning network segment.

Ceph panel shows "no data" on a healthy cluster: The API token used for the remote needs the PVEAuditor role applied at the root path (/), not scoped to a specific node. Ceph data is exposed at the cluster API level and scoped tokens miss it.

apt full-upgrade fails with package conflict: The transition from pdm-alpha package names occasionally leaves stale dpkg state. Run dpkg --purge pdm-alpha && apt install -y proxmox-datacenter-manager to resolve it cleanly.

Provisioning job completes but node does not join the cluster: Check the pvecm add output in the PDM job log — the most common cause is a hostname that does not resolve from the existing cluster nodes. Add a DNS record or /etc/hosts entry on all existing nodes before triggering the join.

Conclusion

PDM 1.1 moves from interesting tech preview to genuinely useful infrastructure tool. Automated provisioning covers the 90% case — bootstrapping a new node into an existing cluster — without custom scripting or a full PXE infrastructure team. The unified Ceph view alone eliminates enough tab-switching to justify the install if you run a hyper-converged setup. Register your existing cluster as a remote first, spend ten minutes with the Ceph panel to validate the data, and then evaluate whether the PXE provisioning workflow fits your hardware refresh cadence before building out the DHCP side.