Hinweis: Dieser Beitrag enthält Affiliate-Links (mit * gekennzeichnet). Kaufst du über einen dieser Links, erhalten wir eine kleine Provision — für dich ändert sich der Preis nicht. Hardware wird vor jeder Empfehlung mindestens vier Wochen im eigenen Homelab getestet.
Eine der häufigsten Fragen, wenn jemand zum ersten Mal vor dem Proxmox-Web-UI sitzt: Soll dieser Dienst eine VM oder ein LXC-Container werden? Beide Konzepte machen auf den ersten Blick dasselbe — sie isolieren einen Workload vom Rest des Systems — und doch sind sie technisch sehr verschieden. Dieser Vergleich zeigt dir, wann LXC die entspannte Wahl ist, wann eine VM Pflicht wird, und wie ein typischer Mix in einem ausgereiften Homelab aussieht.
TL;DR — der Vergleich auf einen Blick
- LXC-Container teilen sich den Linux-Kernel mit dem Host. Klein, schnell, ressourcenschonend — aber nur für Linux-Gäste und mit eingeschränkter Isolation.
- VMs bringen einen eigenen Kernel mit (KVM-Virtualisierung). Volle Isolation, beliebige Betriebssysteme — aber höherer Overhead.
- Faustregel: Linux-Webdienste, Reverse-Proxies, Datenbanken, Tools-VMs → meist LXC. Windows, BSD, anspruchsvolle Sicherheits-Workloads → VM.
- Performance-Unterschied bei reinen CPU/RAM-Workloads: LXC ~5-10 % schneller als KVM. Bei I/O fast identisch dank virtio.
- Im typischen Homelab-Mix sind 60-80 % der Workloads LXC, der Rest VM — mit gutem Grund.
Was ist eigentlich der Unterschied?
Eine VM (Virtual Machine) ist ein vollständiger virtueller Computer. Sie hat eigenen Speicher, eigene virtuelle Hardware, einen eigenen Kernel und ein komplettes Betriebssystem. Der Hypervisor (bei Proxmox: KVM) sorgt dafür, dass mehrere VMs auf einer physischen Maschine parallel laufen, ohne sich zu sehen. Du kannst Linux, Windows, BSD, Solaris — alles, was auf der Architektur läuft — in einer VM betreiben.
Ein LXC-Container ist viel schlanker: Er nutzt den Linux-Kernel des Hosts mit, hat aber ein eigenes Userland (Distribution, Pakete, Konfiguration). Du fühlst dich beim SSH-Zugriff wie auf einer eigenen Maschine, aber unter der Haube läufst du in einem Namespace-Käfig des Host-Kernels. Das macht Container extrem effizient: Start in unter einer Sekunde, kaum CPU/RAM-Overhead. Die Kehrseite: Nur Linux, eingeschränkte Isolation, weniger Sicherheits-Hard-Wall.
Vergleichstabelle: LXC vs VM
| Kriterium | LXC-Container | VM (KVM) |
|---|---|---|
| Eigener Kernel | nein, teilt sich den Host-Kernel | ja, eigener Kernel |
| Betriebssystem-Wahl | nur Linux | Linux, Windows, BSD, … |
| Boot-Zeit | < 1 Sekunde | 10-60 Sekunden |
| Ressourcen-Overhead | minimal (CPU/RAM near native) | spürbar (5-10 % CPU) |
| Isolation | Namespaces + cgroups, keine Hard-Wall | echte Hardware-Trennung |
| Sicherheit | schwächer (Kernel-Exploits möglich) | stärker (eigener Kernel) |
| Live-Migration | begrenzt (Restart-Migration) | vollwertig (vMotion-ähnlich) |
| Dichte (VMs/Container pro Host) | 50-200 LXC machbar | 10-40 VMs typisch |
| Snapshot | ja, ZFS- oder LVM-Snapshot | ja, mit RAM-Status |
| GPU-Passthrough | nicht offiziell unterstützt | voll, via VFIO |
| Nested Virtualization | nein | ja, mit Einschränkungen |
| Storage-Tools | NFS/CIFS-Mounts brauchen Tricks | volle virtio-Storage |
Wann LXC die richtige Wahl ist
Container-Workloads, die im Homelab und in kleinen Setups in 80 % der Fälle als LXC besser fahren:
- Reverse-Proxies (Traefik, Nginx, Caddy) — brauchen keine eigene Kernel-Spielwiese.
- Web-Anwendungen (Nextcloud, WordPress, Vaultwarden) — Standard-Linux-Stack, Container reicht völlig.
- Datenbanken im Homelab (PostgreSQL, MariaDB, Redis) — läuft im LXC ohne Performance-Verlust.
- Monitoring-Stacks (Prometheus, Grafana, Uptime Kuma) — werden mit LXC sehr leichtgewichtig.
- Tools-Container für kleine Skripte, Cron-Jobs, Watchtower — dafür ist LXC erfunden.
- Pi-hole, AdGuard Home — arbeiten als DNS-Container hervorragend in LXC.
- Build-Server (Forgejo, Gitea, Jenkins-Runner) — minimaler Overhead bei vielen parallelen Jobs.
Der größte Vorteil: Du kannst auf demselben Mini-PC aus unserer Mini-PC-Übersicht deutlich mehr LXC-Container als VMs gleichzeitig laufen lassen, ohne dass die Kiste schwitzt. 30 LXC auf einem Ryzen-7-System mit 32 GB RAM ist Alltag — bei VMs wäre dasselbe System schon mit 8-10 Stück voll.
Wann eine VM Pflicht wird
- Windows-Workloads — offensichtlich, aber wichtig: AD-Domain-Controller, Windows-Update-Server, Office-Trainings-VMs gehen nur als VM.
- BSD-Systeme — OPNsense, pfSense, FreeBSD — jeweils mit eigenem Kernel, daher VM-Pflicht.
- Sicherheits-kritische Workloads — alles, was eine echte Hardware-Isolation braucht: HoneyPot, Malware-Analyse-Sandbox, Zero-Trust-Server.
- Workloads mit eigenem Kernel-Modul — ZFS-Storage-VMs, Custom-Virtio-Treiber, manche RAID-Lösungen.
- GPU-Passthrough für KI — wenn du einer einzelnen Workload eine echte Grafikkarte zuteilen willst (z. B. für Ollama mit GPU), brauchst du eine VM mit VFIO-Passthrough.
- Nested Virtualization — etwa eine zweite Proxmox-Instanz im Homelab als Test-Cluster, oder eine VMware-Workstation in einer VM.
- Docker mit ernsthaften Anforderungen — obwohl Docker in LXC technisch geht, ist eine eigene Docker-VM die saubere Praxis. Mehr dazu in unserem Proxmox-9.1-OCI-Container-Beitrag oder im Docker-Tutorial.
Performance — was die Zahlen sagen
Bei reinen CPU- und RAM-Workloads hat LXC einen kleinen Vorsprung — weil eben kein Kernel-Layer dazwischen läuft. In synthetischen Benchmarks zeigt sich:
- Single-Core CPU: LXC ~99-100 % der nativen Leistung. KVM-VM ~94-97 %.
- Multi-Core CPU: LXC praktisch native, KVM ~92-96 %.
- RAM-Bandbreite: beide nahezu identisch zur nativen Leistung.
- Disk-I/O (NVMe, virtio): LXC ist minimal schneller, KVM mit virtio-blk ist nah dran. Unterschied im Alltag oft < 5 %.
- Netzwerk: LXC mit veth + Bridge ~99 % nativ. KVM mit virtio-net ~97-98 %.
Heißt im Klartext: Performance allein ist fast nie der Grund, sich für oder gegen LXC zu entscheiden — die Lücke ist im Homelab nicht spürbar. Entscheidender sind Isolation, Betriebssystem-Wahl und Skalierungsfaktor.
Sicherheit — wo LXC schwächer ist
Wenn du LXC bewusst einsetzt, solltest du die wichtigsten Sicherheits-Punkte kennen:
- Kernel-Exploits sind kritisch: Ein erfolgreicher Kernel-Angriff aus einem LXC kann den Host kompromittieren. Bei VMs schützt der eigene VM-Kernel.
- Unprivileged Container nutzen: Proxmox legt LXC standardmäßig als „unprivileged“ an — das mappt root im Container auf eine non-root-UID auf dem Host. Pflicht für jede LXC, die nicht hundertprozentig vertrauenswürdig ist.
- Kernel-Module-Aktivität: Kein LXC kann eigene Kernel-Module laden. Wenn ein Workload das braucht, muss es eine VM sein.
- Netzwerk-Segmentierung: Auch im LXC gilt: per VLAN trennen, nicht alle Container in dieselbe Bridge. Mehr dazu in unserem VLAN-Tutorial.
Ein typischer Homelab-Mix
So sieht ein durchdachter Homelab-Mix in der Praxis aus — das ist tatsächlich der Setup-Plan, den wir hier auf Lapalutschi-Hardware fahren:
- VM 100 — Docker-Hostsystem (Ubuntu Server LTS): trägt alle Container-Workloads, die viel Internet sehen oder unsicher sind.
- VM 110 — OPNsense-Firewall (FreeBSD): Pflicht-VM, weil BSD.
- VM 120 — Windows-Test-VM: für gelegentliche Windows-Tests und AD-Spielereien.
- VM 130 — KI-Worker (Ubuntu mit GPU-Passthrough): für Ollama mit Nvidia-GPU.
- LXC 200 — Pi-hole: minimaler Container, der überall im Heimnetz ankommt.
- LXC 201 — Vaultwarden: schlanker Passwort-Server.
- LXC 202 — Traefik: Reverse-Proxy mit Let’s Encrypt.
- LXC 203 — Nextcloud: eigene Cloud, NFS-Mount auf eine NAS.
- LXC 204 — Jellyfin: Mediaserver mit Hardware-Transcoding (VAAPI).
- LXC 205 — Grafana + Prometheus: Monitoring-Stack.
- LXC 210-220: Test-Container, kleine Tools, Build-Helper.
Das Verhältnis 4 VMs zu 11+ LXC ist keine Faulheit, sondern Effizienz. Auf einem Mini-PC mit 32 GB RAM hast du so deutlich mehr Funktionalität, als wenn du alles in VMs zwingen würdest.
Häufige Fragen
Kann ich Docker in einem LXC laufen lassen?
Technisch ja, aber es ist nicht der saubere Weg. Du brauchst ein privileged-LXC mit AppArmor-Profilen, was die Sicherheits-Vorteile von LXC zunichte macht. Sauberer: eine kleine Docker-VM (Debian oder Ubuntu LTS) als Hostsystem für alle Docker-Container. Seit Proxmox 9.1 gibt es zusätzlich OCI-Container-Support direkt im UI — siehe unser Proxmox-9.1-OCI-Beitrag.
Wie migriere ich einen Workload von VM zu LXC (oder umgekehrt)?
Es gibt keinen direkten Konvertierungs-Pfad. In der Praxis baut man den Container neu auf, mountet die alten Daten von der VM-Disk und konfiguriert die Anwendung neu. Das ist meist eine gute Gelegenheit, das Setup zu modernisieren.
Lassen sich LXC-Container live migrieren wie VMs?
Eingeschränkt. Proxmox unterstützt Restart-Migration für LXC im Cluster — das heißt der Container wird auf einem anderen Node gestartet, mit kurzer Unterbrechung. Echte Live-Migration ohne Downtime ist bei VMs sauberer gelöst (vMotion-ähnlich).
Wie viele LXC kann ein einzelner Host stemmen?
Faustformel: Pro 1 GB RAM-Verbrauch ein LXC. Mit 32 GB RAM und vorsichtiger Konfiguration sind 50-100 leichte LXC drin. Bei VMs landest du auf derselben Hardware bei 8-15. Begrenzungen kommen meist über RAM, manchmal über LXC-Limits in /etc/sysctl.conf (max user processes, ulimit).
Brauche ich für LXC etwas anderes als für VMs?
Hardware-mäßig nichts — jede Proxmox-Hardware kann beides. Beim Storage-Setup bietet sich ZFS an, weil dort Container-Snapshots und Klone besonders effizient sind. Mehr zu Storage-Wahl im Proxmox-Komplettguide.
Was ist mit Backups?
Beide werden vom Proxmox Backup Server gleich behandelt — LXC-Backups sind sogar deutlich kleiner und schneller als VM-Backups, weil weniger Daten zu sichern sind.
Wo es weitergeht
- Der komplette Proxmox-Guide — die Pillar-Page mit allen Themen.
- Proxmox 9.1 mit OCI-Containern — Docker-Ersatz im UI.
- Proxmox-Cluster mit Ceph — Hochverfügbarkeit für VMs und LXC.
- Proxmox Backup Server einrichten — Backups für beide Welten.
- Docker für Einsteiger — falls du dich für die Docker-Welt entschieden hast.
Externe Pflichtquellen:
- Proxmox-Wiki: Linux Container (LXC) — offizielle Doku.
- linuxcontainers.org — das LXC-Projekt selbst.
- Proxmox-Forum — viele LXC-Praxis-Threads.
Du planst gerade einen neuen Workload und kommst nicht weiter mit der Entscheidung? Schreib uns eine Mail an admin@lapalutschi.de.