A shared kernel instead of full virtualisation
An LXC container does not boot its own kernel or BIOS — it shares the Proxmox host kernel, isolating processes via namespaces and cgroups. The result: sub-second startup, minimal memory overhead, and far more containers per host than full VMs.
| Feature | LXC container | QEMU/KVM VM |
|---|---|---|
| Kernel | Shared with host | Own, any kernel |
| Resource overhead | Very low | Higher (full VM) |
| Startup time | < 1 s | Seconds–minutes |
| Guest OS | Linux only | Linux, Windows, BSD… |
| Isolation | Kernel-level | Full (hardware) |
| Snapshots / backup | Yes (ZFS, PBS) | Yes (ZFS, PBS) |
Security: unprivileged by default
Proxmox creates containers as unprivileged and they should stay that way. The container's UID/GID are mapped onto an unprivileged host range (root inside the container = a regular user on the host), greatly limiting the impact of a potential container escape.
- Unprivileged: the default and recommended choice for almost all services — web, API, applications, databases.
- Privileged: only when you truly must (e.g. specific device access) — root in the container = root on the host, higher risk.
- Nesting / FUSE / keyctl: extra capabilities (e.g. Docker inside LXC) are enabled deliberately via "Features", not globally.
Note: workloads requiring their own kernel modules, a custom kernel, or a non-Linux OS (Windows) are not suitable for LXC — use a full QEMU VM there.
Bind mounts and persistent data
Containers use volumes on Proxmox storage (ZFS, LVM-thin, directory). Large, shared datasets are attached via a bind mount (pct set <id> -mp0 /tank/data,mp=/data) rather than kept in the container rootfs — this makes sharing data between containers easy. Note: bind mount contents are not included in vzdump or PBS backups and are not covered by Proxmox snapshots, and a container with a bind mount can only be migrated if the same path exists on the target node (shared=1). Back up and snapshot that data separately on the host, e.g. with ZFS dataset snapshots and replication.
- Keep the container rootfs small — OS and app, not data.
- Put working data on a separate host ZFS dataset — snapshots and replication (
zfs snapshot,zfs send) are done on the host, not with Proxmox tools. - With unprivileged containers, remember UID/GID mapping for bind mounts.
LXC in real infrastructure
LXC containers are backed up just like VMs — via Proxmox Backup Server (PBS) with deduplication and incremental copies, or via vzdump. Snapshot mode (on ZFS/LVM-thin) and suspend/stop are supported. Proxmox cluster HA covers containers too, with one difference: a running container cannot be live-migrated — Proxmox moves it with a restart migration (shut down, move, start again), so the downtime lasts as long as the container shutdown and restart, plus the data copy when it uses local disks.
Typical good fits for LXC: web servers and reverse proxies, APIs and microservices, CI runners, dev/test database instances, DNS/monitoring servers. For maximum tenant isolation or untrusted workloads — stick with full VMs.
In practice: in migrations we combine both worlds — critical and untrusted workloads as VMs, dense homogeneous Linux services as LXC. The result: higher density and lower cost without sacrificing security where it matters.
We'll plan your VM / LXC split
We'll help decide which workloads to move into lightweight containers and which to keep as full VMs — with PBS backup and HA.
⚡ Free consultation → Choosing a CPU type in Proxmox