Two Proxmox nodes, a Raspberry Pi and a NAS. The primary node was built to be the server and does nothing else. The secondary is my college laptop, which is also the machine games run on. Most of what follows comes out of that split, and out of a laptop making a better second node than its price suggests.
Primary node
- Runs Proxmox and nothing else
- 32 GB RAM, GPU passed to a guest
- Uptime expectation and a change process
- Holds what the whole house notices
Secondary node
- Dual boots; also the games machine
- 16 GB RAM, second GPU, spare disk
- Rebooted on a whim, nothing depends on it
- Second vote and a place for backups
- Battery is a UPS already attached
The cheapest second node is a laptop you already own.
The primary node
An AMD desktop with 32 GB of RAM and an RTX 5060, running Proxmox and nothing else. That is the point of it. The machine holding the services everyone in the house notices when they stop should not also be a machine somebody is sitting at.
The GPU is passed through to a guest that runs local models, which is covered in its own post. It is not there for games. 🎮
32 GB sounds like plenty and is the first thing to run out. More on that in the cluster post, because it is not the cores that constrain a homelab.
The secondary node
A college laptop: Ryzen 5 3550H, 16 GB of RAM, a GTX 1650 alongside the AMD integrated graphics, a 477 GB NVMe and a 931 GB spinning disk. It dual boots, because it is also the machine games run on, and Proxmox is what runs on it the rest of the time.
Two small things make a dual booting node survivable. Put the hypervisor first in the EFI boot order, so an unattended reboot comes back into Proxmox rather than a Windows login screen you cannot see. And before any remote reboot, set the next boot explicitly:
efibootmgr | grep -i proxmox # find the entry number
efibootmgr -n 0003 # boot that next, whatever the saved order says
reboot“I am fairly sure the boot order is still right” is not a plan.
A laptop is an unusual cluster node and it is good value for a reason nobody puts in the spec sheet: the battery is a UPS. Not a metaphorical one. A real one, already attached, already load tested, with a charge controller that has been doing this its whole life. 🔋
The lid is the gotcha. logind will suspend your hypervisor when you close it:
# /etc/systemd/logind.conf
HandleLidSwitch=ignore
HandleLidSwitchDocked=ignore
HandleLidSwitchExternalPower=ignoreThen mask the sleep targets, because ignoring the lid switch is not the same as refusing to sleep:
systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.targetIt also has a fan curve you can drive from software, which is how an auto turbo rule ended up in Home Assistant. Above 80C for a minute, go turbo. Below 70C for five, go back to balanced 🙂
The third machine
There is a third always on machine: a Raspberry Pi 5 with 4 GB of RAM and an SD card, running exactly one container, the controller for the switch and the access points.
It is deliberately not part of the Proxmox cluster, and that is not laziness. The controller for a network cannot depend on the thing whose network it controls. Neither can a monitoring endpoint, or a second DNS resolver. A monitor that shares fate with its subject is a decoration. The Pi costs almost nothing to run and stays up when both of the interesting machines are down.
The SD card is the part I would change. A Java application backed by MongoDB writes about 5.7 GB a day, and random writes are the worst thing you can do to SD flash. That is an NVMe hat waiting to happen. 💾
Storage and network
Bulk storage is a TrueNAS appliance running as a guest on the primary node, with two 3.64 TiB disks passed through raw. That arrangement is fine for storage and it has one sharp edge around backups, which is a longer story than this post has room for. 🗄️
The network is a TP-Link ER7206 router with two WAN links, a PoE switch, and two EAP670 access points. Four VLANs, split by how much each group of devices is trusted. How SSIDs get bound to those VLANs, and the config flag that reads as broken and is not, is in the networking post.
The split
The division is the whole design, and it is worth stating plainly: one machine is the server, the other is everything else.
That is what makes the rest tractable. The primary node can be treated as infrastructure, with an uptime expectation and a change process. The secondary can be rebooted on a whim, because nothing depends on it being there, and it earns its place by being a second vote, a second GPU and a place to put backups that is not the machine they protect.
The cheapest second node is a laptop you already own, and a working battery is a UPS you do not have to buy. 💻
Next: what an even number of votes does to a two node cluster.