LXC — System-Level Containers on Linux (practical notes)
What it is
LXC provides operating-system–level virtualization using the Linux kernel’s namespaces and cgroups. There is no guest kernel boot, so containers start very fast and share the host kernel. In practice it is used for lightweight isolation, quick testing, and small services where a full VM would be excessive. LXC stays close to the Linux layer and is script-friendly, which appeals to admins who prefer low-level control instead of large management platforms.
How it works
LXC sets up a container root filesystem, applies namespace isolation (PID, mount, network, UTS, IPC, user), and enforces limits through cgroups. Networking is usually handled with veth pairs bridged to the host, but macvlan or ipvlan can also be used. Storage backends may be plain directories or advanced drivers like btrfs, ZFS, or LVM-thin for snapshot support. Security can be hardened with unprivileged containers, AppArmor, SELinux, and seccomp filters. Configurations are plain text files, easy to edit or version control.
Technical profile
Area | Details |
Isolation model | Namespaces + cgroups, shared host kernel |
Security options | Unprivileged containers, AppArmor/SELinux, seccomp |
Networking | veth + bridge, macvlan/ipvlan, DHCP or static |
Storage backends | Directory, LVM-thin, btrfs, ZFS |
Management | CLI tools (lxc-*), config files |
Images | Rootfs templates, tarballs, bootstrap tools |
Host/Guest OS | Linux host, Linux guests |
Footprint | Low memory use, near-instant startup |
Typical use | Labs, CI/CD runners, lightweight services |
Installation guide
1. Install LXC packages and any required storage drivers.
2. Prepare a network bridge (for example br0) and configure IP addressing.
3. Create a container rootfs using a template or bootstrap tool.
4. Adjust container config: resource limits, mounts, capabilities.
5. Start the container and attach to it for setup.
6. Use snapshots or clones to replicate golden images.
Usage scenarios
– High-density Linux services that don’t need a dedicated kernel.
– Short-lived CI/CD or test containers.
– Isolating legacy apps in their own rootfs.
– Network and topology labs using bridged veth devices.
Limitations
– Shared kernel means no custom kernels per container.
– Non-Linux guests are not supported.
– Security isolation is weaker than with full hypervisors.
– Tooling is low-level; fewer built-in features compared to Docker or Proxmox.
Comparison snapshot
Tool | Strengths | Best fit |
LXC | Very lightweight, fast start, scriptable | Dense Linux workloads, CI, labs |
LXD | Higher-level API/daemon, clustering, images | Ops teams needing lifecycle management |
Docker/Podman | OCI images, registry integration | Application packaging, developer environments |
KVM/QEMU | Full virtualization, custom kernels | Mixed OS workloads, stronger isolation |