Why I Left XCP-ng for Proxmox

The first post in this series covered why I’m retiring two 1U servers, and the second measured the power saving. This one backs up to a decision that came before any of the migration work — and didn’t go the way I planned.

I had already chosen XCP-ng, on purpose

When I built the old pool years ago, I ran it on XCP-ng, and I chose it largely on the strength of Lawrence Systems — Tom Lawrence’s channel, which I’ve followed for years. XCP-ng ran that pool faithfully the whole time. So when I started the rebuild my default was obvious: put the current XCP-ng release on the new mini PCs and carry on. I wanted to do this rebuild right and not cut corners.

The wall: Secure Boot

Doing it “right,” to me, meant leaving the firmware locked down rather than switching protections off to make my life easier. So I tried to install XCP-ng 8.3 on the Minisforum mini PCs with Secure Boot enabled — and I could not get them to install and boot cleanly that way. I spent a long time on it: firmware settings, forum threads, the usual search-and-retry loop. No combination I found worked on this hardware.

I want to be careful about what I’m claiming. This is not “XCP-ng doesn’t support Secure Boot” — it’s entirely possible the cause was these particular mini PCs, their firmware, or something I simply missed. What I can say honestly is that after a lot of effort I still didn’t have a working install, and I wasn’t willing to just disable Secure Boot and call it done.

A nudge from the usual place

Around the same time, Lawrence Systems put out a run of videos on the post-VMware landscape — people leaving VMware after the Broadcom acquisition and weighing where to go, with XCP-ng and Proxmox both in the conversation.¹² Having chosen XCP-ng off that channel’s advice once already, it felt fitting to let it inform the second look too. The thing I took away was simple: Proxmox was worth a serious try, not just a grudging fallback.

Proxmox just installed

So I put Proxmox on the minis. It installed without drama — Secure Boot and all — and within an evening I had both nodes up and was clicking around. After the XCP-ng fight, the absence of a saga was its own kind of signal.

LXC sold me

What turned “Proxmox works” into “I’m switching” was LXC containers. XCP-ng isolates workloads as full virtual machines; Proxmox runs both full VMs and LXC system containers natively on the host, sharing its kernel instead of running a separate one for every service.

That distinction matters more than it sounds. My lab is mostly small, single-purpose Linux services — a certificate authority, a jump host, and the like — and as full VMs each one pays for an entire guest OS and a block of RAM reserved up front, used or not. As containers they share the host kernel and draw memory only as they actually need it. It doesn’t make a genuinely heavy service lighter — GitLab still wants its several gigabytes either way — but it stops the dozen small things around it from each costing a full VM’s worth of overhead. On two mini PCs with 16 GB apiece, that overhead is the difference between fitting and not — and the heaviest, bulkiest work, backups and storage, lives on the NAS rather than on these two boxes at all. Given that the whole point of the rebuild was to fit the lab onto far smaller hardware, that wasn’t a nice-to-have. It was the deciding factor.

None of this is a knock on XCP-ng. It ran my old pool well for years and I’d still recommend it to people. But for these mini PCs, this workload, and a rebuild whose whole goal was to do more with less, Proxmox fit and XCP-ng — at least the way I tried to install it — didn’t. The next post is where that choice meets the actual work: the first Terraform commit, the first apply, getting a TLS cert the hard way, and pushing the code to the server the code itself built.

AI-assistant disclaimer: This post was drafted by Claude Code (Claude Opus 4.8, claude-opus-4-8) from my own account of the events and homelab notes, then reviewed and edited by me. The XCP-ng install trouble is my experience on specific hardware, not a general claim about the software. Verify specifics before relying on them.