Proxmox Datacenter Manager 1.1 Audit Inventory Pre-Install

Proxmox Datacenter Manager 1.1 is most useful before the first automation run, not after. A host inventory audit in 1.1 gives you a list of nodes, stale credentials, orphaned entries, and missed hosts, so you can add machines without pointing an installer at the wrong target. The concrete outcome is a small inventory packet: verified nodes, retired hosts, current login users, and a clean target list for the next install.

Key Takeaways

Inventory first: Datacenter Manager 1.1 should be read as an audit table before automation.
Orphans matter: Nodes shown as known may be stale entries from removed hosts.
Credentials age fast: SSH keys, API users, and role grants need a quick pass before install.
Missed hosts are normal: DHCP leases, spare nodes, and homelab boxes often stay outside Datacenter Manager.
Audit prevents wrong installs: A 10-minute check avoids installing onto a node that is offline, duplicate, or already owned.

Why Does Datacenter Manager 1.1 Work as a Pre-Install Audit?

Datacenter Manager 1.1 is often used to install hosts, but the inventory view is the more valuable part before automation. If you have already read Proxmox Datacenter Manager 1.1: Automated Host Install, you know the install side is fast. The missing part is the audit.

A good pre-install audit answers three questions:

Which hosts are currently known to Datacenter Manager?
Which hosts are reachable and still have valid credentials?
Which hosts are missing from the inventory but should be included?

The audit is not just a UI check. It should be paired with the live Proxmox API command so you can compare what Datacenter Manager remembers with what the running Proxmox host reports.

For network-side checks, the Proxmox VE 9.1 Network Audit Checklist Before New VMs pairs well with this inventory pass. If backup storage is in the inventory, treat PBS 4.2 S3 Backup Pre-Flight Checklist for Production as the storage half of the audit.

How to Turn Datacenter Manager 1.1 into a Host Inventory Audit

Start with the inventory table, not the install screen

Open Datacenter Manager 1.1 and look for the host inventory before starting any install job. You want to see host names, last known status, login users, and any stale entries. A host that appears in the inventory but is not reachable is not a clean host. It is a pending failure.

Use the Proxmox API command below to capture the live node list. This is the authority you compare against the Datacenter Manager inventory.

pvesh get /nodes --output-format json > nodes.json

Then compare the JSON output with the Datacenter Manager inventory. If a node appears in Datacenter Manager but not in nodes.json, it is either offline, removed, or stale.

A quick SSH probe on the current Proxmox node confirms that the host is still reachable and that the SSH key is valid.

ssh -o BatchMode=yes -o ConnectTimeout=5 root@$(hostname) 'pveversion' > ssh-check.txt

A 10-second SSH timeout is enough for an audit. If the probe fails, the node is either offline, the key is stale, or the host is not actually part of the cluster inventory.

Validate the node list against the running Proxmox host

Do not trust the Datacenter Manager inventory alone. The Proxmox API command below shows the current status of the node you are running it on.

pvesh get /nodes/$(hostname)/status --output-format json > node-status.json

This is useful because Datacenter Manager can show a node as known even when the node is no longer part of the live cluster. The API output tells you whether the node is online, what its current status is, and whether it is reachable through the Proxmox API.

If you are auditing multiple hosts, run the same check on each node where SSH keys are already trusted. The inventory is only clean when every known host can be verified from both the Datacenter Manager side and the running Proxmox host side.

Catch orphaned nodes

An orphaned node is a host that Datacenter Manager remembers but the live Proxmox inventory does not support. This usually happens when a node was removed, rebuilt, moved, or renamed.

Use the live node list as your baseline.

pvesh get /nodes --output-format json > nodes.json

If Datacenter Manager shows a host that is not in nodes.json, mark it as orphaned. Do not add it to an install target list. Do not let automation touch it until you confirm whether it should be removed from Datacenter Manager or restored to the live Proxmox inventory.

Orphaned nodes are common in homelabs. A retired spare node may stay in Datacenter Manager for weeks. The UI may show it as known, but the node may have no SSH key, no valid cluster membership, or no running Proxmox service. A 90-second timeout during automation is often the first sign that the host was never really ready.

Check stale credentials

Stale credentials are one of the most common causes of failed Datacenter Manager installs. A host can be reachable, but the user, role, or SSH key may be wrong.

Use these commands to collect the user and role inventory.

pveum user list > users.txt
pveum role list > roles.txt
pveum user permissions --user root@pam > root-permissions.txt

Look for users that are no longer needed, roles that are too broad, and login users that point to hosts that are no longer in the inventory. For automation, you want a small, clear credential set. A stale API user can be worse than a missing host because automation may still attempt the install and fail in a confusing way.

If the SSH probe fails, the problem may not be the host. It may be the key. A host can appear healthy in Datacenter Manager while the SSH key is missing, the user has no permission, or the node was rebuilt with a fresh key.

Confirm missed hosts

Missed hosts are the opposite problem. The host exists, but Datacenter Manager does not know it. This is common with spare nodes, temporary test hosts, or hosts that were added manually to Proxmox but never added to Datacenter Manager.

Use these commands to capture the live storage and container inventory for the current node.

