LXC, VM oder Docker auf Proxmox: die Entscheidungslogik

/01Drei Betriebsformen, ein Unterschied im Kernel

Proxmox VE kennt zwei Gasttypen: den KVM-Gast, also die virtuelle Maschine mit eigenem Kernel, und den LXC-Container, der den Kernel des Hosts mitbenutzt. Docker ist kein dritter Gasttyp. Es ist eine Laufzeitumgebung für Anwendungscontainer, die innerhalb eines der beiden Gasttypen laufen muss. Wer in der Weboberfläche nach einem „Docker-Knopf" sucht, findet keinen, und das ist Absicht.

Der Unterschied liegt beim Kernel, und aus ihm folgt fast alles andere. Eine VM bringt ihren Kernel mit; deshalb läuft in ihr Windows, FreeBSD oder ein Linux mit anderem Kernelstand als der Host. Ein Container bringt nur Userland mit; deshalb startet er in Sekunden, braucht keinen eigenen Arbeitsspeicher für einen zweiten Kernel und sieht den Host näher, als vielen lieb ist. Die Proxmox-Dokumentation formuliert es trocken: Container sind eine leichtgewichtige Alternative zu VMs, die Laufzeitkosten sind „gering, meist vernachlässigbar", und die Nachteile sind, dass nur Linux-Distributionen laufen und der Zugriff auf Host-Ressourcen aus Sicherheitsgründen eingeschränkt werden muss.

Was die Sache nicht ist: eine Frage der Leistung. In der Praxis entscheidet selten der Durchsatz zwischen LXC und VM, sondern die Frage, was passiert, wenn etwas schiefgeht. Der Kernel ist die Grenze, die ein Angreifer überwinden müsste. Bei der VM liegt sie zwischen Gast und Hypervisor, beim Container liegt sie in Namespaces, cgroups, AppArmor und seccomp. Das ist keine Formsache.

/02LXC: geteilter Kernel, unprivilegiert als Regel

Ein LXC-Container ist in Proxmox ein Systemcontainer: ein vollständiges Debian, Ubuntu, Alma oder Rocky mit eigenem systemd, eigenem Netz und eigenem Dateisystem, nur eben ohne eigenen Kernel. Genau dafür wurde pct gebaut, und genau dafür taugt es: Reverse-Proxy, DNS-Resolver, Monitoring-Agenten, kleine Webanwendungen, interne Werkzeuge, die man in einer Viertelstunde aufsetzt und die keine Wochenendmigration brauchen.

Die wichtigste Einstellung fällt bei der Erstellung: unprivilegiert oder privilegiert. Unprivilegierte Container bilden die Root-Kennung 0 im Container per User-Namespace auf einen unprivilegierten Nutzer des Hosts ab. Bricht ein Prozess aus, landet er als niemand auf dem Host; die Dokumentation zitiert das LXC-Team mit dem Satz, unprivilegierte Container seien „safe by design". Seit einigen Versionen ist das der Standard bei der Erstellung. Der Preis: Ein systemd im Container muss mindestens Version 220 haben, Bind-Mounts vom Host bringen Rechteprobleme mit, und Quotas funktionieren nur im privilegierten Container auf ext4-Abbildern.

Privilegierte Container stützen sich allein auf AppArmor, seccomp und Namespaces. Das LXC-Team hält diese Bauform für unsicher und vergibt für neue Ausbrüche daraus keine CVE; die Dokumentation zieht die Konsequenz, dass privilegierte Container nur in vertrauenswürdigen Umgebungen laufen sollen. Wer die Option heute noch anhakt, tut es meist wegen eines NFS-Mounts, eines USB-Geräts oder eines alten Installationsskripts. Jeder dieser Gründe lässt sich anders lösen: Der Mount gehört auf den Host und per Bind-Mount in den Container, das Gerät in eine VM, das Skript in die Tonne.

Zwei Betriebseigenschaften prägen den Alltag. Erstens gibt es keine Live-Migration für Container. Die Dokumentation nennt technische Gründe und bietet die Restart-Migration an: herunterfahren, verschieben, starten, mit einem Stillstand von „einigen hundert Millisekunden" und einem Abbruch-Timeout von 180 Sekunden. Für einen Proxy ist das egal, für einen Dienst mit langen Sitzungen nicht. Zweitens hängt der Container am Kernel des Hosts. Ein Kernel-Update auf dem Knoten ist ein Kernel-Update für jeden Container darauf, ob er will oder nicht; wie wir Kernel-Wechsel im Cluster staffeln, steht im Artikel zur Kernel-Update-Strategie für Proxmox-Cluster.

