KVM oder LXC auf Proxmox: wann eine VM, wann ein Container

Die große Stärke von Proxmox VE (und nebenbei die größte Quelle der Verwirrung für neue Nutzer) ist, dass es zwei Virtualisierungstechniken auf demselben Host anbietet: virtuelle KVM-Maschinen und Linux-Container mit LXC. Auf dem Papier könnte man meinen, es sei Geschmackssache. In der Praxis hat die Wahl direkte Folgen für Sicherheit, Dichte, Leistung und Wartbarkeit Ihrer Infrastruktur.

Dieser Artikel klärt von Grund auf, was jede Technik tatsächlich tut, wo die echten Sicherheitsrisiken liegen (vor allem die klassische Docker-in-LXC-Falle), wie man einen LXC richtig konfiguriert, und gibt ein Entscheidungsraster in 5 Fragen an die Hand, damit Sie nie mehr zögern.

Was jede Technik tatsächlich tut #

KVM: vollständige Virtualisierung #

KVM (Kernel-based Virtual Machine) erzeugt eine virtuelle Maschine im strengen Sinn: Jede VM hat ihren eigenen Linux-Kernel (oder Windows, oder BSD), ihren eigenen Kernel-Space, ihre eigenen Treiber, ihre eigene Prozesstabelle. Der Proxmox-Hypervisor spricht über die Hardware-Erweiterungen VT-x oder AMD-V mit der Hardware, und die VM „sieht“ nur eine virtualisierte Hardware, die ihr allein gehört. Die Isolation ist eindeutig: Was in der VM passiert, greift nicht auf den Host über, außer bei einer kritischen Schwachstelle in QEMU/KVM (äußerst selten und sofort gepatcht).

LXC: native Linux-Container #

LXC (Linux Containers) erzeugt keine virtuelle Maschine. Es erzeugt eine isolierte Umgebung, die sich über die nativen Kernel-Mechanismen den Linux-Kernel des Proxmox-Hosts teilt: Namespaces (PID, Netzwerk, Mount, User, UTS, IPC) und cgroups. Der Container hat seine eigene Prozesstabelle, seine eigenen virtuellen Netzwerkschnittstellen, sein eigenes Dateisystem. Aber wenn ein Prozess im Container einen Systemaufruf macht, antwortet der Kernel des Hosts.

Der gemeinsame Kernel: Vorteil und Risiko #

Der gemeinsame Kernel macht LXC so leicht. Kein zweites Betriebssystem zu booten, kein reservierter Arbeitsspeicher für einen Gast-Kernel, kein Overhead durch Hardware-Virtualisierung. Ein minimaler Debian-Container startet in 2 Sekunden und belegt im Leerlauf 50 bis 80 MB Arbeitsspeicher. Auf einem Host mit 32 GB laufen problemlos 30 unabhängige Dienste in 30 getrennten LXC.

Die Docker-in-LXC-Falle #

Das ist wahrscheinlich die verbreitetste schlechte Praxis im Proxmox-Umfeld von Hobbyanwendern: einen Debian-LXC anlegen, Docker darin installieren und dann den gesamten Anwendungsstack mit Docker Compose darin laufen lassen. Technisch funktioniert das. Offiziell wird es von den Proxmox-Entwicklern weder unterstützt noch empfohlen.

Warum? Weil man damit zwei Schichten mit gemeinsamem Kernel übereinanderlegt (LXC + Docker), was die Ausbruchswege vervielfacht. Außerdem braucht Docker Linux-Capabilities, die unprivilegierte LXC nicht gewähren: Man muss also entweder einen privilegierten LXC verwenden (schlechte Idee für die Sicherheit), lxc.cap.keep aktivieren, was die Angriffsfläche vergrößert, oder mit fuse-overlayfs arbeiten, was die I/O-Leistung verschlechtert.

Privilegiert oder unprivilegiert, und AppArmor #

Unprivilegiert (standardmäßig empfohlen) #

• Der Root des Containers (UID 0) wird auf eine nicht privilegierte UID des Hosts abgebildet (typischerweise 100000).
• Ein Ausbruch auf den Host verschafft keine echten Rechte.
• Ein restriktives AppArmor-Profil wird automatisch angewendet.
• Einschränkung: Manche exotischen Mounts (NFS-Root, FUSE) erfordern zusätzliche Konfiguration.

Privilegiert (nur in Ausnahmefällen) #

• Der Root des Containers bleibt auf dem Host UID 0.
• Eine Schwachstelle in einem Dienst, der im LXC als Root läuft, verschafft direkt Root-Kontrolle über den Host.
• Nur für Systemcontainer, bei denen Sie 100 % des Codes kontrollieren und das Risiko bewusst tragen.
• Nie für eine öffentliche, aus dem Internet erreichbare Anwendung verwenden.

