Virtualisierung
LXC / LXD
LXC betreibt System-Container, die sich wie schlanke VMs verhalten; LXD (Fork Incus) ist die Management-Schicht mit API, Images, Storage und Netzwerk.
- Offen, Linux Containers
- System-Container, keine App-Container
- Sehr dicht und leichtgewichtig
- Unprivilegierte Container
- LXD und Fork Incus
LXC (Linux Containers) betreibt System-Container: Anders als ein Anwendungs-Container, der einen einzelnen Prozess kapselt, enthält ein System-Container ein vollständiges Linux-Userland mit eigenem Init, Diensten und Paketverwaltung und verhält sich damit wie eine sehr leichte virtuelle Maschine, ohne deren Overhead. LXD und der quelloffene Fork Incus sind die Management-Schicht darüber.
Dieser Artikel erklärt den Unterschied zwischen System- und Anwendungs-Containern, die Kernel-Grundlagen, das Sicherheitsmodell privilegierter und unprivilegierter Container, die Aufspaltung von LXD und Incus, Storage und Netzwerk, die zusätzliche VM-Verwaltung sowie die Grenzen, die sich aus dem geteilten Host-Kernel ergeben.
1. System-Container statt Anwendungs-Container
Der entscheidende Unterschied zu den verbreiteten OCI-/Docker-Containern liegt im Umfang: Ein System-Container bootet ein ganzes Linux-Userland samt Init-System, läuft also dauerhaft mit mehreren Diensten und wird wie ein Server administriert (SSH, Paketmanager, Logdienste). Ein Anwendungs-Container kapselt dagegen typischerweise genau einen Prozess. Beides hat seinen Platz; LXC zielt auf das Server-artige Szenario, nicht auf das Verpacken einzelner Microservices.
2. Die Kernel-Grundlagen
LXC ist eine schlanke Userspace-Schnittstelle zu den Isolationsfunktionen des Linux-Kernels. Mehrere Namespaces trennen Sicht und Ressourcen (Prozesse, Netzwerk, Mounts, Benutzer), cgroups begrenzen CPU, Speicher und I/O, und Capabilities, seccomp sowie AppArmor oder SELinux schränken ein, was im Container erlaubt ist. Es gibt keinen Hypervisor: Alle Container teilen sich denselben Host-Kernel, was sie extrem leichtgewichtig macht.
3. Privilegiert oder unprivilegiert
Sicherheitsentscheidend ist, wie die Benutzerkennungen abgebildet werden:
- Privilegierte Container die Root-Kennung im Container ist die Root-Kennung des Hosts. Die Dokumentation nennt sie ausdrücklich nicht root-sicher; ihr Schutz hängt allein an AppArmor, SELinux und seccomp.
- Unprivilegierte Container über User-Namespaces wird die Container-Root auf eine unprivilegierte Host-Kennung abgebildet (etwa Container-UID 0 auf Host-UID 100000). Selbst ein Ausbruch trifft dann nur einen rechtlosen Host-Benutzer. Dieses Modell gilt als sicher konstruiert und ist der Standard.
Unprivilegierte Container sind das Sicherheitsfundament von LXC: Sie bieten deutlich bessere Isolation als privilegierte, ohne den Overhead einer vollen VM.
4. LXD und Incus: eine Aufspaltung
LXC selbst ist die Low-Level-Laufzeit. Für den Alltag gibt es eine Management-Schicht mit REST-API, Image-Verwaltung, Profilen, Storage-Pools, Netzwerken und Clustering. Hier muss man heute zwei Wege kennen: LXD hat Canonical 2023 aus dem Linux-Containers-Projekt in die eigene Obhut übernommen und auf die AGPLv3 mit Contributor-Vereinbarung umgestellt. Daraufhin haben die ursprünglichen LXD-Entwickler den Fork Incus gestartet, wieder unter dem Linux-Containers-Projekt und der offenen Apache-2.0-Lizenz.
Praktisch heißt das: Beide werden aktiv gepflegt und sind sich technisch nah, aber getrennt. Mehrere Distributionen (etwa Debian) setzen inzwischen auf Incus, und es gibt ein Migrationswerkzeug von LXD zu Incus. Bei der Werkzeugwahl gehört dieser Unterschied bewusst entschieden.
5. Storage, Netzwerk und sogar VMs
LXD und Incus verwalten Speicher über Pools auf Basis von ZFS, Btrfs, LVM, einfachem Verzeichnis oder Ceph; ZFS und Btrfs erlauben dabei schnelle Snapshots und effizienten Transfer. Beim Netzwerk reichen die Optionen von einer einfachen Bridge bis zu Open Virtual Network (OVN) für software-definierte, geclusterte Netze. Bemerkenswert: Über dieselbe API und CLI lassen sich neben Containern auch vollwertige QEMU-VMs verwalten, eine Instanz wird einfach als Container oder als VM deklariert. Eine Live-Migration von Containern ist über CRIU möglich, in der Praxis aber spürbar eingeschränkt.
Container starten und auflisten (Incus, analog LXD)
incus launch images:debian/12 web01 # System-Container starten
incus list # Instanzen anzeigen
incus exec web01 -- bash # Shell im Container
incus launch images:debian/12 db01 --vm # dieselbe CLI, aber als VM6. Sicherheit: der geteilte Kernel
Der größte konzeptionelle Unterschied zur VM ist der gemeinsame Kernel. Eine Kernel-Lücke, die die Container-Grenze überwindet, betrifft potenziell alle Container und den Host. Damit ist die Isolation grundsätzlich schwächer als bei KVM/QEMU, wo jede VM einen eigenen Kernel-Speicherraum hat. Abgemildert wird das durch unprivilegierte Container, AppArmor/SELinux-Profile, seccomp-Filter und das Ablegen unnötiger Capabilities. Wo höchste Trennung gefordert ist, etwa zwischen Mandanten mit hohem Schutzbedarf, bleibt die VM die robustere Wahl.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Sehr dicht und leichtgewichtig, Start in Sekunden | gemeinsamer Host-Kernel: schwächere Isolation als VMs |
| Volles Linux-Userland je Container (wie eine leichte VM) | nur Linux-Gäste, kein Windows oder fremder Kernel |
| Unprivilegierte Container als sicherer Standard | Live-Migration (CRIU) nur eingeschränkt nutzbar |
| Flexible Storage-Backends (ZFS, Btrfs, Ceph) und OVN | Werkzeugwahl LXD oder Incus muss bewusst getroffen werden |
| Container und VMs über dieselbe API/CLI | kein Ersatz für VMs bei höchstem Trennungsbedarf |
Häufige Fragen zu LXC / LXD
LXC betreibt System-Container: ein vollständiges Linux-Userland mit eigenem Init und mehreren Diensten, das wie eine schlanke VM administriert wird. Docker und andere OCI-Container kapseln typischerweise einen einzelnen Anwendungsprozess. Beide teilen den Host-Kernel, verfolgen aber unterschiedliche Zwecke: LXC das Server-artige Szenario, Docker das Verpacken einzelner Anwendungen.
Beide verwalten LXC-Container (und VMs) und sind technisch nah. LXD wird seit 2023 von Canonical unter AGPLv3 mit Contributor-Vereinbarung gepflegt; Incus ist der Fork der ursprünglichen Entwickler unter dem Linux-Containers-Projekt und der offenen Apache-2.0-Lizenz. Mehrere Distributionen bevorzugen inzwischen Incus, und es gibt ein Migrationswerkzeug. Die Wahl hängt von Distribution, Lizenzpräferenz und Support ab.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
LXC / LXD im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.