/03KVM-VM: Isolation, Live-Migration, Windows

Die virtuelle Maschine ist die Betriebsform ohne Fußnoten. Sie läuft mit jedem Betriebssystem, das QEMU startet, sie hat ihren eigenen Kernel und damit ihre eigenen Sicherheitsupdates, und sie lässt sich im laufenden Betrieb auf einen anderen Knoten verschieben. Der Befehl dafür ist qm migrate <vmid> <ziel> --online; die Weboberfläche wählt bei laufender VM die Live-Migration von selbst. Voraussetzung sind gemeinsamer Speicher oder eine Speicher-Mitmigration, keine durchgereichten Geräte und dieselbe CPU-Architektur. Zwischen Intel- und AMD-Hosts gibt die Dokumentation keine Garantie, und die Wahl des CPU-Typs entscheidet mit: host bringt alle Flags, verträgt aber keine heterogenen Knoten; der Standard der Oberfläche, x86-64-v2-AES, läuft auf allem ab Westmere.

Der Preis der VM ist ein vollständiges Betriebssystem je Gast: eigener Kernel, eigener Speicherverwalter, eigener Bootvorgang, eigenes Patch-Management. Wer zwölf kleine Dienste in zwölf VMs packt, betreibt zwölf Betriebssysteme. Das ist kein Argument gegen VMs, aber eines dafür, sie mit Bedacht zu schneiden: Datenbank, Fachanwendung, Domänencontroller, alles mit Fremdcode, alles mit Windows, alles, was migrieren können muss.

Für Windows kommt ein Sonderfall dazu. Windows 11 und Server 2025 wollen UEFI, Secure Boot und ein TPM; Proxmox liefert alle drei als virtuelle Geräte, und seit Version 9.1 liegt der TPM-Zustand auf Wunsch im qcow2-Format, sodass Snapshots auch auf NFS- oder CIFS-Speicher funktionieren. Ein Windows im Container gibt es nicht und wird es nicht geben; wer die Frage stellt, hat die Antwort schon.

/04Docker und Podman: in die VM, nicht in den Container

Die Frage „Docker in LXC oder in einer VM" ist im Proxmox-Forum ein Dauerbrenner, und die Antwort dort schwankt mit dem Tagesgeschmack. Die Dokumentation schwankt nicht. Sie empfiehlt für Anwendungscontainer, die maximale Isolation oder Live-Migration brauchen, das Verschachteln in einer QEMU-VM als weiterhin gültige Praxis. Und in der Optionsreferenz steht bei keyctl der Satz, den man kennen sollte, bevor man den ersten Docker-Host als Container anlegt: Die Option sei nötig, um Docker in einem unprivilegierten Container zu betreiben, sie sei im Kern ein Workaround für systemd-networkd, und im Ergebnis wähle man zwischen systemd-networkd und Docker.

Technisch geht es trotzdem. Mit features: nesting=1,keyctl=1 startet Docker in einem unprivilegierten Container, und für einen Bastelrechner ist dagegen nichts einzuwenden. Im Betrieb kaufen Sie sich damit drei Eigenschaften ein, die nicht in der Anleitung stehen, sondern im Störungsprotokoll. Nesting legt laut Dokumentation procfs und sysfs des Hosts im Gast offen. Das Overlay-Dateisystem von Docker läuft auf einem Dateisystem, das selbst schon ein Container-Rootfs ist, mit allen Eigenheiten von ZFS-Subvolumes oder ext4-Abbildern darunter. Und jedes Kernel-Update des Hosts ist ein Kernel-Update für die Docker-Engine, ohne dass jemand die Kompatibilität getestet hätte. Erfahrungswert aus unseren Übernahmen: Die Docker-in-LXC-Umgebungen, die nach einem Proxmox-Upgrade nicht mehr starteten, hatten alle dieselbe Vorgeschichte, nämlich ein Forum-Tutorial und keinen Grund, der sich im Nachhinein noch rekonstruieren ließ.

