How Debian Runs in Linux Containers and LXD

This article provides an overview of how the Debian operating system operates inside Linux Containers (LXC) and the LXD container manager. Running Debian within these environments differs fundamentally from running it in a traditional virtual machine; instead of emulating virtual hardware, the containerized Debian instance shares the host Linux kernel while maintaining an isolated, independent userspace. This guide explains the core architectural components—including kernel namespaces, control groups, root filesystems, and the init system—that allow Debian to function smoothly as a system container.

The Shared Kernel Architecture

Unlike hypervisors such as KVM or VirtualBox, LXC and LXD do not emulate hardware or boot a separate guest operating system kernel. When Debian runs inside an LXC or LXD container, it executes directly on the host machine's Linux kernel. System calls generated by Debian binaries inside the container are processed directly by the host kernel, eliminating hypervisor overhead and delivering near-bare-metal performance. Because Debian relies on standard Linux kernel interfaces, it is completely compatible with modern host Linux kernels.

Isolation Through Namespaces and Control Groups

The host kernel provides complete environment separation through two core Linux technologies:

  • Kernel Namespaces: Namespaces partition global system resources so that the Debian container operates with its own isolated view of the system.
    • PID Namespace: Gives Debian its own process tree, where the container's init process begins at PID 1.
    • Net Namespace: Provides Debian with independent virtual network interfaces, IP addresses, routing tables, and firewall rules.
    • Mount Namespace: Confines Debian to its own filesystem mount points.
    • User Namespace: Maps root privileges (UID 0) inside the container to an unprivileged UID on the host, preventing container escapes from gaining root access to the host system.
    • UTS and IPC Namespaces: Isolate hostnames and inter-process communication resources.
  • Control Groups (cgroups): Cgroups track and regulate resource consumption. LXD uses cgroups to allocate and limit CPU cores, memory limits, disk I/O, and network bandwidth for the Debian container.

The Debian Userspace and Image Initialization

Debian inside a container runs as a "system container," behaving much like a standalone physical server or virtual machine. LXD achieves this using pre-built Debian root filesystems generated through tools like debootstrap.

The root filesystem contains the standard Debian directory structure (/etc, /var, /usr, etc.) and the core utilities needed for Debian operation, including apt, dpkg, and standard system libraries. When an administrator launches a Debian container, LXD mounts this rootfs, creates the configured namespace boundaries, and executes the default init program.

Init System and Service Management

Most application containers (such as Docker) run a single foreground process. In contrast, LXC and LXD run Debian's full default init system, systemd.

When the container boots, systemd assumes PID 1 inside the container's PID namespace. It initializes standard system services, handles logging through journald, manages scheduled tasks via cron, and handles user authentication through sshd. LXC and LXD automatically configure required pseudo-filesystems—such as /sys, /proc, and /dev—allowing systemd to function inside the container without conflicting with the host system's hardware management.

Management via LXD

LXD acts as an orchestration and abstraction layer on top of LXC. It simplifies running Debian through:

  • Image Repositories: Providing official, cryptographically signed minimal Debian images (e.g., Debian 11 Bullseye, Debian 12 Bookworm).
  • Storage Pools: Managing Debian container root filesystems on various backends like ZFS, Btrfs, or LVM with support for instant snapshots and rollbacks.
  • Profiles and Networking: Applying reusable networking, security, and hardware access configurations across multiple Debian instances using standard bridges or OVN networks.