Proxmox VE bietet zwei Virtualisierungstechnologien: KVM Virtual Machines und LXC Container. Während VMs komplette Betriebssysteme mit eigenem Kernel emulieren, teilen LXC Container den Linux-Kernel des Hosts und sind dadurch erheblich ressourcenschonender. Für viele Unternehmensanwendungen sind Container die effizientere Wahl — doch es gibt klare Szenarien, in denen eine VM die bessere Option bleibt.
Was sind LXC Container?
LXC (Linux Containers) ist eine Virtualisierungstechnologie auf Betriebssystemebene. Im Gegensatz zu einer VM, die einen kompletten Computer mit eigenem Kernel simuliert, nutzt ein LXC Container den Kernel des Host-Systems. Jeder Container hat jedoch seinen eigenen Dateisystem-Baum, seine eigenen Netzwerkinterfaces, Prozesse und Benutzer — von innen betrachtet fühlt er sich wie ein eigenständiges Linux-System an.
Der entscheidende Unterschied zu Docker: LXC Container sind System-Container. Sie verhalten sich wie eine vollständige Linux-Installation mit systemd, SSH-Zugang und persistentem Zustand. Docker-Container sind Anwendungs-Container, die typischerweise einen einzelnen Prozess isolieren. LXC ist damit die natürliche Wahl für Dienste, die in einer VM laufen würden, aber keine VM-Ressourcen benötigen.
Container vs VM: Der Vergleich
| Kriterium | LXC Container | KVM Virtual Machine |
|---|---|---|
| Kernel | Geteilter Host-Kernel | Eigener Kernel |
| Boot-Zeit | 1–3 Sekunden | 30–90 Sekunden |
| RAM-Overhead | Minimal (~20 MB Basis) | 512 MB–2 GB (OS + Kernel) |
| Disk-Overhead | ~500 MB (Basissystem) | 5–20 GB (vollständiges OS) |
| CPU-Performance | Nahezu nativ | ~2–5 % Overhead |
| I/O-Performance | Nativ (kein Hypervisor-Layer) | Leichter Overhead (virtio) |
| Gastbetriebssystem | Nur Linux | Linux, Windows, BSD, beliebig |
| Kernel-Module | Vom Host bereitgestellt | Eigene Kernel-Module möglich |
| Isolation | Prozess-Level (Namespaces, cgroups) | Hardware-Level (volle Isolation) |
| Live-Migration | Unterstützt (mit Einschränkungen) | Vollständig unterstützt |
| Snapshots | Unterstützt | Unterstützt (inkl. RAM-State) |
| Backup (PBS) | Unterstützt | Unterstützt |
Die Ressourcenersparnis ist erheblich: Wo eine VM mit Ubuntu Server mindestens 1 GB RAM und 10 GB Disk belegt, kommt ein LXC Container mit 128 MB RAM und 1 GB Disk aus. Bei 20 Diensten summiert sich das auf 16 GB eingesparte RAM und 180 GB weniger Disk.
Wann Container einsetzen?
Ideale Einsatzgebiete für LXC
DNS-Server (Pi-hole, AdGuard Home): Ein DNS-Server benötigt keine VM-Isolation und verbraucht minimal Ressourcen. In einem LXC Container läuft er mit 64–128 MB RAM.
Reverse Proxy (nginx, Caddy, Traefik): Ein Reverse Proxy leitet HTTP/HTTPS-Traffic weiter und benötigt dafür keine eigenständige VM. Container starten in Sekunden und verbrauchen kaum Ressourcen.
Monitoring (Prometheus, Grafana, Zabbix): Monitoring-Dienste profitieren von der schnellen Bereitstellung und niedrigem Overhead. Grafana mit Prometheus läuft problemlos in einem Container mit 512 MB RAM.
Webserver und Webanwendungen: Statische Websites, WordPress, Wikis oder interne Webanwendungen sind klassische Container-Workloads.
Build-Server und CI/CD: Jenkins, Gitea oder GitLab Runner laufen effizient in Containern. Die schnelle Boot-Zeit ermöglicht On-Demand-Builds.
Dateiserver (Samba/NFS): Ein Dateiserver, der SMB- oder NFS-Freigaben bereitstellt, kann als LXC Container betrieben werden — mit direktem Zugriff auf gemountete Storage-Volumes.
Datenbanken (PostgreSQL, MariaDB): Datenbank-Server profitieren von der nativen I/O-Performance ohne Hypervisor-Overhead.
Wann eine VM die bessere Wahl ist
Windows-Anwendungen: LXC unterstützt ausschließlich Linux als Gastbetriebssystem. Für Windows-Server oder Windows-Anwendungen ist eine KVM-VM erforderlich.
Eigene Kernel-Module: Wenn eine Anwendung spezielle Kernel-Module oder einen bestimmten Kernel benötigt (z. B. ZFS auf einem Nicht-ZFS-Host oder Custom-Treiber).
Maximale Isolation: Für sicherheitskritische Workloads, bei denen eine Kernel-Schwachstelle nicht alle Container gefährden darf. VMs bieten Hardware-Level-Isolation.
Docker/Kubernetes-Workloads: Docker innerhalb eines LXC Containers (nested virtualization) funktioniert, erfordert aber spezielle Konfiguration. Für komplexe Docker-Setups ist eine VM oft der einfachere Weg.
Appliances: Vorgefertigte VM-Images (OVA/QCOW2) von Herstellern lassen sich direkt als VM importieren.
LXC Container auf Proxmox verwalten
Erstellen eines Containers
Proxmox bietet einen integrierten Template-Download. Über das Webinterface oder die CLI lassen sich Container in wenigen Schritten erstellen:
- Template herunterladen: Proxmox bietet vorgefertigte Templates für Debian, Ubuntu, Alpine, CentOS, Fedora und weitere Distributionen. Der Download erfolgt über den integrierten Template-Manager.
- Container erstellen: ID, Hostname, Root-Passwort, Netzwerk und Ressourcen definieren.
- Starten: Der Container ist in 1–3 Sekunden betriebsbereit.
Ressourcen-Management
Proxmox erlaubt die dynamische Anpassung von Container-Ressourcen:
- CPU: Anzahl der CPU-Kerne zuweisen (Hotplug möglich)
- RAM: Arbeitsspeicher zuweisen und Swap konfigurieren
- Disk: Storage dynamisch erweitern (ohne Neustart)
- Netzwerk: Mehrere virtuelle Netzwerkinterfaces pro Container
Ein Container kann mehr CPU-Kerne zugewiesen bekommen als physisch verfügbar sind — Proxmox managed die Verteilung über cgroups. Das ermöglicht Overcommitment bei Workloads, die selten alle Ressourcen gleichzeitig nutzen.
Privilegiert vs Unprivilegiert
Proxmox unterstützt zwei Container-Modi:
Unprivilegierte Container (Standard, empfohlen): Die Benutzer-IDs innerhalb des Containers werden auf einen hohen ID-Bereich des Hosts gemappt. Selbst wenn ein Angreifer Root-Zugriff im Container erlangt, hat er auf dem Host nur eingeschränkte Rechte. Das ist die sicherste Option und sollte für alle neuen Container verwendet werden.
Privilegierte Container: Die Benutzer-IDs entsprechen denen des Hosts. Root im Container ist Root auf dem Host. Nur in Ausnahmefällen notwendig, wenn Anwendungen spezifische Systemzugriffe benötigen (z. B. bestimmte Mount-Operationen oder NFS-Server).
Container und Storage
LXC Container in Proxmox unterstützen verschiedene Storage-Backends:
- ZFS: Optimal für Snapshots, Komprimierung und Klone. Ein ZFS-Klon eines Containers benötigt initial null zusätzlichen Speicher.
- LVM / LVM-Thin: Performant und platzsparend mit Thin Provisioning.
- Directory-basiert (ext4, XFS): Einfach und kompatibel.
- Ceph RBD: Für Cluster-Umgebungen mit verteiltem Storage.
Bei ZFS als Storage-Backend sind Container-Snapshots und -Klone besonders effizient: Ein Snapshot wird in Millisekunden erstellt und belegt nur den Platz für nachfolgende Änderungen (Copy-on-Write).
Backup und Hochverfügbarkeit
LXC Container werden in Proxmox identisch zu VMs gesichert:
- Proxmox Backup Server: Inkrementelle, deduplizierte Backups mit schnellem Restore. Funktioniert identisch für Container und VMs.
- Snapshots: ZFS-Snapshots für sofortige Sicherungspunkte.
- HA-Cluster: Container können in einem Proxmox-HA-Cluster automatisch auf einen anderen Node migriert werden, wenn ein Host ausfällt.
Praxisbeispiel: 10 Dienste auf einem Server
Ein typischer KMU-Server mit 32 GB RAM und 500 GB SSD kann problemlos folgende Dienste als LXC Container betreiben:
| Dienst | RAM | Disk | Container |
|---|---|---|---|
| DNS (Pi-hole) | 128 MB | 1 GB | CT 100 |
| Reverse Proxy (nginx) | 128 MB | 1 GB | CT 101 |
| Webserver (Apache + PHP) | 512 MB | 5 GB | CT 102 |
| Datenbank (MariaDB) | 1 GB | 10 GB | CT 103 |
| Monitoring (Grafana + Prometheus) | 1 GB | 20 GB | CT 104 |
| Mailserver (Postfix + Dovecot) | 512 MB | 10 GB | CT 105 |
| Wiki (BookStack) | 256 MB | 2 GB | CT 106 |
| Git (Gitea) | 256 MB | 5 GB | CT 107 |
| Backup-Agent (PBS Client) | 128 MB | 1 GB | CT 108 |
| VPN (WireGuard) | 64 MB | 512 MB | CT 109 |
| Gesamt | ~4 GB | ~56 GB | 10 Container |
Als VMs würden dieselben Dienste ~20 GB RAM und ~200 GB Disk benötigen. Container sparen hier 80 % der Ressourcen.
Häufig gestellte Fragen
Sind LXC Container so sicher wie VMs?
Unprivilegierte LXC Container bieten gute Isolation durch Linux-Namespaces und cgroups. VMs bieten jedoch stärkere Isolation auf Hardware-Ebene. Für die meisten internen Dienste in einem Unternehmensnetzwerk ist die Container-Isolation ausreichend. Für Multi-Tenant-Umgebungen oder besonders sicherheitskritische Workloads empfehlen wir VMs.
Kann ich Docker in einem LXC Container ausführen?
Ja, mit der Option “Nesting” in den Container-Features. Proxmox muss den Container als unprivilegiert konfigurieren und die Nesting-Option aktivieren. Für komplexe Docker-Compose-Setups funktioniert das zuverlässig.
Welches Linux-Template sollte ich verwenden?
Für die meisten Anwendungsfälle empfehlen wir Debian 12 — stabil, schlank, langzeitunterstützt. Für minimale Container (DNS, Proxy) eignet sich Alpine Linux mit nur ~5 MB Basisimage.
Können Container live migriert werden?
Ja, Proxmox unterstützt Live-Migration von Containern zwischen Cluster-Nodes. Bei ZFS-basiertem Storage ist die Migration besonders schnell, da nur geänderte Datenblöcke übertragen werden.
Wie viele Container kann ein Server betreiben?
Das hängt von den Ressourcen ab. Ein Server mit 64 GB RAM kann problemlos 50–100 leichtgewichtige Container betreiben. Der begrenzende Faktor ist typischerweise der RAM, nicht die CPU.
Sie möchten Ihre Proxmox-Infrastruktur mit LXC Containern optimieren? Kontaktieren Sie uns — wir beraten Sie bei der Architektur und setzen die Migration um.
Mehr zu diesen Themen:
Weitere Artikel
Backup-Strategie für KMU: Proxmox PBS + TrueNAS als zuverlässiges Backup-Konzept
Backup-Strategie für KMU mit Proxmox PBS und TrueNAS: 3-2-1-Regel umsetzen, PBS als primäres Backup-Target, TrueNAS-Replikation als Offsite-Kopie, Retention Policies und automatisierte Restore-Tests.
Proxmox Notification-System: Matcher, Targets, SMTP, Gotify und Webhooks
Proxmox Notification-System ab PVE 8.1 konfigurieren: Matcher und Targets, SMTP-Setup, Gotify-Integration, Webhook-Targets, Notification-Filter und sendmail vs. neue API.
Proxmox Cluster-Netzwerk richtig planen: Corosync, Migration, Storage und Management
Proxmox Cluster-Netzwerk designen: Corosync-Ring, Migration-Network, Storage-Network für Ceph/iSCSI, Management-VLAN, Bonding/LACP und MTU 9000 — mit Beispiel-Topologien.