Unsere Empfehlung ist unspektakulär: eine schlanke Linux-VM je Docker-Umgebung, mit Docker Compose oder Podman, mit dem QEMU-Guest-Agent für konsistente Sicherungen, mit Live-Migration und eigenem Kernel. Wer viele Compose-Stacks hat, betreibt zwei oder drei solcher VMs nach Vertrauensstufe getrennt, nicht eine je Stack. Ab wann aus mehreren Docker-Hosts ein Kubernetes werden sollte, haben wir im Artikel Docker und Kubernetes on-premise beantwortet; die Kurzfassung lautet dort wie hier: später, als die Anbieter es Ihnen erzählen.

/05OCI-Images seit Proxmox VE 9.1: Stand und Grenzen

Am 19. November 2025 hat Proxmox mit Version 9.1 eine Funktion eingeführt, die die Docker-Frage verschiebt, aber nicht beantwortet: LXC-Container lassen sich aus OCI-Images erzeugen. OCI, die Open Container Initiative, ist das Format, in dem Docker-Hub, GitHub Container Registry und alle anderen Registries ihre Images verteilen. Proxmox kann ein solches Image manuell hochladen oder per Knopf „Pull from OCI registry" aus einer Registry holen; es liegt dann wie eine Vorlage auf dem Speicher, und pct create baut daraus einen Container. Das Image wird dabei in den LXC-Stack übersetzt, den Proxmox ohnehin verwendet. Es läuft also keine Docker-Engine, nirgends.

Die Release-Notes unterscheiden zwei Fälle, und die Unterscheidung ist wichtig. Systemcontainer aus geeigneten OCI-Images, etwa ein debian:trixie mit systemd darin, gelten als vollwertig. Anwendungscontainer aus OCI-Images, also das typische Ein-Prozess-Image mit einem Webserver oder einer Datenbank, sind seit 9.1 und auch in Version 9.2 vom 21. Mai 2026 „Technology Preview". Die 9.2-Notes zeigen, woran gearbeitet wird: Die User-Eigenschaft des Images wird jetzt beachtet, unter /dev/shm liegt ein tmpfs wie in der OCI-Laufzeitspezifikation, und die Mount-Point-Optionen idmap und keepattrs helfen bei Images, die bestimmte Verzeichnisrechte erwarten. Das sind Feinheiten, die man erst bemerkt, wenn das dritte Image nicht startet.

Was fehlt, steht in der Roadmap, nicht in den Release-Notes: OCI-Unterstützung soll „reifen", und ein deklaratives Mehr-Container-Modell nach der Compose-Spezifikation ist als Ziel formuliert. Heute gibt es weder ein compose.yaml für Proxmox noch Netze zwischen Anwendungscontainern, wie Docker sie anlegt, noch die Volumes-Semantik. Ein einzelner Dienst aus einem OCI-Image als LXC-Container: ja, mit Vorbehalt. Ein Stack aus fünf Images mit gemeinsamem Netz: heute weiterhin in der Docker-VM. Wir setzen OCI-Container produktiv derzeit nur für Systemcontainer ein und beobachten den Rest; wer den Stand nachprüfen will, findet ihn in den Release-Notes der jeweiligen Version, nicht in Blogbeiträgen vom Vorjahr.

/06Sicherheitsgrenzen im Vergleich

Die Sicherheitsfrage hat drei Ebenen, und man sollte sie getrennt betrachten: was ein Angreifer im Gast erreicht, was er beim Ausbruch erreicht, und wer dafür Patches liefert.

Im Gast ist die Lage in allen drei Formen gleich. Ein verwundbarer Webserver ist verwundbar, ob in LXC, VM oder Docker. Der Unterschied beginnt beim Ausbruch. Aus einer VM heraus muss der Angreifer QEMU oder KVM angreifen; das ist möglich, kommt vor und wird als CVE behandelt. Aus einem unprivilegierten Container heraus muss er den Kernel angreifen und landet dann zunächst als unprivilegierter Nutzer auf dem Host; auch das gilt als Kernel-Fehler mit CVE. Aus einem privilegierten Container heraus muss er AppArmor oder seccomp umgehen, und dafür gibt es laut LXC-Team keine CVE und keine schnelle Korrektur. Das ist der Grund, warum wir privilegierte Container in Kundenumgebungen als Befund führen, nicht als Geschmacksfrage.

