LXC container (Proxmox)

A virtual machine moves into its own flat. An LXC container takes a room in yours: cheaper and quicker, and the walls are thinner.

The short answer

An LXC container is a Linux container that uses the kernel of its host instead of emulating a whole computer [1][2]. LXC is the userspace toolkit behind it, and Proxmox VE builds its containers on LXC and manages them with the pct tool [1][3]. Compared with a virtual machine (VM), a container costs little at runtime, but only Linux systems run in it and the separation is weaker [1][3]. Our assessment: use a container for trusted Linux services and a VM when you need another operating system or hard separation.

How it works

1. Kernel features, not a hypervisor. LXC contains processes with kernel namespaces, AppArmor and SELinux profiles, seccomp policies, chroots, capabilities and control groups (cgroups) [2]. A namespace makes processes see their own isolated instance of a global resource, such as process IDs, network devices, mount points or the hostname [4]. Cgroups limit CPU time, memory and access to device nodes [3].
2. What Proxmox VE adds. Containers start from template images, which are tar archives, and they use the same network and storage as VMs, the Proxmox firewall and the high-availability framework [3]. Windows or FreeBSD cannot run inside; only Linux distributions can [1][3]. Application containers from OCI images are a technology preview, and Proxmox converts them to the LXC stack [3].
3. Unprivileged by default. In an unprivileged container, root inside maps to an unprivileged user on the host through user namespaces. The LXC team considers this safe by design [3]. Privileged containers rely on AppArmor, seccomp and namespaces alone. The LXC team considers them unsafe and does not treat new escape exploits as CVE-worthy, so use them only in trusted environments [3].
4. Shared kernel, shared attack surface. Proxmox says full VMs provide better isolation and that this matters when containers go to unknown or untrusted people [3]. For maximum isolation and live migration, it still recommends nesting containers inside a QEMU VM [1][3].
5. Storage has sharp edges. A container has a root file system and up to 256 mount points [3]. Bind mounts are not managed by the storage system, cannot be snapshotted, and their contents are not part of vzdump backups; with unprivileged containers the user mapping can cause permission problems [3].
6. Support window. The LXC project lists LXC 6.0 as a long-term support release until 1 June 2029 and LXC 5.0 until 1 June 2027 (state at retrieval) [2].

A practical example

You want a small always-on service, such as an exporter or a reverse proxy, on a Proxmox host. You refresh the template list, look at the system images and create the container from a downloaded template [3]:

pveam update
pveam available --section system
pct create 200 local:vztmpl/<template-file>

In the wizard, keep "Unprivileged container" ticked, set cores and memory, and start it at boot if it should come up with the host [3]. We have not documented a Proxmox setup in our inventory (14 to 16 Oct 2026), so this is a generic walk-through and not a report from our own hardware.

Checklist

• Choose a VM when you need Windows, BSD or another kernel version [1][3].
• Keep the container unprivileged unless a service really needs more [3].
• Bind mount only directories reserved for that purpose, such as a folder under /mnt/bindmounts, and never /, /var or /etc [3].
• Back up bind-mounted data separately, because vzdump skips it [3].
• Set core and memory limits so one container cannot starve the others [3].
• Check old templates: pure cgroup v2 needs a recent enough systemd inside, and Proxmox VE 9.0 removed cgroup v1 [3].
• Remember that the kernel belongs to the host: updating it affects every container on that host.