LXD: System Containers for VM-Like Workflows

Sometimes you need a full Linux machine, not just an application process. A network lab where nodes need L2 presence for broadcast, multicast, or virtual IP failover. A storage lab to experiment with different filesystems.

Docker runs one app per container. It expects immutable, stateless, single-process workloads behind NAT. Less suited for these labs.

Hypervisors run full virtual machines with their own kernel. Complete isolation. Any OS. But they duplicate the kernel per instance. Slow boot times. High memory usage.

LXD runs system containers. It looks like a VM to you but behaves like a container to the kernel. Each instance gets its own systemd, direct filesystem (not layers), and network interfaces with L2 presence.

I used LXD to test high-availability Kubernetes with virtual IP failover on a single laptop. The nodes needed to broadcast VRRP packets and respond to ARP. LXD made this easy. Each instance gets its own IP and MAC with full L2 presence. Docker can only partially do this, and even that requires fiddly setup. VMs could, but with unnecessary overhead.

This talk covers:

• System containers and how they differ from Docker containers and VMs

• Why LXD fits network and storage lab use cases

• Real example: HA Kubernetes testing on a single laptop