Proxmox Datacenter Manager 1.1: Multi-Node Visibility Without A Mega-Cluster
Tech GuruQuick Answer
Use Proxmox Datacenter Manager for a shared view of independent remotes, not as a substitute for cluster design. Start with two noncritical nodes, record their credentials and permissions, and compare PDM's guest, snapshot, task, and storage views with each node. Test loss or removal of a remote registration while retaining direct node access. PDM alone does not supply quorum, shared storage, or guaranteed high availability.
Evidence status: PDM 1.1's central guest/snapshot management and Ceph monitoring are documentation-backed. No two-node enrollment, permission-denial, snapshot, or remote-removal results are supplied. The workflow below is an evaluation plan.
What To Check
The PDM 1.1 announcement describes cross-remote guest views, snapshot operations, and unified Ceph monitoring. Those are management capabilities. They do not demonstrate that an unclustered pair of hosts can take over each other's workloads.
Evaluate the specific work you want to centralize: locating a guest, reviewing a task, checking a snapshot, or inspecting a Ceph cluster. Keep a list of operations still performed at the remote. This gives the trial a useful result even when the answer is to keep a particular task node-local.
Key Concepts In Plain Language
- Remote: A Proxmox endpoint registered with PDM; the management view does not itself merge its cluster or storage design with another endpoint.
- Visibility versus authority: Seeing a guest is different from having permission to change it. Test both the allowed action and a denied action.
- Independent recovery: Direct access and recovery records for a remote that remain available when PDM cannot reach it.
Technical Checklist
- Add two independent Proxmox nodes as separate remotes and document certificates, credentials, role assignments, and API reachability.
- Compare node, guest, storage, snapshot, task, and Ceph visibility without describing those views as shared-storage or HA capability.
- Remove and re-add a remote to prove that PDM loss does not alter the independent node's workload state.
- Document which lifecycle actions remain node-local and which PDM operations require additional permissions or product support.
Interactive Operating Model
Use the detailed runbook and acceptance checks below with this overview. No test result is implied by the diagram.
Before You Start: Safe Defaults
Use two recoverable, noncritical remotes and keep direct login paths to both. Save PDM and remote configuration, certificate information, and credential/role assignments. Select a disposable guest for lifecycle and snapshot work so the trial does not endanger an unrelated workload.
- Confirm the exact installed release, edition, repository, firmware, and add-on state instead of relying on the dashboard label alone.
- Export configuration and protect application data, credentials, certificates, and encryption material separately.
- Stage on a clone, spare node, canary device, or least-critical workload whenever the platform allows it.
- Define stop conditions and console access before the maintenance window begins.
Go, Hold, Recover, Or Escalate
Proceed only when each remote can be administered without PDM and its permissions are understood. Hold central write operations if an API credential's scope or certificate identity is unclear.
Planned Checks And Recovery
Step 1: Record each remote independently
List the node or cluster identity, versions, guests, storage, existing HA arrangement, API reachability, and certificate details. Capture the node-local state before enrollment so the central view has something concrete to compare against.
Step 2: Add two remotes and test permissions
Register the selected endpoints through the supported PDM workflow. Compare the displayed identity and inventory with the local records. Test one permitted operation and one operation the assigned role should deny. Do not broaden credentials just to make every control succeed.
Step 3: Exercise guest and snapshot operations
Use the disposable guest to compare task results and snapshot state in PDM and on the remote. Record the operation, permission, storage context, and result. Verify snapshot recovery separately; a visible snapshot entry is not proof of a successful restore.
Step 4: Check Ceph only where it exists
For a remote with Ceph, compare the central health, capacity, and component view with the cluster's own view. If neither test remote uses Ceph, record that part of the trial as untested. Do not add storage or invent a health result simply to fill the checklist.
Step 5: Remove the registration and verify independence
Remove only the test remote's PDM registration, not the node, cluster membership, guest, or storage. Observe workload state and direct administration, then re-add the remote through the supported workflow. Record stale displays, task failures, and recovery behavior instead of assuming PDM loss is harmless.
Validation Checklist
- Both remote identities and inventories match node-local records; certificate and permission decisions are documented.
- A permitted operation succeeds and a restricted operation is denied without exposing broader management access.
- Snapshot and applicable Ceph results are compared with their source remote; unavailable coverage is explicitly untested.
- Remote-registration removal/re-addition leaves an observed workload and management result, and connectivity alerts reach the operator.
Troubleshooting
- A guest appears but an action fails: Compare the role, API credential, remote task log, and operation support before changing permissions.
- Central and local storage views disagree: Confirm the remote identity and freshness of each observation; inspect the storage system locally.
- A remote disappears: Test direct node access and API reachability before treating the display as a workload outage.
Security, Privacy, Legal, And Recovery Boundaries
Security
Use official packages and release guidance, preserve signing and authentication controls, and do not expose a management plane to simplify migration.
Privacy
Configuration exports and support bundles may contain names, addresses, tokens, certificates, device identifiers, and user data; encrypt and restrict them.
Legal
Review software licenses, support entitlements, and retention obligations before copying production data into a test environment.
Recovery
A rollback is credible only when its media, configuration, keys, data, boot path, and restore order are available outside the system being changed.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
No enrollment or removal trial is reported here. Management visibility does not validate shared-storage health, migration compatibility, cluster quorum, or HA recovery. A test on two remotes would not establish permissions or behavior on every other remote, and Ceph coverage remains separate from guest-operation coverage.
Related TechGeeks Resources
- Linux and Homelab Notes: Start Here
- Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests
- How Do You Document a Homelab So Someone Else Can Recover It?
References
Next Action
Adopt PDM for the operations the trial actually validates. Keep node-local recovery instructions and label everything the central view does not provide.