Wie nah der geteilte Kernel ist, hat Proxmox im Mai 2026 selbst vorgeführt: Die 9.2-Notes nennen einen seccomp-Filter gegen eine lokale Rechteausweitung über AF_ALG-Sockets in Containern, veröffentlicht als Sicherheitshinweis PSA-2026-00018-1. Für VMs war das kein Thema. Für jeden Container auf einem nicht aktualisierten Host war es eines, und zwar für alle gleichzeitig. Wer Container betreibt, betreibt den Host-Kernel als gemeinsames Sicherheitsgut; wie man den Host selbst härtet, steht im Artikel Linux-Server härten.

Docker fügt eine vierte Ebene ein: die Engine mit Root-Rechten im Gast, den Socket, den jedes Verwaltungswerkzeug gern eingebunden hätte, und Images unbekannter Herkunft. In einer VM bleibt der Schaden im Gast. In einem LXC-Container mit Nesting liegen procfs und sysfs des Hosts eine Schicht darunter offen. Das ist kein Ausbruch, aber es ist eine Menge Information über den Host, die ein Anwendungscontainer nie sehen sollte.

/07Sicherung und Snapshots je Betriebsform

Die Sicherung unterscheidet sich zwischen VM und Container stärker als die Oberfläche vermuten lässt, weil vzdump je Gasttyp andere Modi fährt. Für VMs gibt es drei Modi, von denen einer zählt: der Snapshot-Modus nutzt das Live-Backup von QEMU, kopiert Blöcke bei laufender Maschine, braucht keinen snapshotfähigen Speicher und ruft bei aktivem Guest-Agent fsfreeze im Gast auf, damit das Dateisystem konsistent ist. Stop-Modus gibt es für höchste Konsistenz, Suspend-Modus nur noch aus Kompatibilitätsgründen; die Dokumentation rät selbst davon ab.

Für Container heißt Snapshot-Modus etwas anderes: Der Container wird kurz eingefroren, der Speicher darunter legt einen Snapshot an, der Inhalt wird als Archiv gesichert, der Snapshot verschwindet. Das setzt voraus, dass alle gesicherten Volumes auf einem snapshotfähigen Speicher liegen, also ZFS, LVM-thin oder Ceph. Liegt der Container auf einem Verzeichnis ohne Snapshot-Fähigkeit, fällt vzdump in den Suspend-Modus zurück: einmal rsync bei laufendem Container, einfrieren, zweites rsync für die Änderungen, weiterlaufen. Das braucht zusätzlichen Platz für die Zwischenkopie und einen lokalen --tmpdir, wenn das Ziel ein NFS-Server ist. Der Stop-Modus hält den Container für die Dauer der Sicherung an, und die Dokumentation warnt vor „potenziell sehr langen" Stillständen.

Zwei Fallen sind containerspezifisch. Zusätzliche Mount-Points außer dem Root-Dateisystem sind standardmäßig nicht im Backup; wer die Datenplatte eines Containers sichern will, setzt backup=1 am Mount-Point. Und Bind-Mounts vom Host sind nie im Backup, egal, was konfiguriert ist. Wir haben Bestandsumgebungen gesehen, in denen die Anwendung im Container Monat für Monat gesichert wurde und die Daten daneben auf einem Bind-Mount lagen, den niemand sicherte. Erfahrungswert, kein Einzelfall.

Mit Proxmox Backup Server als Ziel bleibt die Modi-Logik gleich; PBS speichert das Ergebnis als deduplizierte Chunks mit Metadaten, was die Dokumentation gegenüber einem Dateispeicher ausdrücklich empfiehlt. Der Restore unterscheidet sich im Alltag: VMs kommen als Ganzes zurück, bei Containern lassen sich einzelne Dateien direkt aus dem Archiv ziehen. Docker in einer VM wird als VM gesichert, konsistent über den Guest-Agent; Docker in einem LXC-Container erbt alle Container-Fallen plus die Frage, ob das Overlay-Dateisystem im eingefrorenen Zustand sauber ist. Wie oft der Restore geprobt wird, ist wichtiger als der Modus; die RTO misst man, man schätzt sie nicht.

/08Speicher und Ressourcen ohne Prozentzahlen

