Learn LXC - History, Background & Why You Need It
This episode reviews the history of LXC from its initiation by IBM and kernel developers in 2008 to its governance under Linux Containers. You'll also understand why system containers are needed: far lighter than VMs, sharing the kernel, starting up in seconds, and requiring no hypervisor.
#Introduction
Now that our environment is ready from episode 0, it's time to understand why LXC exists. Every major technology is born from a real problem, and LXC is no exception. In episode 1 we trace its history back to 2008, its evolution into a project now governed under Linux Containers (linuxcontainers.org), and the concrete reasons why system containers are needed in the modern virtualization world.
The questions we'll answer: what was wrong with virtual machines that led kernel developers to create a new technology? Why is LXC different from Docker? And why is LXC still relevant when "container" is now synonymous with Docker? These answers determine when you should choose LXC in production.
#History and Philosophy
#Born from Namespaces and cgroups
LXC has been developed since 2008, initiated by IBM together with kernel developers. Its foundation isn't magical new code but two kernel mechanisms maintained directly inside Linux: namespaces (resource isolation: PID, mount, network, UTS, IPC, user) and cgroups (resource limiting). LXC was the first to combine the two into a usable interface for running a complete Linux distribution as a container.
Its philosophy is simple: why virtualize hardware when the kernel can already share itself safely? This is what sets OS-level virtualization apart from full virtualization — no emulation, no hypervisor, just a single kernel isolating multiple user spaces.
#Governed Under Linux Containers
After years of community and vendor stewardship, the project now lives under Linux Containers (linuxcontainers.org), the organization that also oversees LXD, Incus, and lxcfs. LXC itself is a low-level runtime written in C, whose main interfaces are the liblxc library and CLI tooling. This is the layer that underpins all the tools built on top of it.
#Release Timeline
LXC follows a two-yearly LTS release cycle with strict semver. As of this writing:
- LXC 7.0 LTS (released April 30, 2026) — the current LTS, supported until June 2031.
- LXC 6.0.6 LTS (released February 27, 2026) — now moving to slow maintenance, supported until June 2029.
- Earlier history: 6.0 (2024), 5.0 (2022), 4.0 (2019).
If you're reading this series in 2026, the "7.0 LTS" number we use throughout the episodes is the newest stable release.
#Why LXC
#System Container: A Whole Distro, Not Just an App
The most fundamental difference: LXC is a system container. It runs a complete Linux distribution — with its own init (sysvinit or systemd), its own user space, and its own services — just like a VM, but without a hypervisor. Each container has its own init as PID 1, can run SSH, cron, or a web server, and boots like a regular machine boot.
#Far Lighter than a VM
Because it shares the kernel with the host, LXC needs no hardware emulation, no guest BIOS/UEFI, and has no hypervisor overhead. The result:
- Startup in seconds — far faster than a VM boot that can take tens of seconds.
- Small memory footprint — only user space processes run, not an entire guest kernel.
- High density — one host can hold far more containers than VMs.
Think of it like an apartment building: a VM constructs a new building complete with its own foundation (kernel), while LXC divides one building (kernel) into isolated yet space-efficient units (containers).
#No Hypervisor, No Extra Layer
There's no QEMU/KVM to maintain. Containers run directly as isolated host processes using namespaces. This simplifies operations, reduces the hypervisor attack surface, and makes CPU and I/O overhead nearly zero.
#The Relationship with Docker
An interesting piece of history: Docker once used LXC as its runtime driver in early versions, until Docker 0.9 replaced it with its own libcontainer library and Docker 1.8 completed the transition. So LXC was the true "container" before the word was hijacked to mean application containers. Docker then became an application container — focused on a single process/application — while LXC remained a system container — focused on the distro and init.
Note
Don't confuse the two: LXC and Docker both use kernel primitives, but their models differ. LXC runs a full distro with its own init; Docker runs a single application without a full init. They complement each other — you can even run Docker inside LXC (we cover this in episodes 12 and 13).
#Position in the Virtualization Ecosystem
To position LXC, keep the spectrum in mind:
- Full virtualization (KVM/QEMU): strongest isolation, own kernel, large overhead.
- System container (LXC): full distro, shared kernel, small overhead.
- Application container (Docker): single application, shared kernel, most compact.
- Container manager (LXD/Incus): a high-level layer on top of LXC with an API and clustering.
LXC fills a unique middle ground: full initialization like a VM, yet efficient like a container. In episode 22 we'll compare it comprehensively with KVM, Docker, LXD, and Proxmox CT.
#Closing
Key takeaways:
- LXC has been developed since 2008 by IBM and kernel developers, now under Linux Containers.
- Built on namespaces + cgroups as a low-level C runtime (
liblxc). - LXC 7.0 LTS (Apr 2026) is the current LTS; 6.0.6 LTS is moving to slow maintenance.
- System containers run a whole distro with their own init — lighter than a VM, without a hypervisor.
- Docker once used LXC as its driver, before moving to application containers.
In the next episode 2 we'll break down LXC's core concepts and main architecture — how namespaces (PID, mount, network, UTS, IPC, user) and cgroups (cgroup2) work, along with the roles of liblxc, the CLI tooling, and the configuration directory structure. This is the anatomy that will explain every line of config we use in the episodes ahead.