LXC
Linux Foundation-hosted open-source project
LXC (Linux Containers) is an operating-system-level virtualization technology that lets multiple isolated Linux systems, called containers, run on a single host kernel. Each container gets its own process tree, filesystem, network stack,…
Definition
LXC (Linux Containers) is an operating-system-level virtualization technology that lets multiple isolated Linux systems, called containers, run on a single host kernel. Each container gets its own process tree, filesystem, network stack, and set of users, achieved through kernel namespaces and cgroups rather than a hypervisor. LXC is often described as feeling like a lightweight virtual machine, since a container can boot an init system and run multiple services, unlike single-process application containers.
Overview
LXC emerged from the Linux kernel's namespace and control group (cgroup) work in the mid-2000s, giving administrators a way to partition one machine into several independent-looking systems without the overhead of full hardware virtualization. Because containers share the host kernel, they start in a fraction of a second and use only the memory their running processes actually need, rather than reserving RAM for a guest kernel and virtualized hardware. The `liblxc` library provides the underlying API, with `lxc-` command-line tools and language bindings (Python, Go, Lua) built on top. Mechanically, LXC combines several kernel features: PID, network, mount, UTS, IPC, and user namespaces isolate what a container can see, while cgroups cap and account for CPU, memory, disk I/O, and other resources. A container's root filesystem is typically a directory tree or an image-based rootfs, and templates or downloaded images bootstrap a minimal distribution inside it. Because there is no hypervisor layer, the security boundary depends entirely on correct namespace and capability configuration, which is why unprivileged containers, where root inside the container maps to an unprivileged user outside it, became a major focus of later LXC releases. LXC sits between chroot-style jails and full virtual machines in the isolation spectrum, and it predates and technically underlies much of today's container tooling. Docker's original release used LXC as its execution backend before switching to its own `libcontainer` runtime, and LXD (a separate management daemon built on LXC) added image handling, live migration, and a REST API for treating containers more like lightweight VMs. This distinguishes LXC from Docker's typical usage pattern: Docker containers usually run one application process per container and are built from layered images meant to be rebuilt and redeployed, while LXC containers commonly run a full init system and are treated more like persistent, stateful machines. In practice, LXC is used by hosting providers and self-hosters to offer VM-like Linux environments cheaply, by CI systems to spin up disposable isolated test environments, and by developers who want a full multi-service Linux instance without the resource cost of QEMU or VirtualBox. System administrators also use it to consolidate several lightly loaded servers onto one physical host while keeping each service's filesystem and process namespace separate. It remains a common substrate for platform-as-a-service systems that need to hand tenants something closer to a full OS than a single-binary container. The main limitation is that all containers on a host share one kernel, so a kernel vulnerability or panic affects every container, and a container cannot run a different operating system kernel than the host. Unprivileged containers mitigate but do not eliminate the risk of namespace-related privilege escalation. Networking and storage configuration also require more manual setup than application-container platforms provide out of the box. For running a single stateless application at scale with strong image-based deployment workflows, Docker or another OCI-compliant runtime is usually a better fit; for a genuinely isolated hardware or kernel boundary, a hypervisor-based VM is preferable to LXC.
Key Features
- Uses kernel namespaces and cgroups instead of a hypervisor for isolation
- Supports unprivileged containers that map container root to a host non-root user
- Can boot a full init system and run multiple services per container
- Shares the host kernel, giving near-instant startup and low memory overhead
- Provides `liblxc` with bindings for Python, Go, and Lua
- Underlies LXD, which adds image management and a REST API
- Offers fine-grained resource limits via cgroup CPU, memory, and I/O controls
- Historically served as Docker's original container execution backend