Zum Ressourcenverbrauch kursieren Zahlen, die wir nicht wiederholen, weil niemand sie in einer Umgebung wie Ihrer gemessen hat. Was sich ohne Messung sagen lässt: Ein Container hat keinen eigenen Kernel und keinen eigenen Seitencache, sein Arbeitsspeicher ist die Summe seiner Prozesse, begrenzt durch cgroups; der Standardwert für Swap ist 512 MB, für Speicher gibt es keinen Standard, weil der Wert Pflicht ist. Eine VM reserviert, was ihr zugewiesen ist, plus den Kernel und den Cache darin; Ballooning gibt einen Teil zurück, aber nicht verlässlich unter Last. Bei zwanzig Diensten mit je einem halben Gigabyte Bedarf ist der Unterschied spürbar. Bei drei Datenbanken mit je 64 GB ist er es nicht.

Seit Proxmox VE 9.0 gibt es nur noch cgroup v2; die Dokumentation beschreibt, dass Speicher und Swap damit getrennt begrenzt werden, und die 9.2-Notes warnen vor verbliebenen v1-Einträgen in alten Container-Konfigurationen. Wer Container aus Proxmox-6-Zeiten mitschleppt, prüft das vor dem nächsten Upgrade.

Beim Speicher liegt der eigentliche Unterschied. Eine VM bekommt ein Blockgerät: ein ZFS-Zvol, ein LVM-thin-Volume, ein RBD in Ceph oder eine qcow2-Datei. Ein Container bekommt je nach Speicher etwas anderes: auf ZFS ein Subvolume, laut Dokumentation technisch ein Bind-Mount, aber mit Größenänderung und Snapshot; auf LVM oder Verzeichnissen ein Raw-Abbild mit ext4 darin; auf Verzeichnisspeichern mit size=0 ein schlichtes Verzeichnis. Das ZFS-Subvolume ist die angenehmste Form: dünn belegt, snapshotfähig, per Dateisystem sichtbar, Replikation zwischen Knoten inklusive. Das Raw-Abbild verhält sich wie eine kleine VM-Platte mit allen Nachteilen eines Dateisystems im Dateisystem. Welche Speicherform Snapshots wie verkettet, haben wir im Artikel zu Snapshots als Volume-Ketten auf SAN-Speicher auseinandergenommen; für Container gilt schlicht: ZFS oder Ceph, sonst kein Snapshot-Backup.

FUSE-Dateisysteme im Container, etwa für S3-Mounts oder verschlüsselte Ordner, rät die Dokumentation wegen des Freezers „dringend" ab; der Mount gehört auf den Host und per Bind-Mount hinein. Und wer Docker im Container betreibt, stapelt Overlay auf Subvolume auf ZFS, drei Schichten mit je eigener Meinung über Blockgröße und Kompression. Das läuft, aber es misst sich schlecht und sichert sich schlechter.

/09Die Entscheidungsmatrix mit Befehlen

Wir entscheiden nach sieben Fragen, nicht nach Bauchgefühl. Die Tabelle fasst zusammen, was die vorigen Abschnitte begründet haben.

Die Befehle zu den drei Wegen stammen aus der Dokumentation, die Werte sind unsere: ein unprivilegierter Container aus einer Debian-Vorlage, eine VM als Docker-Host, und zum Vergleich die Zeile, die man im Forum findet und im Betrieb vermeiden sollte.

# 1) Unprivilegierter LXC-Container aus einer Systemvorlage (Standard bei der Erstellung)
pveam update && pveam download local debian-13-standard_13.1-1_amd64.tar.zst
pct create 210 local:vztmpl/debian-13-standard_13.1-1_amd64.tar.zst \
    --hostname proxy01 --unprivileged 1 --cores 2 --memory 1024 --swap 512 \
    --rootfs local-zfs:8 --net0 name=eth0,bridge=vmbr0,ip=dhcp
pct start 210 && pct enter 210

# Datenplatte als eigener Mount-Point, ausdruecklich in die Sicherung aufnehmen
pct set 210 --mp0 local-zfs:20,mp=/srv/data,backup=1

# 2) KVM-VM als Docker-Host, Guest-Agent fuer fsfreeze bei der Sicherung
qm create 310 --name docker01 --memory 4096 --cores 4 --cpu x86-64-v2-AES \
    --scsihw virtio-scsi-pci --scsi0 local-zfs:32 --net0 virtio,bridge=vmbr0 \
    --ostype l26 --agent enabled=1 --cdrom local:iso/debian-13.1.0-amd64-netinst.iso
