Proxmox gives you two ways to run a workload: a full virtual machine or a lightweight LXC container. They look similar in the web UI — both get a VMID, a resource graph, and start/stop buttons — but under the hood they are completely different, and picking the wrong one means either wasting RAM or hitting a wall you can’t cross. This guide breaks down exactly when to reach for each.
If you just want the mechanics of building one, see Creating Your First Proxmox VM and the LXC networking guide. This post is about the decision before you click Create.
The one difference that explains everything: the kernel
Every other trade-off below flows from a single architectural fact. A QEMU/KVM virtual machine emulates a complete computer and boots its own operating system kernel on top of that virtual hardware. An LXC container shares the host’s kernel and only isolates the userland — the processes, filesystem, and network namespace.
That shared kernel is why containers are so cheap — there is no second kernel to boot, no hardware to emulate, and no fixed RAM carved out for a guest OS. It is also why they are more limited: no Windows, no custom kernel modules, and a thinner security boundary. Everything below is a consequence of this diagram.
The seven dimensions that decide it
1. Operating system
A VM runs anything — Windows, BSD, an old Linux with a 4.x kernel, even another hypervisor. An LXC container runs Linux only, and specifically a Linux userland compatible with the host kernel. If your workload is not Linux, the decision is already made: you need a VM.
2. Isolation and security
A VM’s boundary is the hypervisor — the guest sees only emulated hardware, so a breakout has to defeat KVM itself. A container shares the kernel, so its boundary is the Linux namespace and cgroup machinery, which is a larger attack surface. For anything untrusted or internet-facing, prefer a VM. For containers, always use unprivileged containers (the Proxmox default since 5.0), and reserve privileged containers for trusted workloads that genuinely need them. See the Proxmox security hardening guide for locking either down.
3. Resource overhead and density
This is where containers shine. A VM reserves its full assigned RAM and carries the memory cost of a running guest kernel; a container uses only what its processes actually touch. On a modest node you might run a handful of VMs but dozens of containers. If your goal is “many small Linux services on limited hardware,” containers win decisively — this is exactly why the whole Ollama LXC cluster runs in containers rather than VMs.
4. Performance
Closer than most people expect. Because a container has no hardware emulation, it runs at essentially native speed, while a KVM VM pays a small virtualization tax. IKUS Soft’s KVM vs LXC benchmark measured LXC at roughly 99–100% of bare-metal CPU throughput versus about 97–99% for KVM — a real but small gap on modern hardware. For I/O-heavy or latency-sensitive workloads the container edge is a bit larger, but for most homelab services either is fast enough.
5. Boot and lifecycle speed
A container starts in a second or two because there is no OS to boot; a VM takes tens of seconds to POST, load a bootloader, and initialize a kernel. If you spin guests up and down frequently — CI runners, throwaway test environments — containers make that loop much faster.
6. Snapshots, backups, and migration
Both support snapshots and scheduled backups through Proxmox Backup Server. VMs additionally support live migration between cluster nodes with no downtime; LXC containers require a brief restart to migrate (offline migration). If zero-downtime mobility across your Proxmox cluster matters, that is a point for VMs.
7. Hardware passthrough
Passing a GPU, an HBA, or a PCIe device through to the guest is a VM feature (VFIO/IOMMU). Containers can share host devices via bind mounts and cgroup device rules, which covers many cases (like /dev/dri for hardware transcoding), but true exclusive PCIe passthrough needs a VM.
Side-by-side
| Factor | VM (QEMU/KVM) | LXC container |
|---|---|---|
| Operating systems | Any (Windows, BSD, Linux) | Linux only |
| Kernel | Its own | Shared with host |
| Isolation | Hard (hypervisor) | Softer (namespaces/cgroups) |
| RAM overhead | Full reservation + guest kernel | Only what processes use |
| Density per node | Lower | Much higher |
| CPU performance | ~97–99% of bare metal | ~99–100% of bare metal |
| Boot time | Tens of seconds | 1–2 seconds |
| Live migration | Yes (no downtime) | Offline only (brief restart) |
| PCIe/GPU passthrough | Yes (VFIO) | Shared devices only |
| Best for | Non-Linux, untrusted, passthrough | Dense Linux services, low RAM |
The decision flowchart
For a typical single-service Linux workload — a database, a web app, a monitoring agent, a Git server — start with an unprivileged LXC container. It uses a fraction of the RAM and starts instantly. Reach for a VM only when you tick one of the boxes above. Most of a homelab ends up being containers with a few VMs for the exceptions.
Concrete examples from a real homelab
Pure-Linux services with no exotic kernel needs run as containers to keep RAM free. Wiki.js, Vaultwarden, and the Ollama nodes are all LXC — dozens of megabytes of overhead each instead of gigabytes.
A Windows guest, an OPNsense/pfSense firewall, or a machine that needs a dedicated GPU passed through all require a VM. The hard isolation and hardware passthrough simply aren’t available to a container.
If a service accepts connections from the public internet and you want a compromise contained to the guest, a VM’s hypervisor boundary is worth the extra RAM. Pair it with the Proxmox firewall.
Common mistakes
People coming from VMware or Hyper-V often make everything a VM. In Proxmox that wastes RAM fast — five VMs might exhaust a 16 GB node that could happily run twenty containers. Default to a container and justify the VM.
A privileged LXC container’s root maps to the host’s root. Combined with the shared kernel, that is a thin boundary for anything untrusted. Use unprivileged containers, or a VM, for workloads you don’t control.
What’s next
Pick your guest type, then build it: follow Creating Your First Proxmox VM for the VM path, or the LXC networking guide to get a container onto your network. Either way, set up Proxmox Backup Server so whichever you chose is protected.
Related posts:
- Creating Your First Proxmox VM — the full VM build walkthrough once you’ve decided on a VM.
- Proxmox LXC Networking — get a container onto your LAN with a static IP or DHCP.
- Proxmox Security Hardening — lock down privileged/unprivileged containers and VMs.
- Proxmox Backup Server in an LXC — back up both VMs and containers on a schedule.
- Building a Proxmox Cluster — enables live migration for VMs across nodes.
- Ollama LXC Cluster — a real example of choosing containers for density.