LXC vs VM in Proxmox: When to Use Each

By LK Wood IV · 2026-05-30 · Updated 2026-09-28 · ~10 min read · St. Louis County, MO

The kernel decides it. A Proxmox VM boots its own kernel on virtual hardware; an LXC container, which Proxmox calls a CT and manages with pct (the Proxmox Container Toolkit), runs on the host’s. So a container runs only Linux and cannot live-migrate, while a VM runs Windows or FreeBSD as readily as Linux and can take a whole PCI device. The Proxmox behaviour on this page is from Proxmox VE 9.2 (released May 21, 2026) and its 9.2.12 manual, dated September 18, 2026.

Here’s what I use in my own homelab, why, and where the lines are.

Which one for each service

The Proxmox capacity planner estimates how many guests of each kind your host can hold.

A service not listed goes through the decision tree further down.

What each one is

A VM is KVM with QEMU: virtual hardware and its own kernel, so it can run Windows or FreeBSD, load modules for its guest kernel and take a PCI device whole. A container runs in its own namespaces on the host’s kernel. Proxmox puts a container’s runtime cost at “low, usually negligible” and names the price in the same place: only Linux runs in one, and its access to host resources is restricted.

Where each one wins

LXC

It carries no guest kernel and no QEMU process. Bind mounts give a container a host directory “with practically zero overhead”, and a render node such as /dev/dri/renderD128 can be passed in as a device while the host keeps the GPU and its driver. The web interface gained that device passthrough in Proxmox VE 8.2. The API and CLI had it from 8.1.

VM

Its own kernel and modules. A container runs on whatever modules the host kernel has, and no feature flag changes that: pct.conf(5) lists force_rw_sys, fuse, keyctl, mknod, mount and nesting, nothing that loads a module. WireGuard is not a reason for a VM. It has been in the mainline kernel since Linux 5.6 (March 29, 2020). Proxmox VE 9.2 ships kernel 7.0, and the WireGuard tutorial runs it in a privileged container; keep that setup to trusted code. A module the Proxmox kernel does not carry, a different ZFS version or an out-of-tree NIC driver is a reason.

Other operating systems. Windows and FreeBSD, and the firewall and NAS appliances built on them.

A whole PCI device. A GPU, an HBA or a NIC passed through belongs to that VM alone.

Live migration. In a cluster, qm migrate <vmid> <target> --online moves a running VM — as long as it has no local resource that cannot be migrated: passed-through PCI or USB devices block it, local disks do not. A running container cannot be live-migrated. You can do a restart migration instead (pct migrate --restart): it shuts the container down (killing it after 180 seconds by default), copies it and starts it on the target.

Isolation. A container uses the host’s kernel, which Proxmox says “exposes an attack surface for malicious users”, and “in general, full virtual machines provide better isolation.” A VM’s boundary is KVM and QEMU. I would put untrusted or public-facing code in a VM.

Resource overhead numbers

Here’s a concrete comparison measured on a Beelink SEi12 Pro (N150, 16GB RAM, 512GB NVMe) running Proxmox VE 8.x. That was the current release when these numbers were taken. VE 9 has shipped since and Proxmox’s lifecycle table puts VE 8’s end of support at August 2026. The container-versus-VM overhead these figures show is structural rather than version-specific, so the shape holds. Treat the absolute megabytes as 8.x-era:

Numbers are representative of Proxmox 8.x with virtio drivers. The storage IO gap closes significantly when using virtio-blk with io_uring.

What I run in LXC vs VM

In my own Proxmox setup, the split is roughly:

LXC containers:

• Home Assistant (isolated HAOS-style config on a Debian container)
• Vaultwarden (no kernel needs, pure userspace app)
• Nginx reverse proxy
• Uptime Kuma
• Immich photo server
• Pi-hole DNS
• Gitea
• Prometheus + Grafana stack
• Any service that’s “just a process” — no special kernel requirements, no GPU, trusted code

Virtual machines:

• TrueNAS Scale (needs its own ZFS kernel, storage needs isolation)
• Windows 11 (gaming and testing)
• Any LLM inference node with RTX 5080 GPU passthrough
• OPNsense (firewall OS — needs network kernel control and isolation is mandatory)
• Any publicly-exposed service handling user data

The pattern: if the workload is a Linux service that doesn’t need kernel modules, GPU access, or strong isolation, it’s an LXC container. If it needs any of those, it’s a VM.

The decision tree

New workload in Proxmox?
│
├─ Docker/Compose stack or Home Assistant OS? → VM
│
├─ Windows, FreeBSD or any non-Linux OS? → VM
│
├─ One guest owns a whole PCI device (GPU, HBA, NIC)? → VM
│
├─ Needs its own kernel or a module the host lacks? → VM
│
├─ Untrusted or public-facing code? → VM
│
├─ Must keep running while it moves between cluster nodes? → VM
│
└─ Everything else → LXC container
   (a Linux service, trusted code; an iGPU render node or a host directory can be passed in)

