Der Artikel liegt nicht als Datei vor, sondern wurde mir direkt als Text übergeben. Hier die korrigierte Fassung mit der einen behobenen Stelle:
- LXC-Container laufen mit 97–99 % nahezu auf nativer Geschwindigkeit, VMs kommen auf rund 82–90 % – dafür ist eine VM sauberer vom Host getrennt.
- Nur VMs lassen sich bei Proxmox live migrieren, also im laufenden Betrieb auf einen anderen Server verschieben. LXC-Container gibt es nur als Backup/Restore.
- Für GPU-Transcoding (Plex, Jellyfin) ist ein LXC-Container meist einfacher einzurichten und kann sich die Grafikkarte sogar mit mehreren Containern teilen – seit Proxmox VE 9 aber mit neuen Hürden.
- Windows 11 geht ausschließlich in einer VM, weil LXC keinen eigenen Kernel (den Kern des Betriebssystems) mitbringt.
Wer sich ein Homelab aufbaut, stolpert früh über diese Frage: Läuft der neue Dienst als LXC-Container oder als virtuelle Maschine (VM)? Beide Wege stehen in Proxmox VE, einem der bekanntesten Hypervisoren (die Software, die auf einem Server mehrere virtuelle Systeme gleichzeitig verwaltet) für Homelabs, direkt nebeneinander zur Auswahl. Die Antwort hängt weniger vom Geschmack als vom Workload ab.
Der technische Unterschied
Ein LXC-Container ist ein Linux-Systemcontainer: Er teilt sich den Kernel des Host-Systems, startet also keinen eigenen Betriebssystemkern, sondern nutzt den vom Server mit. Dadurch ist er schlank und startet in Sekunden. Eine VM dagegen läuft über KVM/QEMU (die Virtualisierungstechnik unter Proxmox) und emuliert vollständige Hardware – sie bringt ihren eigenen Kernel mit und ist damit vom Rest des Systems komplett getrennt.
Performance: Wie viel kostet die Isolation?
Der Preis für die stärkere Trennung einer VM ist Geschwindigkeit. Tests auf Proxmox VE 9.1 zeigen: LXC-Container erreichen etwa 97–99 % der nativen Performance des Hosts, VMs kommen auf rund 82–90 %. Für die meisten Homelab-Dienste – ein Pi-hole (ein DNS-Sinkhole, vereinfacht gesagt eine Sperrliste, die Anfragen an Werbeserver ins Leere laufen lässt), ein kleiner Webserver – ist der Unterschied kaum spürbar. Bei Workloads, die wirklich jedes Prozent CPU-Leistung brauchen, zählt er.
| Kriterium | LXC-Container | VM |
|---|---|---|
| Performance | ca. 97–99 % nativ | ca. 82–90 % nativ |
| Isolation | teilt Host-Kernel, per UID-Mapping abgeschottet | eigener Kernel, vollständig getrennt |
| Live-Migration | nein, nur Backup/Restore | ja, im laufenden Betrieb |
| Restore-Geschwindigkeit | schneller (nur Dateisystem) | langsamer (komplettes Disk-Image) |
| Snapshots ohne Downtime | ja, mit ZFS/Ceph als Speicher | ja |
| Windows möglich | nein | ja |
Sicherheit: Root im Container ist nicht gleich Root auf dem Host
Proxmox legt Container standardmäßig unprivilegiert an: Der Root-Nutzer im Container wird per UID-Mapping (eine Zuordnungstabelle für Benutzer-IDs) auf einen harmlosen, unprivilegierten Nutzer des Hosts abgebildet, meist ab einem Offset von UID 100000. Das ist ein wichtiger Unterschied zum privilegierten Container, bei dem Root im Container tatsächlich Root auf dem Host ist – dort wirkt eine Kernel-Schwachstelle direkt durch. Die pauschale Aussage „LXC ist unsicherer als eine VM“ stimmt also so nicht: Unprivilegierte Container bieten für normale Linux-Dienste brauchbare Isolation. Bleibt aber ein Restrisiko, weil sich Container und Host immer den Kernel teilen – eine VM trennt hier strikter.
Backup, Snapshots und Migration
Bei Snapshots unterscheiden sich beide kaum: Läuft der Speicher über ZFS oder Ceph, sind Snapshots ohne Downtime bei LXC wie bei VM möglich. Beim Wiederherstellen ist LXC im Vorteil, weil nur das Dateisystem gesichert werden muss statt eines kompletten Disk-Images – das geht spürbar schneller. Ein echter Vorteil bleibt bei VMs die Live-Migration: Sie lassen sich im laufenden Betrieb zwischen Cluster-Knoten verschieben, ohne den Dienst neu zu starten. Für LXC-Container gibt es in Proxmox dafür nur Offline-Migration per Backup/Restore.
GPU-Transcoding: LXC einfacher, aber mit neuen Hürden
Für Plex- oder Jellyfin-Transcoding (das Umwandeln von Videos in Echtzeit für verschiedene Geräte) brauchte eine VM klassisches PCI(e)-Passthrough über VFIO/IOMMU – eine Hardwarefunktion, die ein Gerät sicher einer einzelnen VM zuweist. Ein LXC-Container kann dagegen die Gerätedatei der Grafikkarte direkt vom Host einbinden, ganz ohne IOMMU. Der Unterschied wirkt sich auch auf die Nutzung aus: Eine GPU in einer VM ist exklusiv für diese eine VM reserviert, während sich mehrere LXC-Container dieselbe Grafikkarte teilen können, etwa für parallele Transcoding-Jobs. Seit Proxmox VE 9 hat sich das allerdings verkompliziert: Das neue AppArmor 4.1 (ein Sicherheitsmodul im Linux-Kernel, das einschränkt, was Programme dürfen) erschwert GPU-Passthrough in unprivilegierten Containern erheblich. Der bisherige Königsweg „unprivilegierter Container plus GPU-Passthrough“ funktioniert seither nur noch mit Kompromissen – entweder ein privilegierter Container mit weniger Isolation, oder eine host-weite Lockerung von AppArmor.
Beelink Mini S12 Pro Mini PC, Intel N100 (4C/4T, bis zu 3.4Ghz)
Ein N100-Mini-PC wie dieser ist die typische Einstiegshardware, um Proxmox mit mehreren LXC-Containern und VMs parallel auszuprobieren.
Docker in LXC: erlaubt, aber inoffiziell
Docker in einem LXC-Container laufen zu lassen, war lange verpönt – der Satz „Docker gehört nicht in LXC“ ist mittlerweile überholt. Mit den Container-Optionen „nesting“ und „keyctl“ funktioniert Docker in einem LXC-Container 2026 für die meisten Workloads zuverlässig. Offiziell unterstützt wird die Kombination von Proxmox aber weiterhin nicht. Wer sich dafür entscheidet, sollte zudem wissen: Mit CVE-2025-52881 wurde eine Schwachstelle bekannt, über die sich Docker aus einem LXC-Container heraus ausbrechen ließ – betroffen war containerd vor Version 1.7.28-2, der Fix kam etwa im November 2025. Wer den Umweg über Docker ganz vermeiden will, kann alternativ den (noch im Beta-Status befindlichen) direkten OCI-Image-Support von Proxmox nutzen – OCI steht für Open Container Initiative, den Standard hinter Container-Images.
Wann eine VM Pflicht ist
Bei manchen Workloads entscheidet nicht die Performance, sondern die Technik: Windows 11 als VM braucht UEFI/OVMF (ein modernes BIOS-Pendant), den Maschinentyp q35, ein vTPM 2.0 (ein virtuelles Sicherheitsmodul, das Windows 11 zur Installation verlangt) und vorinstallierte Secure-Boot-Schlüssel. In einem LXC-Container ist das grundsätzlich unmöglich, weil dort kein eigener Kernel läuft. Ebenso falsch ist die Annahme, ein Kernel-Update im Container erfordere wie bei einer VM einen Neustart des Containers: Da LXC keinen eigenen Kernel hat, laufen Kernel-Updates ausschließlich auf dem Host – und betreffen dann automatisch alle Container gleichzeitig.
Und außerhalb von Proxmox?
Nicht jedes NAS-Betriebssystem bietet LXC an. Unraid setzt nativ auf Docker-Container und KVM-VMs, echtes LXC gibt es nur über inoffizielle Community-Plugins. TrueNAS SCALE hat seit Version 25.04 zusätzlich zu Docker-Apps und VMs auch Systemcontainer im Angebot, technisch über Incus umgesetzt – den 2024 entstandenen Community-Nachfolger von LXD. Wer außerhalb von Ubuntu unterwegs ist, landet ökosystemseitig ohnehin eher bei Incus als bei LXD.
Fazit: Die Faustregel
Für die meisten klassischen Homelab-Dienste – Pi-hole, Home Assistant, kleine Webanwendungen, auch Jellyfin mit GPU-Transcoding – ist ein LXC-Container die schlankere und schnellere Wahl, gerade auf kompakter Mini-PC-Hardware mit begrenztem RAM. Eine VM lohnt sich, sobald Windows im Spiel ist, sobald Live-Migration zwischen Servern gebraucht wird, oder wenn eine Software so unklar in ihren Ansprüchen ist, dass eine strikte Trennung vom Host beruhigender wirkt. Im Zweifel gilt: Lieber einen LXC-Container zu viel angelegt als eine VM, die nur ungenutzt Ressourcen frisst.