Part 2: Installing Proxmox on Old Dual Xeon Hardware
In Part 1 I made the case for turning an old ASUS dual Xeon workstation into Forge — a documented, rebuildable platform for AI-assisted development, self-hosted Git, automation, and storage. This post covers the first real step: getting a hypervisor onto the bare metal, and the decisions made before a single container existed.
Fair warning: installing Proxmox is genuinely easy. The installer does its job in about fifteen minutes. The interesting part — and the reason this post exists — is everything around the install: why Proxmox over the alternatives, how the disks were divided up before anything was deployed on them, and the sequencing lessons that only became obvious once services started piling up.
The Starting Point
A quick recap of the hardware on the bench:
- ASUS dual Xeon workstation/server board
- 32GB of RAM
- 2 x Samsung 256GB SSDs
- 2 x 6TB hard drives
Nothing exotic, nothing new, and — as Part 1 covered — nothing capable of fast local LLM inference. But two CPUs’ worth of cores and a sensible amount of RAM is a perfectly good foundation for the actual job: running a couple of dozen services, a CI runner, and eventually a full web development VM, all at once, without drama.
Why Proxmox?
The first decision wasn’t which hypervisor to use — it was whether to use one at all. The obvious lightweight route is Debian plus Docker straight on the metal. One OS, no virtualization layer, less to learn. I ruled it out for one reason that paid off months later: I knew this machine would eventually need real VMs, not just containers. A dedicated web development VM was always on the roadmap (it exists now, running nginx, MariaDB, PostgreSQL, and PHP for staging sites — a later post covers it). Bare-metal Docker gives you no path to that; a hypervisor gives you both.
Given a hypervisor, the shortlist looked like most homelab shortlists:
Proxmox VE won, and it wasn’t close. It’s free and open source, it treats both LXC containers and full KVM virtual machines as first-class citizens, ZFS support is built into the installer rather than bolted on, and — critically for the “rebuildable platform” goal — it has scheduled backup jobs out of the box. Snapshot a container, back it up to designated storage on a timer, restore it in minutes. That’s infrastructure discipline for free.
ESXi was briefly considered and quickly dismissed. The free tier’s future has been shaky since the Broadcom acquisition, hardware support for older boards is a lottery, and it has no ZFS. Betting a personal platform on a license whim seemed unwise.
TrueNAS Scale is a genuinely good product, but it’s a NAS that runs apps, not a virtualization platform that handles storage. My priorities were the other way round. Storage matters here, but it serves the services — not the reverse.
The honest version of the decision: Proxmox is boring, well-documented, and does everything this project needs without asking for money. Boring is a feature in the foundation layer.
The Install Itself
The mechanics are straightforward enough to summarise quickly. Download the Proxmox VE ISO, write it to a USB stick, and boot the target machine from it.
The one place old hardware makes itself known is the firmware. A board of this vintage predates the assumption that everything boots UEFI from NVMe, so expect a detour through the BIOS: setting the boot mode, convincing it the USB stick is a boot device, and — worth doing while you’re in there — checking that the virtualization extensions (Intel VT-x and VT-d on a board like this) are actually enabled. They frequently ship disabled, and Proxmox without hardware virtualization is a sad thing.
The installer asks three questions that matter:
- Target disk. The first 256GB SSD got the Proxmox OS. The second SSD and both 6TB drives were deliberately left untouched — more on why in a moment.
- Network. A static IP on the LAN. A hypervisor that changes address when the router reboots is a hypervisor you’ll lose track of.
- Hostname and credentials. This machine became
forge, a name that ended up spreading through the whole project — the storage pool isforge-hdd, the CI runner isforge-runner-01.
Fifteen minutes later the machine reboots into a console screen showing one URL, and everything from that point on happens in the web UI at port 8006 from another machine.
Deliberately Not Partitioning Everything
Here’s the first decision I’d defend in a code review: during the install, only the OS disk was touched. It’s tempting to set up all the storage in the installer while you’re there — pull the big drives into a pool, allocate everything, feel productive. I didn’t, and the restraint was the point.
The plan for the disks was already sketched out:
| Device | Purpose |
|---|---|
| SSD 1 | Proxmox OS |
| SSD 2 | Fast storage for the Docker LXC and databases |
| 2 x 6TB HDD | ZFS mirror (forge-hdd) for backups, media, photos, documents |
But a plan sketched before the platform exists is a hypothesis, not a layout. Configuring the ZFS mirror and the SSD container storage as separate, considered steps — after the hypervisor was stable, before any services landed — meant each layer could be verified on its own. It also meant the storage layout got its own documentation as it was built, which is the entire reason I can write the next post in this series without archaeology.
The general lesson, which my build notes record with the weary tone of experience: configure storage before installing lots of services. Every service you deploy before the storage layout is final is a service you’ll be migrating later. I got this mostly right; the one media service that landed before the HDD mount was properly wired into the container still cost an evening of fixing bind mounts.
First Housekeeping in the Web UI
A stock Proxmox install needs about twenty minutes of housekeeping before it’s ready to hold anything you care about:
- Repositories. Without a paid subscription, the enterprise package repository fails on every update. Switching to the community (no-subscription) repository is standard practice for homelabs, and the web UI can do it without touching a config file. Then run updates — installer ISOs are always behind.
- The subscription nag. Proxmox pops a “no valid subscription” dialog at login. It’s harmless. Consider it the price of free software and click past it; don’t chase hacky scripts that patch it away and then break on every upgrade.
- Backups before experiments. Another lesson recorded early in the build log: backups should be configured before serious experimentation, not after. Once the backup storage existed, a scheduled Proxmox job backing up the entire Docker container became the platform’s safety net. Every risky change since has been made with the quiet confidence of someone who can restore yesterday’s state in minutes.
And one small, real-world observation from those first days, preserved in my notes: the Proxmox mobile UI is limited. Genuinely useful for glancing at whether a container is up; genuinely miserable for actual administration. Early on I tried to do real work from a phone. Do the setup from a proper machine.
What This Stage Actually Delivered
At the end of this phase, the platform was almost aggressively unimpressive: one machine, one hypervisor, an empty web UI, and three untouched drives. No dashboard, no Git server, no AI anything.
But the shape of everything that followed was already set. The choice of Proxmox meant LXC containers for the Docker layer and full VMs when the web development workload arrived later. The untouched disks meant storage got designed rather than accumulated. The backup-first habit meant the experimentation that followed — and there was a lot of it — never risked the platform itself. Foundations are boring precisely when they’re done right.
Next in the Series
With the hypervisor stable, the next job is the one I deferred during the install: carving up those disks properly. Part 3 covers the storage layout — building the forge-hdd ZFS mirror from the two 6TB drives, setting up SSD-backed fast storage for containers and databases, and deciding what data belongs on which tier and why.
Next: Part 3 — Storage Layout with a ZFS Mirror and SSD Tiers