Proxmox PulseProxmox Datacenter Manager Homelab Cluster Setup Guide
Use Proxmox Datacenter Manager to bootstrap a three-node homelab cluster with repeatable installs, API access, and stable fast recovery after failures.
On this page
I rebuilt my homelab three times last month: once for a bad ZFS choice, once for a typo in a cluster address, and once after I stopped hand-editing node configs. Proxmox Datacenter Manager 1.1 gave me one place to hold inventory, API users, and cluster health, while the Proxmox VE 9.2 installer still does the actual node install. The result is a three-node cluster with static IPs, local ZFS storage, and a bootstrap path I can rerun in about 45 minutes.
Key Takeaways
- Repeatable: install one node, write down the answers, then clone the network and storage plan across the rest.
- API-first: let Datacenter Manager 1.1 hold the access model so you are not SSHing into every node to check a user.
- Small cluster: three nodes are enough for HA and failover tests without wasting RAM on a quorum-only box.
- Clock first: fix time synchronization before the first join; drift can make a healthy cluster look broken.
- Tradeoff: the manager VM adds one more thing to back up, but it saves hours after the second rebuild.
Why Bootstrap Through Datacenter Manager?
Datacenter Manager 1.1 is not a magic PXE server, and it does not replace the Proxmox VE installer. It is most useful as the control plane for the parts you repeat: inventory, users, API access, cluster health, and the checklist you run after each node comes online.
On a one-node lab, that feels like extra overhead. On a three-node homelab, it becomes the difference between a cluster you trust and a cluster you rebuild after the first bad week. If you want a deeper look at the installer side, the automated Proxmox VE node install post covers that path. This post is about the cluster bring-up around it.
The practical workflow is simple: install the nodes with the same answers, join them to the cluster, then let Datacenter Manager 1.1 hold the map. I still use normal Proxmox commands for the heavy lifting, but I stop treating each node as a separate snowflake.
What You Need Before Starting
Use three nodes with similar hardware. They do not need to be identical, but similar CPU families make live migration and HA testing much less annoying. For my homelab, each node had:
- 16 GB RAM minimum, 32 GB preferred if you plan to test live migration
- 250 GB boot drive or a small local ZFS mirror
- static IP on the management network
- same timezone and NTP source
- same root password during bootstrap, then rotate it later
The manager itself runs as a small VM on one of the nodes or on an existing box:
- 2 vCPU
- 4 GB RAM
- 32 GB disk
- static IP on the same management network
It must reach the Proxmox VE API port on each node. That is the only hard network rule.
Here is the bootstrap checklist I keep as a small YAML file on the manager:
cluster: homelab01
manager: 192.168.10.10
nodes:
- pve01: 192.168.10.11
- pve02: 192.168.10.12
- pve03: 192.168.10.13
storage: local ZFS
network: one management bridge
ntp: pool.ntp.org
That file is not a Proxmox config file. It is just the answer sheet I use so the next rebuild does not depend on my memory.
How to Prepare a Repeatable Node Install
Verify the installer image first
Before touching any node, verify the ISO. This sounds obvious, but a bad USB stick has cost me more time than any Proxmox bug.
sha256sum proxmox-ve_9.2-1.iso
Check the checksum against the published value. If it does not match, do not continue. A corrupted installer can create a node that boots, then fails in a way that looks like a cluster problem.
Use the same installer answers
For each node, use the same timezone, keyboard layout, and root password during bootstrap. The only fields that should change are hostname and static IP.
I use:
pve01at192.168.10.11pve02at192.168.10.12pve03at192.168.10.13- gateway at
192.168.10.1 - DNS at
192.168.10.2 - NTP from the same source on every node
Do not let the nodes use DHCP for the management network. A DHCP lease that moves after a reboot will break cluster membership in a very confusing way.
Keep the manager out of the cluster
Run Datacenter Manager 1.1 as a separate VM, not as a cluster member during bootstrap. If the manager is part of the cluster, a failed node can take the manager with it, and then you lose the control plane you were using to diagnose the problem.
That adds one more VM to back up. The PBS replication bandwidth scheduling post covers how I keep that backup from eating the network.
How to Bring the Cluster Up
Create the first node, then join the others
On the first node, create the cluster after the installer finishes and the network is up.
pvecm create homelab01
Then, from the manager VM or a jump host, join the other nodes.
ssh root@pve02 "pvecm add 192.168.10.11 --password 'ChangeMe123'"
ssh root@pve03 "pvecm add 192.168.10.11 --password 'ChangeMe123'"
Use SSH keys for the manager if you want the process to feel automated. Passwords are fine for a one-time bootstrap, but keys make reruns much less annoying.
After the join finishes, each node should appear as a cluster member. Do not move on to storage, HA, or guests until the cluster membership is boring and stable.
Verify the cluster from the manager
Add the cluster to Datacenter Manager 1.1 through the web UI. Use the same API user on every node so the manager does not need root passwords scattered across the lab.
Run this on any cluster node:
pveum user add automation@pam --password 'ChangeMe123'
pveum role add AutomationAudit --privs Sys.Audit
pveum access acl add --path / --role AutomationAudit --users automation@pam
pveum token add automation@pam!homelab
The token is what the manager should use for inventory and health checks. It does not need to be a super-admin token unless you plan to let it make changes.
Then verify the cluster from any node:
pvecm status
pvesh get /nodes --output-format json
pvesh get /cluster/resources --output-format json
If the manager shows three nodes and the local commands show three nodes, you have a cluster. If they disagree, fix the disagreement before adding storage or VMs.
How to Standardize Storage and Network
Start with local ZFS, not shared storage
For a homelab bootstrap, local ZFS on each node is usually enough. It keeps the first build simple and avoids pulling in another storage system before the cluster is stable.
If each node has a local ZFS pool, add the storage on each node:
pvesm add zfspool homelab-zfs --pool rpool/data --content images,rootdir
pvesm status
That storage is local. It will not migrate VMs across nodes for you. For now, that is fine. The goal is to make the storage configuration identical on every node so rebuilds are predictable.
If you later want shared storage, move to it after the cluster is stable. The ZFS pool with SMB and NFS shares post covers the storage side in more detail.
Give the management network a boring name
Use one management bridge for cluster traffic, API access, and web UI access. Do not add VLANs, VXLAN, or complex SDN zones until the basic cluster is stable.
Check the network on each node:
pvesh get /nodes/pve01/network --output-format json
pvesh get /nodes/pve01/storage --output-format json
The output should be the same on every node except for the node name and local disk names. If it is not, stop and fix the network before continuing.
The most common failure I have seen is a node that joined with the wrong DNS server. The cluster looks alive, the web UI works, and then API calls or storage checks fail in ways that look random.
How to Test the Bootstrap
Power-cycle one node
A homelab cluster is not real until one node can be unplugged without making you nervous.
Shut down a VM on pve03, then power-cycle the node. After it comes back, run:
pvecm status
pvesh get /cluster/resources --output-format json
If the node rejoins cleanly and the manager shows the same inventory, the bootstrap is working. If the node takes a long time to rejoin, check NTP before blaming Proxmox.
Time drift is the quiet killer. A node with a clock off by several minutes can fail cluster checks in ways that look like network or storage problems. Fix NTP first, then debug anything else.
Re-add a failed node
If a node is gone for good, remove it from the cluster while it is offline:
pvecm delnode pve03
Reinstall the node with the same installer answers, then join it again:
ssh root@pve03 "pvecm add 192.168.10.11 --password 'ChangeMe123'"
After the join, verify the cluster again:
pvecm status
pvesh get /nodes --output-format json
pvesh get /cluster/resources --output-format json
This is the moment where the bootstrap either proves itself or shows you which answer you got wrong the first time. If the rebuild takes longer than the original install, the problem is usually documentation, not Proxmox.
Comparison: Manual Versus Datacenter Manager Bootstrap
| Area | Manual Homelab | Datacenter Manager 1.1 |
|---|---|---|
| Node install | One installer run at a time | Same installer, but answers are tracked in one place |
| Cluster join | Copy-paste commands from memory | Manager shows cluster inventory after each join |
| Users and access | Root password on every node | One API user and token for automation |
| Storage checks | Check each node separately | Same checks, grouped by cluster |
| Failure recovery | Rebuild from memory | Rerun the same checklist |
| Single-node lab | Manager feels like extra overhead | Manager adds little value |
| Three-node lab | Manager pays for itself after the second rebuild | Manager becomes the control plane |
The honest tradeoff is that Datacenter Manager 1.1 adds one more system to maintain. If your lab is a single node, that overhead is probably not worth it. If your lab has three nodes and you plan to rebuild it more than once, it becomes the thing that keeps the next rebuild from turning into archaeology.
Conclusion
The cleanest homelab cluster is not the one with the most features on day one. It is the one you can rebuild in under an hour without guessing. Use the Proxmox VE installer for the nodes, keep the answers boring, and let Datacenter Manager 1.1 hold the inventory, access model, and cluster health.
Your next step is simple: write down the installer answers, verify the ISO, and build the first node. Once that node is boring, add the second and third. If the cluster still looks the same after a power-cycle, you have a bootstrap you can trust.
