LXC-Container (Proxmox)

Eine virtuelle Maschine zieht in eine eigene Wohnung. Ein LXC-Container bekommt ein Zimmer in deiner: günstiger und schneller, aber die Wände sind dünner.

Kurz gesagt

Ein LXC-Container ist ein Linux-Container, der den Kernel seines Hosts nutzt, statt einen ganzen Rechner nachzubilden [1][2]. LXC ist das Userspace-Werkzeug dahinter, und Proxmox VE baut seine Container auf LXC auf und verwaltet sie mit dem Werkzeug pct [1][3]. Gegenüber einer virtuellen Maschine (VM) kostet ein Container zur Laufzeit wenig, aber es laufen nur Linux-Systeme darin, und die Trennung ist schwächer [1][3]. Unsere Einschätzung: Nimm einen Container für vertrauenswürdige Linux-Dienste und eine VM, wenn du ein anderes Betriebssystem oder harte Trennung brauchst.

So funktioniert’s

1. Kernel-Funktionen, kein Hypervisor. LXC sperrt Prozesse mit Kernel-Namespaces, AppArmor- und SELinux-Profilen, Seccomp-Regeln, Chroots, Capabilities und Control Groups (cgroups) ein [2]. Ein Namespace lässt Prozesse ihre eigene, abgeschottete Instanz einer globalen Ressource sehen, etwa Prozess-IDs, Netzwerkgeräte, Einhängepunkte oder den Hostnamen [4]. Cgroups begrenzen CPU-Zeit, Speicher und den Zugriff auf Gerätedateien [3].
2. Was Proxmox VE ergänzt. Container starten aus Vorlagen, das sind tar-Archive, und sie nutzen dasselbe Netzwerk und denselben Speicher wie VMs, die Proxmox-Firewall und das Hochverfügbarkeits-Framework [3]. Windows oder FreeBSD laufen darin nicht, nur Linux-Distributionen [1][3]. Anwendungscontainer aus OCI-Images sind eine Technologievorschau, und Proxmox wandelt sie in den LXC-Stack um [3].
3. Standardmäßig unprivilegiert. In einem unprivilegierten Container wird root innerhalb über User-Namespaces auf einen unprivilegierten Benutzer des Hosts abgebildet. Das LXC-Team hält das für sicher im Entwurf [3]. Privilegierte Container verlassen sich allein auf AppArmor, Seccomp und Namespaces. Das LXC-Team hält sie für unsicher und behandelt neue Ausbruchslücken nicht als CVE-würdig, also setze sie nur in vertrauenswürdigen Umgebungen ein [3].
4. Geteilter Kernel, geteilte Angriffsfläche. Proxmox schreibt, dass vollständige VMs besser isolieren und dass das zählt, wenn Container an unbekannte oder nicht vertrauenswürdige Personen gehen [3]. Für maximale Isolation und Live-Migration empfiehlt es weiterhin, Container in einer QEMU-VM zu verschachteln [1][3].
5. Beim Speicher gibt es Kanten. Ein Container hat ein Root-Dateisystem und bis zu 256 Einhängepunkte [3]. Bind-Mounts verwaltet das Speichersystem nicht, man kann sie nicht per Snapshot sichern, und ihr Inhalt gehört nicht zu vzdump-Backups; bei unprivilegierten Containern kann die Benutzerzuordnung Rechteprobleme verursachen [3].
6. Supportzeitraum. Das LXC-Projekt führt LXC 6.0 als Langzeit-Release bis zum 1. Juni 2029 und LXC 5.0 bis zum 1. Juni 2027 (Stand beim Abruf) [2].

Ein Praxisbeispiel

Du willst einen kleinen Dauerdienst, etwa einen Exporter oder einen Reverse Proxy, auf einem Proxmox-Host betreiben. Du aktualisierst die Vorlagenliste, schaust dir die System-Images an und legst den Container aus einer heruntergeladenen Vorlage an [3]:

pveam update
pveam available --section system
pct create 200 local:vztmpl/<template-file>

Im Assistenten lässt du „Unprivileged container“ angehakt, setzt Kerne und Speicher und aktivierst „Start at boot“, wenn der Container mit dem Host hochkommen soll [3]. Ein Proxmox-Setup haben wir in unserem Inventar (14. bis 16. Okt. 2026) nicht dokumentiert, deshalb ist das ein allgemeiner Ablauf und kein Bericht von unserer eigenen Hardware.

Prüfliste

• Wähle eine VM, wenn du Windows, BSD oder eine andere Kernelversion brauchst [1][3].
• Lass den Container unprivilegiert, solange ein Dienst nicht wirklich mehr braucht [3].
• Binde nur Verzeichnisse ein, die dafür reserviert sind, etwa einen Ordner unter /mnt/bindmounts, und niemals /, /var oder /etc [3].
• Sichere bind-gemountete Daten getrennt, denn vzdump überspringt sie [3].
• Setze Grenzen für Kerne und Speicher, damit ein Container die anderen nicht aushungert [3].
• Prüfe alte Vorlagen: Reines cgroup v2 braucht ein ausreichend neues systemd im Container, und Proxmox VE 9.0 hat cgroup v1 entfernt [3].
• Denke daran, dass der Kernel dem Host gehört: Ein Update wirkt auf jeden Container dieses Hosts.