Proxmox

TL;DR: Proxmox is the software that lets me run multiple virtual computers on a single physical machine. It’s my homelab’s foundation—I use it to test ideas safely before applying them at work, and to run home automation without dedicated hardware for each service.

Proxmox VE is the hypervisor layer that ties my homelab together. It runs VMs and containers, integrates with TrueNAS storage, and provides the management interface for the whole lab.

This is where I learned virtualization and clustering concepts that eventually scaled into production work. The Proxmox + Ceph infrastructure I run professionally grew directly from experiments I ran here first.

Why Proxmox

I chose Proxmox over other hypervisors for a few reasons:

Open source with no artificial limitations. VMware’s free tier restricts features I wanted to use. Proxmox gives you everything without licensing games. The business model is support subscriptions, not feature gates.

KVM and LXC in one interface. I run both full VMs (for things that need isolation or specific kernels) and LXC containers (for lightweight Linux services). Proxmox manages both through the same interface, which simplifies operations.

Built-in clustering. Even with a single node, having the clustering infrastructure in place meant I could add nodes later without rearchitecting. When I did add a second node, live migration just worked.

Web UI that doesn’t require a separate management server. Each Proxmox node has its own web interface. In a cluster, any node can manage the whole cluster. No dedicated management VM required.

My Setup

I run a small Proxmox cluster—enough to experiment with HA and live migration, but not so large that it becomes its own project to maintain.

Storage Integration

The most interesting part of my setup is how Proxmox integrates with TrueNAS:

• NVMe-over-TCP from both TrueNAS pools provides block storage for VM disks. I use NVMe-over-TCP for both the SSD and HDD backends—the high-performance block storage interface shows its value regardless of whether the underlying storage is fast or slow. Lower protocol overhead and better queue handling benefit even spinning rust.

• NFS from both TrueNAS pools handles shared storage needs—ISOs, backups, templates, and any workloads that benefit from multiple VMs accessing the same data. The TrueNAS page covers the storage architecture in more detail.

• Local ZFS on each Proxmox node for workloads that benefit from local disk performance or don’t need shared storage.

What Runs Here

• Home Assistant as a dedicated VM with USB passthrough for the Zigbee coordinator
• Development VMs for testing configurations before applying them elsewhere
• LXC containers for lightweight services (DNS, monitoring, small utilities)
• Test environments that mirror production patterns at smaller scale

What I’ve Learned

Virtualization abstractions are leaky. VMs aren’t perfectly isolated black boxes. CPU steal, noisy neighbors, storage contention—these affect performance in ways that matter. Running my own hypervisor taught me to think about these effects.

Backup and snapshot discipline matters. Proxmox makes snapshots trivially easy. I’ve developed habits around snapshotting before changes, testing restores periodically, and maintaining backup schedules. These habits transferred directly to production work.

The management plane is infrastructure too. When Proxmox itself has problems, you can’t manage your VMs. I’ve learned to think about the hypervisor layer as critical infrastructure that needs its own monitoring and backup strategy.

Clustering adds complexity. A single Proxmox node is simple to operate. A cluster adds quorum requirements, shared storage considerations, and network dependencies. Worth it for HA, but not free.

The Path to Production

My professional Proxmox + Ceph work builds on concepts I learned here, though the storage architecture differs deliberately:

The virtualization and clustering concepts transfer directly. The storage difference isn’t an evolution—it’s a different answer to a different problem. TrueNAS makes sense when you can’t justify 3x node redundancy. Ceph makes sense when you can, and when you need storage that survives node failures automatically.

What I’d Do Differently

If I were starting over:

• More network segmentation. I initially ran everything on one network. Separating storage, management, and VM traffic would have been better practice.

• Better monitoring from day one. I added monitoring retroactively. Starting with it would have caught problems earlier.

Why Not Ceph at Home

I sometimes get asked why I don’t run Ceph in my homelab, given that I run Ceph professionally. The answer is economics: Ceph only makes sense when you can justify buying 3x similarly-specced nodes. Ceph’s value proposition is distributed resilience—data survives node failures because it’s replicated across multiple machines. But that replication means you need at least three nodes with comparable storage capacity to make it worthwhile.

In a homelab, I can’t justify tripling my hardware budget for storage resilience my workloads don’t require. TrueNAS with ZFS gives me data integrity and reasonable redundancy on a single box. When a VM’s storage needs exceed what one TrueNAS server can provide, or when I need storage that survives a whole server dying without intervention—that’s production, and that’s where Ceph earns its complexity.

Related

• TrueNAS Storage — The storage backend
• Home Assistant — Runs as a VM on Proxmox
• On-Premise Kubernetes Platform — Where these concepts scale to production
• Homelab — Overview of the homelab