pvesh get /nodes/$(hostname)/storage --output-format json > storage.json
pvesh get /nodes/$(hostname)/lxc --output-format json > lxc.json
pvesh get /nodes/$(hostname)/qemu --output-format json > qemu.json

If a host has containers, VMs, storage, and a valid SSH probe, but it is not in Datacenter Manager, it is a missed host. Add it to the audit list before automation. If it is not in Datacenter Manager, automation will not see it, and the install job will either skip it or target the wrong node.

What Does a Clean Pre-Install Inventory Look Like?

A clean inventory is not just a list of hosts. It is a list of verified hosts, retired hosts, missing hosts, and stale credentials. The file below is a practical audit format you can keep beside the JSON output.

cluster: homelab
source: proxmox-datacenter-manager-1.1
nodes:
  - name: pve1
    role: primary
    inventory: verified
    credentials: root@pam
    last_seen: 2026-02-14
    ssh_key: trusted
  - name: pve2
    role: spare
    inventory: orphaned
    credentials: root@pam
    last_seen: 2025-11-06
    ssh_key: missing
  - name: pve3
    role: test
    inventory: missed
    credentials: root@pam
    last_seen: 2026-02-12
    ssh_key: pending

A good audit packet should include the Datacenter Manager inventory, the live Proxmox API output, the user list, the role list, and the SSH probe results. A 12 MB inventory snapshot is small enough to keep with the install notes, but large enough to preserve the exact state before automation runs.

How to Spot Orphaned Nodes, Stale Credentials, and Missed Hosts

The audit works best when you compare different views of the same inventory. Datacenter Manager shows what you have recorded. The Proxmox API shows what is live. SSH shows what is reachable. User permissions show what automation can actually do.

Audit view	What it proves	What it can miss
Datacenter Manager inventory	Known hosts, last seen status, recorded credentials	Stale entries from removed hosts
Proxmox API node list	Live cluster membership	Network reachability from the UI
SSH probe	SSH key works, host is reachable	Wrong user, missing role, no SSH key
User and role list	Current login users and role grants	Actual key ownership or token state
Storage and container inventory	Host has real workloads and storage	Whether Datacenter Manager knows the host

Orphaned nodes are usually the easiest to spot. If Datacenter Manager shows a host but the live Proxmox API does not, the host is stale. If the live Proxmox API shows a host but Datacenter Manager does not, the host is missed. If both show the host but SSH fails, the credential is stale.

Stale credentials are harder to catch because they often look normal. A user list may show root@pam, and the host may appear online. But the SSH key may be missing, the user may have no permission, or the host may have been rebuilt with a different key. This is why a simple SSH probe is worth adding to the audit.

Missed hosts are usually discovered by accident. A spare node may have containers, storage, and a working SSH key, but it is not in Datacenter Manager. If automation runs before the host is added, the job will target the wrong inventory list. The host may be skipped, or a previously known host may be reused incorrectly.

What to Fix Before Datacenter Manager Runs an Install

Before you run an install, freeze the inventory. This is not a full production audit, but it is enough to prevent the most common automation mistakes.

Capture the live Proxmox node list.
Compare the Datacenter Manager inventory with the live node list.
Remove orphaned hosts from the automation target list.
Confirm stale credentials with user, role, and SSH checks.
Add missed hosts only after they are verified.
Save the audit output before starting the install.

Use the commands below to build the audit packet.

pvesh get /nodes --output-format json > nodes.json
pvesh get /nodes/$(hostname)/status --output-format json > node-status.json
pvesh get /nodes/$(hostname)/storage --output-format json > storage.json
ssh -o BatchMode=yes -o ConnectTimeout=5 root@$(hostname) 'pveversion' > ssh-check.txt
pveum user list > users.txt
pveum role list > roles.txt
pveum user permissions --user root@pam > root-permissions.txt

The result is a clear decision list. Each host is either verified, orphaned, missed, or stale. If a host is verified, it can be used for automation. If it is orphaned, remove it from the Datacenter Manager inventory. If it is missed, add it only after confirming SSH, storage, and user permissions. If credentials are stale, fix them before the install job runs.

Common Gotchas and Tradeoffs

I once left a retired pve2 node in Datacenter Manager for three weeks. The UI showed it as known, but the node had no SSH key. The install job waited through a 90-second timeout and then failed. The host was not broken. The inventory was stale.

That is the main gotcha: Datacenter Manager can remember a host even when the host is no longer valid. The inventory view is useful, but it is not a live guarantee. The Proxmox API, SSH probe, and user permissions are what prove the host is ready.

The tradeoff is time. A full audit adds about 10 minutes per batch. For a single homelab node, that can feel slow. For a cluster with several hosts, stale credentials, or a retired spare node, the audit prevents a wrong install target. The audit is not as fast as clicking install, but it is usually faster than debugging a failed automation run.

Another common issue is duplicate host names. Datacenter Manager may show a host by name, while the live Proxmox API shows a different node. If you rename a node, the inventory can become confusing. Use the live node list as the final source of truth for the audit.

Conclusion

Datacenter Manager 1.1 becomes more useful when you treat it as an inventory audit tool before automation. The concrete outcome is a clean target list: verified nodes, removed orphans, fixed stale credentials, and missed hosts added only after they are confirmed. Your next step is to capture the node list, user list, and SSH probe results before the next install run, then compare them against the Datacenter Manager inventory.