How to Ditch Bare Metal and Run Everything on Proxmox

Running Proxmox VE 9.1 on every node while still keeping TrueNAS, Home Assistant, or your monitoring stack on bare metal is the most common homelab trap. You end up with a mixed environment that cannot be snapshotted, cannot be cleanly rebuilt, and creates dependency tangles that only make sense at 2am. Hypervisor-first means Proxmox sits on every piece of hardware and every service runs inside a VM or LXC container -- nothing executes directly on the host OS. By the end of this guide you will have a concrete migration plan and a Proxmox foundation where any service can be snapshotted, cloned, or rebuilt from scratch in under five minutes.

Key Takeaways

• Snapshot recovery: Every VM and LXC can be rolled back in seconds; bare metal gives you no equivalent safety net.
• Resource isolation: CPU, RAM, and disk I/O limits let 12+ services coexist on hardware that previously ran one.
• Network segmentation: Proxmox Linux bridges give you per-workload VLAN isolation without requiring managed switches first.
• Migration timeline: Most bare-metal services move to LXC in 30-90 minutes; disk-heavy workloads like TrueNAS take longer as VMs with passthrough.
• The tradeoff: You add a thin hypervisor layer, but on modern hardware the overhead is under 3% CPU and roughly 200 MB RAM for the Proxmox host itself.

Why Running Anything on Bare Metal Is the Wrong Default

The usual argument for keeping services on bare metal is performance. For storage servers moving petabytes with direct disk access, that argument has some merit. For everything else -- Home Assistant, Plex, Pi-hole, Nextcloud, Gitea, monitoring stacks -- it does not hold up.

Proxmox KVM adds roughly 1-3% CPU overhead on modern CPUs with hardware virtualization extensions enabled. LXC containers add essentially zero overhead because they share the host kernel. The actual cost of going hypervisor-first is one afternoon of planning. The payoff is that every disaster scenario -- bad update, misconfigured service, corrupted database -- becomes a 30-second rollback instead of a 3-hour reinstall.

The second argument is "complexity." Running bare-metal Pi-hole is simpler than running an LXC Pi-hole on day one. By day 90, when you want to replicate it to a second node, roll back after a bad update, or move it to newer hardware, the bare-metal version requires documentation and luck. The LXC version is three pct commands. If you are already running Docker inside LXC containers on Proxmox, you have already seen how little overhead the container layer adds.

Planning Your Migration: Workload Inventory First

Before moving anything, inventory every service and answer three questions for each:

1. Does it need direct hardware access (GPU, disk controller, specific USB device)?
2. Does it need a custom kernel module the host does not have?
3. Is it stateful, and how much data would you lose if you rebuilt it today?

Most homelab services fail none of these. Pi-hole, Uptime Kuma, Gitea, Nextcloud, Jellyfin (software transcoding), and Home Assistant all run in unprivileged LXC containers without modification. Services that need direct hardware -- TrueNAS with HBA passthrough, a gaming VM with GPU -- go into full KVM VMs.

Build a Migration Table Before You Start

Service	Current location	Target type	Data volume	Priority
Pi-hole	bare-metal RPi	LXC unprivileged	< 1 GB	High
Home Assistant	bare-metal RPi	VM (HAOS)	5 GB	High
Plex	bare-metal Ubuntu	LXC privileged	media via bind mount	Medium
TrueNAS	bare-metal server	VM + HBA passthrough	48 TB	Low
Gitea	bare-metal Docker	LXC + Docker	10 GB	Medium

Move high-priority, low-data services first. This builds your operational confidence and validates your Proxmox networking and storage configuration before you touch anything critical.

Setting Up the Proxmox Foundation

If you have not already installed Proxmox, How to Install Proxmox VE on Any Hardware covers the full installer walkthrough and post-install configuration. Once the host is up, configure your storage backend before creating a single VM or container.

For a single-node setup with one NVMe drive, the default local-lvm (LVM-Thin) layout works. If you have a second drive, add a ZFS mirror immediately -- retrofitting this after your lab is populated is painful.

# List available drives
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

# Create a ZFS mirror pool using disk IDs (never use /dev/sdX -- names shift on reboot)
zpool create -f -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  tank mirror \
  /dev/disk/by-id/ata-WD_Red_6TB_WD-XXXXXX \
  /dev/disk/by-id/ata-WD_Red_6TB_WD-YYYYYY

Add the ZFS pool to Proxmox: Datacenter > Storage > Add > ZFS, select tank, enable it for VZDump backups and disk images. ZFS supports snapshots natively via copy-on-write, which is what makes rollback instant rather than slow.

Network Bridges and VLAN Awareness

Proxmox creates vmbr0 during install, bridged to your first physical NIC. Enable VLAN-aware mode so each VM and LXC container can be tagged to a separate VLAN without additional physical interfaces. Full VLAN setup is covered in Configuring VLANs on Proxmox with Linux Bridges.

# /etc/network/interfaces -- add bridge-vlan-aware yes to vmbr0
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes

Apply with ifreload -a (from the ifupdown2 package, installed by default on Proxmox VE 9.1) -- no reboot required.

How to Migrate a Bare-Metal Service to LXC

The fastest path for most services:

1. Download the matching Proxmox LXC template (Proxmox UI: local > CT Templates > Templates).
2. Create an LXC container with conservative CPU and RAM limits using pct create.
3. Install and configure the service inside the container.
4. Transfer state (config files, databases) from the old host via rsync or pct push.
5. Validate functionality for 24-48 hours, then shut down the bare-metal instance.

For Pi-hole, the built-in Teleporter export captures all blocklists and configuration as a single ZIP file you can import directly into the new container. For services with larger state:

