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 simplifies backup, migration and sharing between containers.
- Keep the container rootfs small — OS and app, not data.
- Put working data on a separate ZFS volume with its own snapshots.
- 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 exactly like virtual machines.
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