The homelab hardware: two Proxmox nodes, a laptop, and a Pi

My homelab is two Proxmox nodes, a Raspberry Pi 5 and a NAS that runs as a guest. The primary node was built to be the server. The secondary is my college laptop, which is also the machine I play games on. This post covers what each machine does and what a laptop needs to work as a cluster node.

What each machine does

The primary node

An AMD desktop with 32 GB of RAM and an RTX 5060. I built it to be the server, so it gets the NAS guest, the GPU guest and the VMs that need the most memory.

The RTX 5060 is passed through to a guest that runs local models. Why passthrough and not an LXC container is in the GPU post.

32 GB sounded like plenty. The host sees 31,186 MiB of it, and at one point the balloon floors of its guests added up to 32,768 MiB. RAM runs out long before the cores do, which the cluster post gets into.

The secondary node

An ASUS TUF FX505DT from college:

• Ryzen 5 3550H, 4 cores and 8 threads
• 16 GB of RAM
• GTX 1650 next to the AMD Vega integrated graphics
• 512 GB NVMe and a 1 TB hard disk

Linux reports the disks as 477 GiB and 931 GiB, the usual 7% that goes missing between the box and lsblk.

Proxmox is on the NVMe, and part of the hard disk holds the backup datastore. The host runs on the integrated graphics, which leaves the GTX 1650 free to pass through to a small guest.

How to reboot a dual boot node remotely

The laptop dual boots, because it is also the machine I play games on. Proxmox stays first in the EFI boot order, so an unattended reboot comes back into Proxmox and not a Windows desktop nobody is sitting at.

Before a remote reboot I also set BootNext. It overrides the boot order for one boot only, and the firmware deletes it after use:

efibootmgr             # list the entries and find the Proxmox one
efibootmgr -n 0003     # boot entry 0003 on the next boot only
reboot

0003 is only an example, use whatever number your Proxmox entry has. “I am fairly sure the boot order is still right” is not a plan.

How to stop a laptop node from sleeping

Close the lid on a laptop hypervisor and it suspends, because logind defaults HandleLidSwitch to suspend. The fix goes in /etc/systemd/logind.conf:

[Login]
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

The first line does most of the work. HandleLidSwitchDocked already defaults to ignore, and HandleLidSwitchExternalPower is not used until it has an explicit value. The other two lines are there so nobody has to remember that. Restart systemd-logind or reboot to apply it.

Ignoring the lid is not the same as refusing to sleep. The suspend key still defaults to suspend, and any process can call systemctl suspend. So I masked the sleep targets as well:

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

That still works, but the Debian wiki now lists the mask as the method for releases older than Debian 10. Proxmox VE 9 is on Debian 13, and the current method is a drop-in at /etc/systemd/sleep.conf.d/nosuspend.conf:

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no

The battery and the fan

A laptop battery is a UPS that came with the machine. When the power drops, the node keeps running. It covers the laptop only, so without a UPS on the router and the switch the node stays up and unreachable.

The fan profile is exposed to Linux as well. The asus-nb-wmi driver has a throttle_thermal_policy file in sysfs, where 0 is the default profile, 1 is overboost and 2 is silent. Home Assistant switches it over an SSH key that can only run the fan script. Above 80C for a minute it goes to turbo, below 70C for five minutes it goes back to balanced.

The mode resets to default on every reboot, which on a dual boot machine is often.

The third machine

A Raspberry Pi 5 with 4 GB of RAM, booting from an SD card. It runs the Omada controller for the switch and the access points, and a secondary DNS resolver.

It is not in the Proxmox cluster, on purpose. When the cluster is down, I still want the network controller and the fallback DNS up. They cannot live on the cluster they are meant to outlast.

The SD card is the part I would change. The Omada controller is a Java application on top of MongoDB, and it writes about 5.6 GB a day to the card. That is roughly 2 TB a year, onto a card holding about 5.5 GB of actual data. The Pi 5 can boot from NVMe through the M.2 HAT+, so that is the fix.

Storage and network

Bulk storage is TrueNAS, running as a guest on the primary node with two 3.64 TiB disks passed through raw. That setup had one sharp edge around backups, which needs a post of its own.

The network is TP-Link Omada: an ER7206 router, an SG3210XHP-M2 PoE switch and two EAP670 access points. Devices sit on four VLANs, split by how much I trust them. How the SSIDs are bound to those VLANs, and the config flag that looks broken and is not, is in the networking post.