# Rsync config from old bare-metal host into the new LXC container (ID 200)
# Run from the Proxmox host -- container must be running
rsync -avz --progress root@192.168.1.50:/etc/pihole/ \
  /var/lib/lxc/200/rootfs/etc/pihole/

# Push a single file directly into a container
pct push 200 /tmp/config-backup.tar.gz /tmp/config-backup.tar.gz

Sensible Starting Resource Sizes

Start conservative. Adjust live with pct set after observing real usage -- no restart required.

Service	vCPU	RAM	Disk
Pi-hole	1	256 MB	4 GB
Uptime Kuma	1	256 MB	4 GB
Gitea	2	512 MB	20 GB
Nextcloud	2	1 GB	varies
Home Assistant (VM)	2	1 GB	32 GB
Grafana + Prometheus	2	1 GB	20 GB

# Increase RAM and CPU on a running container -- no restart needed
pct set 200 --memory 512 --cores 2

# Check real usage inside the container
pct exec 200 -- top -bn1 | head -20

Resource Isolation: Preventing Noisy Neighbors

The biggest operational win from going hypervisor-first is containment. A runaway container or VM cannot starve the host or neighboring services if you set limits from day one.

# CPU: burst up to 2 cores, sustained cap at 1 core
# --cpulimit is a decimal count of physical core-equivalents
pct set 200 --cores 2 --cpulimit 1 --cpuunits 512

# RAM: hard limit, no balloon, no swap for predictable behavior
pct set 200 --memory 256 --swap 0

# Disk I/O: 50 MB/s read cap, 30 MB/s write cap
# Prevents a backup job from saturating the ZFS pool during working hours
pct set 200 --mp0 volume=tank:subvol-200-disk-0,mp=/,size=20G,mbps_rd=50,mbps_wr=30

For VMs, the equivalent uses qm set:

# Cap a Plex transcoding VM at 4 physical cores worth of CPU time
qm set 300 --cores 4 --cpulimit 4 --cpuunits 1024

Gotcha worth knowing: cpulimit is a decimal count of physical core-equivalents. Setting --cpulimit 1 on a container with --cores 4 means the container sees 4 virtual CPUs but total CPU time across all of them is capped to one physical core. Match cpulimit to cores if you want a hard ceiling at full allocation.

Snapshot Recovery: Why This Setup Pays for Itself

Before every risky operation -- package upgrades, database migrations, major config changes -- take a snapshot. If anything breaks, roll back in 30 seconds.

# Take a snapshot before a risky change
pct snapshot 200 pre-upgrade-20260514 --description "Before pihole v6 upgrade"

# If the upgrade breaks something, roll back immediately
pct rollback 200 pre-upgrade-20260514

# List all snapshots for a container
pct listsnapshot 200

# Remove a snapshot you no longer need
pct delsnapshot 200 pre-upgrade-20260514

VM snapshots use qm with identical syntax. Snapshots are instant on ZFS and LVM-Thin because they use copy-on-write. On plain directory storage (local), snapshots are not supported -- this is the main reason to configure ZFS or LVM-Thin before populating your lab.

Snapshots are not backups. They live on the same storage as the VM or container. Set up automated backups with Proxmox Backup Server to cover the second failure scenario: the storage hardware itself fails.

When Bare Metal Still Makes Sense

Be honest about the exceptions so you can plan for them correctly.

HBA-based storage controllers: If you run TrueNAS with an HBA passed through via IOMMU, you are running it inside a VM -- not on bare metal. This is the correct architecture. TrueNAS gets direct disk access with no I/O overhead from the hypervisor. Plan your IOMMU groups before buying hardware, because PCIe slot groupings vary significantly by motherboard.

Proxmox itself: The hypervisor runs on bare metal. This is not a contradiction -- you run Proxmox on bare metal, and every user workload runs inside Proxmox.

Hardware that resists passthrough: Certain USB security keys, hardware HSMs, and some specialized NICs do not pass through cleanly to VMs. These are rare in homelab contexts. Test before committing to a configuration.

Sub-millisecond latency benchmarks: If you are doing raw NVMe IOPS testing and care about microsecond-level variance, running inside a VM adds measurable jitter. For any production service, this precision does not matter.

Building the Hypervisor-First Habit Over Time

The practical approach is additive, not a big-bang migration weekend. Add one rule to your workflow: any new service goes into an LXC container or VM, never onto bare metal. Any hardware being decommissioned gets its workloads inventoried and moved into Proxmox first.

Over 2-3 months this converts your homelab naturally. The migration cost averages 30-90 minutes per service depending on how stateful it is.

Once everything lives in Proxmox, the automation possibilities open up. VM templates with cloud-init let you deploy a configured Ubuntu 24.04 VM in under 45 seconds. Proxmox API tokens let scripts provision and destroy VMs without root credentials. The combination of Proxmox snapshots for fast rollback and idempotent provisioning for reproducible rebuilds gives you two independent recovery paths.

Security posture also improves. You can apply firewall rules at the Proxmox datacenter level that apply uniformly to all VMs and containers, and enforce network segmentation per workload via VLAN tags -- without touching each service configuration individually.

Conclusion

Going hypervisor-first with Proxmox VE 9.1 produces a homelab you can snapshot, replicate, migrate, and hand off to yourself six months from now without relying on memory or notes. The migration from bare metal is 30-90 minutes per service, spread over a few months at your own pace. Start with your lowest-stakes service, validate storage and networking, then work up to stateful workloads. Once you roll back a broken upgrade in 30 seconds rather than spending an evening restoring from a tarball, you will not run anything on bare metal again. A natural next step is setting up Proxmox Backup Server to complement your snapshots with off-node backup copies.