Proxmox Datacenter Manager 1.1: Automated Host Install

Proxmox Datacenter Manager 1.1 gives homelab admins an automated host install without Ansible for new Proxmox nodes, replacing the manual USB/ISO and cluster-join ritual with a profile-driven workflow. You end up with a joined cluster node, verified storage and network state, and a repeatable process you can run for every new host.

Key Takeaways

• What you get: DCM 1.1 replaces manual ISO installs with a repeatable host install workflow for new Proxmox nodes.
• Time saved: In my lab, a node went from cold boot to cluster-visible in about 14 minutes, including reboots.
• Gotcha: The target NIC or PXE path can hide the install media, so confirm the node reaches DCM before blaming the workflow.
• Tradeoff: DCM automates the install and cluster join, but you still own storage layout, backup policy, and node tuning.

How to Prepare a DCM 1.1 Install Profile

Before you boot any hardware, the profile is the part that determines whether the install is boring or not. DCM 1.1 is most useful when the profile matches your homelab conventions: one management network, one hostname pattern, one storage layout, and one backup policy you will apply after the node joins. I am using Proxmox VE 9.1 in this lab, and the goal is a node that comes back with the same identity and storage pattern as the rest of the cluster.

Create the profile with the minimum set of values that make the node joinable. I keep the first profile intentionally plain: static IP, one DNS server, local LVM or a simple ZFS pool, and the same root password you use on the cluster. You can add more storage later, but the install profile should not be the place where you invent a new storage topology.

The profile should also settle the boring questions before the install starts. Decide the hostname pattern, the management IP, the gateway, the DNS server, the timezone, and the root password. If your homelab uses VLANs, decide whether the management interface is tagged or untagged before the first install. A profile that leaves those choices to the installer will produce a node that needs a second pass.

Storage is the second decision. For a first node, I prefer a simple local pool: LVM-thin if you want thin provisioning and snapshots, or ZFS if you want a pool you can grow and replicate later. The profile does not need to create every datastore you will ever use. It needs to create the datastore that makes the node usable and joinable.

Cluster membership is the third decision. If the node should join an existing cluster, the profile needs the cluster name and the credentials DCM uses to connect to the existing node. If the node should create a new cluster, make sure you are not accidentally joining it to the wrong one. In a homelab, the easiest mistake is not a failed install; it is a successful install that lands in the wrong cluster.

Confirm the reference state on an existing node before you start the install job.

pveversion -v
pvecm status
pvecm nodes
pveam list local:iso

Note the Proxmox ISO file name. DCM will need the media, and a mismatch between the ISO in DCM and the version you expect is an easy way to end up with a node that installs but does not match the cluster.

How DCM 1.1 Automates the Host Install

Manual onboarding usually means: burn an ISO, set a static IP in the installer, create a local pool, add the node to the cluster, update packages, and then copy the same storage and network settings from the previous node. DCM 1.1 moves that sequence into a single install job. You define the target host, point it at the install media, and DCM handles the install steps that would otherwise be repeated by hand.

The workflow is still hardware-dependent. The node needs a reachable management NIC, a boot path that reaches DCM, and enough disk to satisfy the storage layout. In a homelab, that often means the node boots from PXE or from a DCM-exposed ISO. The important difference is that the node does not come back as a blank install waiting for you to configure it; it comes back with the identity, network, storage, and cluster membership you asked for.

That is the core of replacing manual node onboarding: the node arrives configured, not blank. The profile is the source of truth for the install job. If you change the profile, the next install follows the new profile. In my experience, DCM is not a general configuration manager for every setting on an existing node; it is strongest when used for the initial install and cluster join. That boundary is useful. It means you can keep later configuration in your normal workflow without expecting the install profile to chase every change.

The install log is where you spend time when something fails. I read it in three passes: did the node reach the install media, did the install complete, and did the node join the cluster. Those are three different failures, and the fix for each is different.

Here is the practical difference I care about:

Task	Manual onboarding	DCM 1.1 automated install
Time per node	20 to 40 minutes	10 to 20 minutes after the profile exists
Human steps	ISO, network, storage, cluster join	Create profile, start install, verify
Error surface	Typos, mismatched IPs, missed updates	Profile validation and repeatable config
Audit trail	Shell history and notes	DCM install log
Reuse	Copy-paste	Same profile for identical nodes

The tradeoff is that DCM does not make your decisions for you. It automates the install path, but it does not choose a storage layout you have not defined, and it does not replace backup policy or node tuning. That is a good thing: you get automation without giving up control of the parts that actually matter in production.

