LXC and Linux System Containers

LXC is a userspace interface for Linux containment features. It combines the liblxc library, command-line tools, and distribution templates to create system containers: isolated Linux userspaces that share the host’s kernel.

An LXC container can boot an init system, run several services, maintain persistent package state, and expose virtual network interfaces. The operating model therefore resembles a lightweight Linux machine more than an OCI application container. LXC remains a container runtime, however, because it does not boot a guest kernel or emulate hardware.

Position in the Virtualization Stack #

LXC coordinates kernel mechanisms rather than implementing isolation in one independent subsystem:

Each container receives a selected set of isolated kernel views:

Mechanism	Function in an LXC Container
Namespaces	Isolate process IDs, mounts, networking, IPC, hostnames, users, cgroup views, and clocks.
cgroups v2	Account for and limit CPU, memory, process count, I/O, and device access.
Capabilities	Split traditional root authority into independently removable privileges.
Seccomp	Filter the system calls available to container processes.
AppArmor or SELinux	Constrain host resources that remain visible through the shared kernel.
User namespaces	Map container UIDs and GIDs, including container root, to unprivileged host IDs.

Namespaces determine what a process can see, whereas cgroups determine how many resources it can consume. Capabilities, seccomp, and Linux security modules add independent restrictions because namespace separation alone is not a complete security policy.

LXC Components and the Wider Ecosystem #

Several related projects have distinct responsibilities:

Project	Responsibility
LXC	The `liblxc` C library, `lxc-*` lifecycle tools, configuration format, and distribution templates.
LXCFS	A FUSE filesystem that presents cgroup-aware `/proc` data, such as container-specific CPU and memory information.
Distrobuilder	Builds root filesystems and images from YAML definitions.
Incus	A higher-level system-container and virtual-machine manager that uses LXC as its default container runtime.

Incus adds a daemon and REST API, managed images, profiles, storage pools, networks, projects, clustering, and migration. LXC itself remains useful when a host needs direct, local container control without a management daemon.

LXD and Incus must not be treated as alternate names for LXC. LXD originated as a manager built above LXC. Incus later forked from LXD and is now maintained under the Linux Containers project.

Container Lifecycle #

The download template retrieves a distribution root filesystem from the Linux Containers image server. The following commands assume that the host distribution has installed LXC and configured the UID/GID ranges and networking required for the invoking user:

lxc-create --name web01 --template download -- \
  --dist debian --release trixie --arch amd64

lxc-start --name web01 --daemon
lxc-info --name web01
lxc-attach --name web01

lxc-stop --name web01
lxc-destroy --name web01

The default system-wide container location is /var/lib/lxc/<name>/. A container directory contains its configuration and root filesystem unless the root filesystem uses another storage backend. Relevant lifecycle tools include:

lxc-ls --fancy to list containers and their states;
lxc-console to connect to a configured console;
lxc-freeze and lxc-unfreeze to suspend and resume execution through the cgroup freezer;
lxc-copy to copy or snapshot a container when the backing store supports the requested operation; and
lxc-monitor and lxc-wait to observe state changes.

LXC configuration uses key = value entries. A simplified configuration can combine identity, storage, networking, UID mapping, and resource controls:

ini

lxc.uts.name = web01
lxc.rootfs.path = dir:/var/lib/lxc/web01/rootfs

lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up

lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536

lxc.cgroup2.memory.max = 2147483648
lxc.cgroup2.pids.max = 1024
lxc.cgroup2.cpu.max = 200000 100000

Configuration is host-dependent. UID/GID ranges must agree with subordinate-ID allocation, network devices must exist, and cgroup values must be supported by the running kernel. LXC passes many cgroup settings to the kernel rather than normalizing them into a runtime-specific resource model.

Privileged and Unprivileged Containers #

The UID mapping determines whether container root is also host root:

In a privileged container, UID 0 inside the container is UID 0 from the host kernel’s perspective. Namespaces, capability removal, seccomp, and mandatory access control can reduce access, but upstream LXC explicitly does not consider privileged containers root-safe.
In an unprivileged container, UID 0 maps to a nonzero host UID, such as 100000. User namespaces therefore prevent container root from owning ordinary host resources.

For example, the mapping u 0 100000 65536 maps container UIDs 0 through 65535 to host UIDs 100000 through 165535. newuidmap and newgidmap install mappings authorized by /etc/subuid and /etc/subgid. Unprivileged networking can also use the narrowly scoped lxc-user-nic helper to create an allowed virtual interface.

Unprivileged containers should be the default for workloads that do not require host-level identity or device access. User namespaces do not remove the shared-kernel risk: a kernel vulnerability reachable through an allowed system call can still cross the container boundary.

Storage #

The root filesystem can be a directory, image file, block device, or supported copy-on-write backend. lxc-create supports backing stores including directory, Btrfs, LVM, loop files, ZFS, and Ceph RBD, subject to build and host configuration.

Backend selection changes operational behavior:

Backend	Operational Property
Directory	Minimal setup and direct file access, but copying a container requires copying its files.
Btrfs or ZFS	Native snapshots and efficient clones when the host filesystem is configured accordingly.
LVM thin pool	Block-device isolation with thin provisioning and snapshot support.
Loop file	A filesystem image without a dedicated logical volume, at the cost of another storage layer.
Ceph RBD	Network-backed block storage for hosts already integrated with Ceph.
OverlayFS	A writable upper layer over one or more lower layers; useful for ephemeral or cloned roots.

Idmapped mounts can expose filesystem ownership through the container’s UID/GID mapping without recursively changing every inode. Kernel, filesystem, and LXC support must all be checked before adopting them.

Networking #

LXC can create several network interface types:

veth creates an Ethernet pair and commonly connects the host end to a bridge such as lxcbr0;
vlan creates a VLAN interface on a host parent;
macvlan and ipvlan attach containers to a parent interface with different Layer 2 or Layer 3 semantics;
phys moves a physical interface into the container’s network namespace;
empty creates an isolated network namespace with only loopback; and
none retains the host network namespace.

A bridge provides connectivity, not tenant security. Containers attached to the same Layer 2 segment can attempt address spoofing or send malicious control traffic. Untrusted tenants therefore require bridge separation, host-side filtering, and explicit IPv6 Router Advertisement controls.

Resource and Device Controls #

LXC 7.0 supports cgroups v2 only. Operators can write controller values through lxc.cgroup2.*, for example:

memory.max and memory.high for memory limits and pressure;
cpu.max and cpuset.cpus for CPU bandwidth and placement;
pids.max to contain fork bombs; and
I/O controller settings for supported block devices.

No resource ceiling is implied merely because a process runs in a container. Without explicit limits, a container can compete for the host’s available memory, CPU, process IDs, I/O, and network capacity.

Device access also requires care. On cgroups v2, device filtering is enforced with cgroup-attached eBPF programs rather than the cgroups v1 device-control files. Passing through GPUs, disks, or other devices expands the attack surface because container processes then interact with host drivers.

Security Model #

LXC isolation is defense in depth rather than a single boundary. A production configuration should:

Use unprivileged containers with nonoverlapping UID/GID ranges.
Apply memory, CPU, process-count, and I/O controls because LXC does not impose complete limits by default.
Drop capabilities that the workload does not need.
Load an appropriate seccomp policy and retain AppArmor or SELinux confinement where the host distribution supports it.
Minimize bind mounts, device passthrough, shared namespaces, and writable host paths.
Separate untrusted network segments and filter host-facing traffic.
Keep the host kernel and LXC packages updated because every container shares the host kernel.

Overlapping subordinate-ID maps should be avoided between mutually untrusted containers. Kernel accounting and limits associated with the same host UID can otherwise create interference between containers.

Nesting another container runtime inside LXC requires additional privileges, mount behavior, cgroup delegation, or security-policy exceptions. Running Docker inside an LXC container can separate lifecycle and configuration state, but it does not create a VM-grade security boundary because both layers ultimately use the same host kernel.

LXC, OCI Containers, and Virtual Machines #

LXC, OCI runtimes, and virtual machines solve different packaging and isolation problems:

Property	LXC System Container	OCI Application Container	Virtual Machine
Typical unit	Linux userspace with init and several services	Application process and dependencies	Complete operating system
Kernel	Shared with host	Shared with host	Separate guest kernel
Image model	Distribution rootfs or custom system image	Content-addressed, layered OCI image	Virtual disk and machine image
State model	Commonly persistent and mutable	Commonly rebuilt and replaced	Commonly persistent
Management	Direct `lxc-*` tools or a manager such as Incus	Docker, containerd, CRI-O, Kubernetes, and related tooling	Hypervisor and VM-management tooling
OS constraint	Linux userspace compatible with the host kernel	Linux userspace compatible with the host kernel	Guest OS supported by the virtual hardware
Isolation boundary	Namespaces, user mapping, cgroups, and security policy	Namespaces, user mapping, cgroups, and security policy	Hardware virtualization and a hypervisor

Choose LXC when the workload is operated as a Linux machine: it needs an init system, several cooperating daemons, in-place package management, or an OS-level integration-test environment.

Choose an OCI runtime when the deployment unit is an application image and the delivery system depends on registries, layered builds, immutable replacement, or Kubernetes.

Choose a virtual machine when the workload needs another kernel, a non-Linux guest, kernel-module control, or a stronger boundary for adversarial tenants. Performance must be measured for the actual workload rather than inferred from the category alone.

Project Status #

As of August 2026, LXC 7.0 is the current long-term support series and is scheduled for support through June 2031. LXC 6.0 remains supported through June 2029, and LXC 5.0 through June 2027.

LXC 7.0 removes cgroups v1 support and support for kernels without pidfds or the new mount API. Deployments upgrading from older LXC releases must therefore validate host-kernel capabilities and migrate remaining cgroups v1 configuration.

Version numbers and support dates describe upstream releases. Linux distributions can apply separate package versions, backports, and maintenance policies.