Everything in this lab that is not a rented gateway runs as a virtual machine, and something has to run those machines. That job goes to Proxmox: an open source hypervisor platform that turns one physical server into many isolated ones, with a web interface, clustering, and backups included rather than sold separately.
Drafted by an AI agent (claude-opus-5) from this lab’s own runbooks, deployment log and errata. Reviewed before publication by the site owner. How this site is written →
This is the first of a series of notes on why each component was chosen, what it beat, and what the choice cost. They are the long form of the one-liners on the Tooling page.
What it replaced
Nothing, and it is worth being honest about that rather than reconstructing a shortlist after the fact.
There was no evaluation matrix. The human had run Proxmox before and knew it worked, the free tier does everything this lab needs, and the community around it is large enough that most problems have already been hit by someone who wrote it down. That is a legitimate way to choose infrastructure and it is how most infrastructure actually gets chosen.
One option was actively excluded, and for a reason worth stating.
VMware was excluded on its licensing position.
Not on capability, and not from unfamiliarity. The human runs VMware in production at scale in their day job and has done for years. This is a rejection by someone who knows exactly what is being turned down, which is worth stating, because “chose the free one” and “chose the free one despite running the expensive one professionally” are different claims.
The technical case was never the problem. The problem is that a homelab is a multi-year commitment made by one person with no purchasing leverage, and the terms under which VMware’s entry-level offerings are available have moved repeatedly in recent years, sometimes for people who had already built on them.
An enterprise absorbs that with a procurement team and a renewal negotiation. A single person with a rack in a basement has neither. The same platform can be entirely the right answer at work and the wrong one at home, and the deciding variable is not the technology.
A hypervisor is the layer everything else sits on. Migrating off it later is not a weekend.
Why this one
The deciding property is that the free tier is the whole product.
Proxmox sells a subscription, and the subscription buys a stable enterprise package repository and vendor support. It does not buy features. Clustering, high availability, live migration, snapshots and the backup system are all present without paying anything. There is no capability in this lab’s design that sits behind a paywall, which means the architecture was never shaped around a license.
That is a narrow-sounding point and it is the important one. A platform whose free tier is deliberately incomplete forces a choice between paying and designing around the gap, and designing around the gap tends to produce architecture that exists to dodge a pricing model rather than to solve a problem.
How it is actually used here
Today: one node, online and carrying production, with five virtual machines on it. The design calls for two, and the second machine is racked but has never been powered on.
The finished shape is a two-node cluster with high availability, and the reason the second node exists is not capacity. The first node alone has the processor threads and memory to run the entire sixteen-VM design with headroom. The second node is there so that a machine can fail, or be taken down for maintenance, without the services on it going away. That distinction matters when reading the build plan: node two is a redundancy purchase, not a capacity purchase.
The cluster shape, and the third machine
A two-node cluster has a structural problem. Clustering software needs a majority to agree before it acts, and two votes cannot produce a majority when they disagree. If the link between the nodes drops, each one sees the other as gone, and neither can safely decide whether it is the survivor or the isolated one. Acting on that guess in both directions at once is how a cluster ends up running the same virtual machine twice on two hosts writing to the same disk.
So a two-node HA cluster is really a three-machine arrangement. The third is a quorum device: a small always-on host running a lightweight voting service, which does nothing except break ties. It never joins the virtualization or storage layers, holds no VMs, and needs almost no resources. It is a vote.
In this lab that role goes to an older, freed-up server rather than new hardware, and it sits on the regular network rather than on the isolated cluster interconnect, which is deliberate: a witness reachable only over the link that just failed is not a witness.
What it cost
Three things, and the second is the one that would not have been obvious in advance.
The two-node cluster is a three-machine commitment. The quorum device is cheap and it is not optional, and a plan that says “two-node HA” without mentioning it is understating what has to be running for the design to be safe.
High availability does not cover everything. One planned VM, the local AI workload, has to live on the first node specifically, because it needs a graphics card passed through to it and the card is physically in that machine’s expansion slot. A passed-through PCIe device cannot follow a VM to another host. So the machine with the most expensive hardware in it is the one HA cannot rescue, and that is a property of hardware passthrough generally rather than a Proxmox defect. It still has to be planned around, and it was not obvious until the design was drawn.
The operational surface is real. Running your own hypervisor means the failure modes are yours. This project has already published several that came straight from that decision, including a VM freeze that took two wrong diagnoses before it was measured, where the fix turned out to be that removing a configuration flag stops asking for a CPU feature while a passthrough processor model hands it over anyway. There is no support line for that. There is a forum, which in practice is often better, and sometimes it is three in the morning and it is neither.
What would change the decision
Stated by the human, and worth recording precisely because these are the conditions rather than a vague sense that something might come along.
- A change in the licensing model. The reason Proxmox won is that its free tier is complete. If that stops being true, the reason stops being true.
- A change in the support ability. Meaning both the vendor’s and, more relevantly here, the community’s. A platform whose answers are all six years old is a different platform.
- A change in the stability of the platform. Hypervisors are the one layer where boring is the entire specification.
None of those has happened. The point of writing them down is that the decision can now be re-examined against something specific, rather than defended out of habit, and a reader can judge whether their own situation already differs.
About Proxmox VE
Proxmox Virtual Environment is an open source server virtualization platform from Proxmox Server Solutions GmbH, based in Vienna. It is built on Debian and combines two kinds of virtualization in one interface: KVM for full virtual machines and LXC for lighter-weight containers, managed through a web console rather than a separate client application.
It is released under the GNU Affero General Public License v3. The paid subscription buys access to an additional, more conservatively tested package repository and vendor support; it does not unlock features.
- Website — proxmox.com
- Documentation — pve.proxmox.com/pve-docs
- Source — git.proxmox.com
- Community — forum.proxmox.com