If you are still assembling the cluster by hand, start with Proxmox Datacenter Manager Homelab Cluster Setup Guide. For a deeper look at the node install path, see Automated Proxmox VE Node Install with Data Center Manager.

How to Run the Automated Install on a Homelab Node

Use the profile you prepared, then run the install as a job. The steps are short, but the first run is where you learn whether your network and boot path are ready.

1. Put the target node into the boot path DCM expects. For PXE, the node should reach the DCM boot server. For ISO-based installs, the node should be pointed at the DCM media. This is the one part that still depends on your network and BIOS.
2. Start the install from the DCM profile. Use a profile that matches the node's role. If this is a cluster node, do not use a profile that creates a standalone cluster unless you intend to merge it later.
3. Let the job finish its reboots. In my lab with a 512 GB NVMe and a wired 1 GbE link, the node was reachable after about 14 minutes, with the Proxmox install itself taking only a few minutes. Most of the time is spent in reboots and post-install configuration.
4. Check the node from the existing cluster before you trust it.

Before you start the job, confirm the IP is not already assigned. In a homelab, the most common silent failure is a target node that boots, installs, and then comes up with the wrong address because the profile IP was already in use.

Start the install and watch the job status, not just the node console. The console is useful, but the DCM install log tells you which stage the workflow is in.

pvecm status
pvecm nodes

On the new node, confirm the identity and network state.

pveversion -v
ip -brief addr show
ip route
timedatectl status

If the node appears in the cluster node list, you are in the verification phase. If it does not, the first thing I check is whether the node actually installed. A black console, a stuck installer, and a node that reboots into a bare metal OS are all different problems.

The gotcha I hit first was not DCM; it was the target NIC. The node had two NICs, and the one DCM expected was not the first boot interface. The install media never appeared. Once I forced the management NIC to be first in the boot order, the job completed. If you use PXE, also check for stale DHCP options pointing at an old TFTP or HTTP server.

What to Verify Before You Call It Done

An automated install is only as good as the verification you run after it. I treat the first 10 minutes after install as a checklist, not a hope.

Cluster membership:

pvecm status
pvecm nodes
pvecm quorumstatus

Quorum status matters because a cluster with one node can look healthy until you add a second. You want to see the expected node count and no quorum loss before you move workloads.

Storage:

pvesm status
pvesm list

Storage status should show the local store and any PBS store you expect. If you use PBS, the storage ID should be present and not in an error state. If you do not use PBS yet, that is fine, but note it for the backup pass.

Media and packages:

pveam update
pveam list local:iso
apt update
apt -y upgrade

Package upgrade may take a few minutes. Do it before moving VMs or LXCs onto the node. A node that is current on install day is less likely to need a second reboot later.

Backups, if you use PBS:

pvesm status | grep -i pbs

Network and time:

ip -brief addr show
ip route
timedatectl status

Time sync matters for backups and cluster logs. If the node is off by minutes, backup jobs and replication can be confusing to debug.

After that, run the Proxmox VE 9.1 Homelab Setup Checklist on the new node. The install workflow gets you to a working node, but the checklist is where you confirm the node matches the rest of the cluster.

When to Skip DCM and Install Manually

DCM 1.1 is best when the node is part of a repeatable pattern. It is less attractive when the node is a one-off experiment.

• You are testing a nonstandard storage layout and do not want to encode it in a profile.
• The node has an unusual NIC order and you need to verify the installer network by hand.
• You are installing a single temporary node for a migration or test.
• Your PXE path is fragile and you would rather use a USB installer.

Manual install is also better when you need to demonstrate the install process to someone else. You can control the pace and explain each step. DCM is better when you need the result.

Even then, the verification steps are the same. The value of DCM is not that it hides the Proxmox commands; it is that it makes the first node and the fiftieth node follow the same path. If you were using Ansible to repeat node setup, DCM 1.1 removes the install and cluster-join part of that playbook. You can still use Ansible for later configuration, but you no longer need it to get a bare-metal node into the cluster.

Conclusion

Proxmox Datacenter Manager 1.1 turns host onboarding from a manual ritual into a profile-driven install. For a homelab, that means you can add a node without re-learning the order of operations, and you get a consistent starting point for storage, backups, and cluster membership. Your next step is to create one plain install profile, run it on a spare node, and then verify the node with the cluster, storage, and package checks above.