# Modus eines bestehenden LXC prüfen (Auszug aus /etc/pve/lxc/100.conf)
cat /etc/pve/lxc/100.conf | grep -E 'unprivileged|features'

# Erwartete Ausgabe für einen unprivilegierten Container:
# unprivileged: 1
# features: nesting=0

Speicher- und CPU-Bedarf: konkrete Zahlen #

Theoretische Vergleiche bleiben abstrakt. Hier einige echte Messwerte auf einem Proxmox-8-Host mit Debian 12 als Gast, im Leerlauf nach vollständigem Start der Dienste.

Vaultwarden (Bitwarden-Passwortmanager) #

• Unprivilegierter Debian-LXC: 80 bis 130 MB Arbeitsspeicher, 0,1 % CPU im Leerlauf. Start in 3 Sekunden.
• Debian-KVM-VM: 480 bis 600 MB Arbeitsspeicher (davon 350 für Kernel und systemd des Gasts), 0,3 % CPU. Start in 25 Sekunden.

Nextcloud (mit PHP-FPM + Nginx + OPcache) #

• Unprivilegierter LXC: 250 bis 400 MB Arbeitsspeicher im Leerlauf, steigt unter Last mit 10 gleichzeitigen Nutzern auf 1,2 GB.
• KVM-VM: 700 MB bis 1 GB Arbeitsspeicher im Leerlauf, 1,8 GB bei gleicher Last.

PostgreSQL 16 (eigene Instanz, shared_buffers 512 MB) #

• LXC: 550 bis 700 MB Arbeitsspeicher. Aber schwache Isolation: für ein kritisches, mandantenfähiges Postgres ungeeignet.
• KVM-VM: 1,1 bis 1,3 GB Arbeitsspeicher. Vollständige Isolation, für die Produktion empfohlen.

Entscheidungsraster in 5 Fragen #

1. Verarbeitet der Dienst kritische Daten oder ist er aus dem Internet erreichbar? → KVM-VM (starke Isolation).
2. Müssen Docker, Kubernetes oder ein anderes Betriebssystem als Linux laufen? → KVM-VM zwingend.
3. Ist der Dienst ein einfacher Linux-Daemon, den Sie kontrollieren, mit geringem Speicherbedarf? → unprivilegierter LXC.
4. Wollen Sie die Dichte maximieren (mehr als 20 Dienste auf einem Host)? → unprivilegierter LXC, mit bewusst getragenem Kernel-Risiko.
5. Braucht der Dienst Hardware-Passthrough (GPU, USB, PCIe-Karte)? → KVM-VM, der einzige sauber unterstützte Modus.

Faustregeln nach Art des Dienstes #

• Produktive Datenbank (Postgres, MySQL, MongoDB): eigene KVM-VM.
• Reverse Proxy / WAF (Nginx, Traefik, Caddy): unprivilegierter LXC, oder VM, wenn er direkt am Internet hängt.
• Zustandslose Webanwendung (Nextcloud, Vaultwarden, BookStack, Outline): unprivilegierter LXC.
• Netzwerkdienste der Infrastruktur (DNS, DHCP, RADIUS): unprivilegierter LXC.
• Medien und Transcoding (Jellyfin, Plex mit GPU-Hardwarebeschleunigung): KVM-VM mit Passthrough.
• Kritische Hausautomation (Home Assistant mit Zigbee über USB): KVM-VM mit USB-Passthrough.
• Entwicklungs- oder Testumgebung, die stark isoliert sein muss: Wegwerf-KVM-VM.
• Alles, was Docker braucht: KVM-VM, nie LXC.

Fazit #

KVM und LXC sind keine Konkurrenten, sie ergänzen sich. Ein gut aufgebauter Proxmox-Host mischt typischerweise einige schwere VMs (Datenbanken, Docker-Dienste, kritische Plattformen) mit einer Mehrheit unprivilegierter LXC für alle schlanken, kontrollierbaren Linux-Daemons. Dieses Nebeneinander, und wie leicht Proxmox den Wechsel zwischen beiden macht, hebt es für den Aufbau einer souveränen privaten Cloud über die Konkurrenz.

Ist für jeden Dienst die richtige Technik gewählt, wird das Backup zur nächsten Priorität, und das verzeiht keinen Architekturfehler. Die PBS-Anleitung beschreibt, wie Sie den gesamten Bestand schützen, VMs wie LXC, mit Deduplizierung, mehrstufiger Aufbewahrung und Widerstandsfähigkeit gegen Ransomware.