qm start 310
qm migrate 310 pve02 --online        # Live-Migration im Cluster

# 3) Was das Forum empfiehlt: Docker im Container. Moeglich, aber siehe /04 und /06
pct set 210 --features nesting=1,keyctl=1
# Die Doku zu keyctl: "you can choose between running systemd-networkd or docker"

Die Vorlagen- und ISO-Namen ändern sich mit jedem Debian-Punktrelease; pveam available zeigt, was Ihr Knoten heute laden kann. Der CPU-Typ x86-64-v2-AES ist der Standard der Oberfläche und migriert zwischen ungleichen Knoten; host wäre schneller und würde die Live-Migration im gemischten Cluster kosten.

/10Wann welche Form die falsche Wahl ist

Die Fehlentscheidungen, die wir bei Übernahmen am häufigsten vorfinden, haben ein Muster: Sie waren am Tag der Einrichtung bequem. Die Rechnung kommt beim Upgrade, beim Restore oder beim Vorfall.

• Die Datenbank im privilegierten Container. PostgreSQL oder MariaDB laufen in LXC technisch einwandfrei. Privilegiert wurde der Container, weil ein NFS-Mount für die Dumps gebraucht wurde. Damit liegt der wertvollste Datenbestand des Hauses hinter der Grenze, für die das LXC-Team keine CVE vergibt. Unsere Regel: Datenbanken mit Anspruch an Konsistenz, Migration und Isolation in eine VM; kleine interne Datenbanken in einen unprivilegierten Container mit eigenem Mount-Point und backup=1; privilegiert nie.
• Docker im LXC-Container mit Nesting. Der Klassiker aus dem Tutorial. Er scheitert selten sofort und fast immer beim übernächsten Kernel-Wechsel oder beim ersten Image, das /sys beschreiben will. Die Docker-VM kostet einen Kernel mehr und spart den Vorfall.
• Der Dienst mit langen Sitzungen im Container. Ein Terminaldienst, ein Telefonie-Server, eine Anwendung mit Websocket-Sitzungen verträgt keine Restart-Migration. Wer Wartung ohne Wartungsfenster will, braucht Live-Migration und damit eine VM.
• Der Fremdcode im Container. Die Testinstallation eines Anbieters, das Skript eines externen Entwicklers, das Werkzeug aus GitHub: Alles, dessen Herkunft Sie nicht kontrollieren, bekommt einen eigenen Kernel. Nicht, weil LXC unsicher wäre, sondern weil der Schaden eines Fehlers dort größer ist als die Ersparnis.
• Zwanzig Kleinstdienste in zwanzig VMs. Der umgekehrte Fehler. Zwanzig Kernel, zwanzig Bootvorgänge, zwanzig Patch-Läufe für Dienste, die je fünfzig Megabyte brauchen. Hier ist der Container die richtige Antwort, und wer ihn aus Prinzip meidet, zahlt mit Arbeitsspeicher und Wartungszeit.
• Der OCI-Anwendungscontainer als Produktivsystem. Technology Preview heißt, was es heißt. Für den internen Dienst, dessen Ausfall niemand bemerkt, ist das in Ordnung. Für den Dienst mit SLA ist es das nicht, solange Proxmox die Einschränkung selbst so ausweist.

Was sich daraus als Regel ergibt, passt in drei Sätze. Container für das, was Ihnen gehört, klein ist und einen Neustart verträgt. VM für alles mit Fremdcode, Windows, Anspruch an Isolation oder Live-Migration. Docker in eine VM, und OCI-Images in Proxmox als das behandeln, was Proxmox selbst dazu sagt. Ehrlich: Die meisten Umgebungen, die wir übernehmen, wären mit dieser Regel und einem Nachmittag Umbau in Ordnung. Der Nachmittag wird nur selten vor dem Vorfall eingeplant. Wer Proxmox ohnehin mit Support fährt, hat den Herstellersupport für 110 Euro je CPU-Sockel und Jahr dabei; die Entscheidung, welcher Dienst in welche Hülle gehört, nimmt einem der Support nicht ab.

/11Häufige Fragen