When a service could go either way, I would start it in a VM. Moving a working service into a container later is a planned job; finding out three months in that a container needs the whole GPU is a rebuild.

Proxmox-specific gotchas

Unprivileged is the default. The container’s root UID 0 is mapped to an unprivileged user on the host, and “This is the default option when creating a new container”, in the web interface, where the Create CT wizard’s “Unprivileged container” box starts ticked, and in pct create alike (pct(1): “For creation, the default is 1”). The LXC project calls a privileged container unsafe. It does not treat new escapes from one as security issues “worthy of a CVE and quick fix”. Keep privileged containers for trusted work.

NFS or SMB inside a container. The NFS and SMB/CIFS boxes in a container’s Features dialog are marked “privileged only”, and pct.conf(5) warns that mounting an NFS file system “can block the host’s I/O completely and prevent it from rebooting”. I would mount the share on the Proxmox host and bind-mount it into the container, as in the file-share row above; the container chapter lists a host NFS mount as a use for bind mounts. That keeps the container unprivileged.

Docker inside a container. An unprivileged container needs keyctl=1 (pct.conf: “This is required to use docker inside a container”) and nesting=1, which the web interface has turned on for new unprivileged containers since Proxmox VE 7.1. On a ZFS host the storage driver is the next question, covered in the Proxmox vs Docker guide. Proxmox VE 9.1 (November 19, 2025) can also create a container straight from an OCI image; running application containers that way is still a technology preview, and Compose support sits on the Roadmap, not in 9.2. I would put Kubernetes in a VM.

Memory ballooning. Proxmox adds the balloon device to every VM by default, even at a fixed memory size. That alone reclaims nothing. The host only reclaims memory when you set the VM’s minimum memory below its maximum; the guest then grows toward the maximum while host RAM use stays under the target (80% by default) and gives memory back when the host runs low.

Snapshots depend on the storage. A container’s snapshots need storage with its own snapshot support, such as ZFS, LVM-thin or Ceph RBD (BTRFS is a technology preview). A container’s volumes are raw images, ZFS subvolumes or directories, never qcow2. Proxmox describes ZFS subvolumes as technically bind mounts backed by managed storage, so they can be resized and snapshotted. On directory, NFS, CIFS or plain LVM storage it has none. A VM has more options. It gets those, plus snapshots on file storage (directory, NFS, CIFS) when its disk is qcow2, and on plain LVM through volume chains (a technology preview since Proxmox VE 9.0).

Backup behavior

Containers

vzdump offers stop, suspend and snapshot modes. Snapshot mode suspends the container, takes a temporary storage snapshot and archives it, so it “requires that all backed up volumes are on a storage that supports snapshots”; without that, suspend mode rsyncs the container to a temporary directory first and needs the space for a copy. To a file target the result is a tar archive; to Proxmox Backup Server it is a pxar archive, and the metadata change-detection mode reuses unchanged files from the previous backup. Bind and device mounts “are never backed up”. A vzdump archive and pct restore are also one way to move a container to a different host without a cluster.

VMs

Snapshot mode is a live backup that copies blocks while the VM runs and works on any storage type, snapshot support or not; with the guest agent enabled and running, it calls guest-fsfreeze-freeze and guest-fsfreeze-thaw to improve consistency. To Proxmox Backup Server the disks go up as fixed-size chunks, and dirty bitmaps can let Proxmox VE upload only the chunks that changed.

Running both for one job

I would keep the ZFS pool on the Proxmox host and bind-mount datasets into unprivileged containers for native Linux services such as Jellyfin or a Samba share. Docker Compose stacks go in a VM, as in the table. The TrueNAS alternative runs the pool in a VM with its disk controller passed through and shares it over NFS or SMB; the host mounts the share and bind-mounts it the same way — so the VM has to be up before anything mounts it. Either way vzdump skips the bind-mounted data. The pool needs its own backup.

Sources

Read 2026-09-26.

• Proxmox VE 9.2.12 manual, dated 2026-09-18: Proxmox Container Toolkit, pct.conf(5), pct(1), QEMU/KVM virtual machines, qm(1), Backup and restore, Storage
• Proxmox VE Roadmap, last edited 2026-09-23: release dates, kernel 7.0 in 9.2, OCI images in 9.1, container device passthrough in 8.1 and 8.2, nesting default in 7.1, volume-chain snapshots in 9.0
• pve-manager source: container Features dialog, Create VM and Create CT buttons, Create CT wizard
• Proxmox Backup Server technical overview
• Home Assistant installation
• Jellyfin hardware acceleration: Intel, NVIDIA
• Plex hardware-accelerated streaming
• TrueNAS, “Yes, You Can (Still) Virtualize TrueNAS”, published 2023-04-03, page metadata modified 2026-07-02
• Netgate: Virtualizing with Proxmox VE, Why FreeBSD?; OPNsense documentation
• WireGuard installation; Kernelnewbies, Linux 5.6

The Power & Cost Calculator prices a host that runs 24/7, and the UPS runtime calculator sizes the battery behind it.