Proxmox-LXC oder VM als Docker-Host mit USB- oder GPU-Passthrough: Was ist einfacher zu betreiben?

Wähle einen Proxmox-LXC-Container als Docker-Host, wenn Linux-Geräteknoten sicher bereitgestellt werden können, der Host die benötigten GPU- oder USB-Treiber verwaltet und ein geringer Ressourcenbedarf oder die gemeinsame GPU-Nutzung wichtig ist. Wähle eine VM, wenn der Gast den Treiber-Stack selbst verwalten muss, ein PCI-Gerät über IOMMU isoliert werden soll oder Docker und dessen Hardwarezugriff unabhängig vom Proxmox-Host bleiben müssen. Serielle USB-Geräte eignen sich oft für beide Varianten; exklusiver GPU-Passthrough spricht meist für eine VM.

„Passthrough“ definieren, bevor LXC und eine VM verglichen werden

LXC und KVM weisen Arbeitslasten Hardware nicht auf dieselbe Weise zu. Ein LXC-Container nutzt den Kernel des Proxmox-Hosts gemeinsam und erhält daher normalerweise die Berechtigung, auf vom Host erstellte Geräteknoten wie `/dev/dri`, `/dev/ttyUSB0` oder `/dev/bus/usb` zuzugreifen. Der Host erkennt die Hardware weiterhin und lädt den Kernel-Treiber.

Eine VM führt ihren eigenen Kernel aus. Proxmox kann ein USB-Gerät emulieren, ein ausgewähltes USB-Gerät oder einen USB-Anschluss zuweisen oder über VFIO und IOMMU ein PCI-Gerät zuweisen. Der Gast lädt dann seinen eigenen Treiber und behandelt die zugewiesene Hardware eher wie ein direkt installiertes Gerät.

Der aktuelle Leitfaden zur Proxmox-NAS-Einrichtung von ZimaSpace stellt beide Gasttypen vor. Dieser Artikel grenzt die Entscheidung auf einen Docker-Host ein, dessen Container USB-Dongles, serielle Adapter, Medien-GPUs oder Rechenbeschleuniger benötigen.

USB-Geräte sprechen für LXC, wenn sie sich wie stabile Linux-Geräteknoten verhalten

USB-Seriell-Adapter, Zigbee-Koordinatoren, USV-Schnittstellen, Coral-USB-Beschleuniger und ähnliche Geräte funktionieren gut mit LXC, wenn Proxmox den Geräteknoten freigibt und die richtigen Besitzrechte zuordnet. Der Docker-Container innerhalb von LXC erhält dieses Gerät dann über seine Linux-Hostumgebung.

Eine praktische Erklärung zum USB-Zugriff in Proxmox LXC zeigt das zugrunde liegende Prinzip: Das Einbinden des Geräts reicht nicht aus, wenn der Container nicht auch darauf zugreifen darf.

Verwenden Sie stabile Pfade wie `/dev/serial/by-id`, sofern die Anwendung sie unterstützt. Busnummern und Zuweisungen wie `/dev/ttyUSB0` können sich nach einem Neustart oder einer erneuten Verbindung ändern. Die LXC-Lösung wird fehleranfällig, wenn nach jedem Host-Update cgroup-, UID-, GID- oder Gerätepfad-Einstellungen manuell korrigiert werden müssen.

Eine VM ist die sauberere Lösung, wenn die USB-Zuständigkeit vollständig gekapselt sein muss

Eine VM kann ein USB-Gerät anhand von Hersteller- und Produkt-ID oder über einen physischen Anschluss zugewiesen bekommen und den Gerätetreiber dann im eigenen Betriebssystem laden. Das ist nützlich, wenn das Gerät ein Herstellerpaket, eine andere Kernelversion oder einen Anwendungs-Stack benötigt, der nicht von den Proxmox-Hostbibliotheken abhängen soll.

Die VM schafft außerdem eine klarere Diagnosegrenze. Verliert die Gastumgebung das USB-Gerät, kann der Administrator zuerst die Einbindung durch den Hypervisor und anschließend den Gasttreiber prüfen. Bei LXC sind Hosttreiber, Geräteknoten, Berechtigungen, Container-Zuordnung, Docker-Laufzeitumgebung und Anwendung Teil derselben Kette.

Der Kompromiss liegt im Verhalten beim erneuten Verbinden. Manche USB-Geräte werden zurückgesetzt, ändern ihre Identität oder verschwinden beim Neustart der Gastumgebung. Testen Sie das Abziehen des Geräts, einen Host-Neustart, einen Neustart der Gastumgebung und die Wiederherstellung der Anwendung, statt anzunehmen, dass eine erfolgreiche erste Verbindung einen stabilen Betrieb garantiert.

Featured

ZimaBoard 2 - Mini-Home-Server für Ihre große Idee

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Gemeinsam genutzter GPU-Zugriff spricht meist für LXC

Bei Intel- oder AMD-Rendergeräten und unterstützten NVIDIA-Workloads kann LXC mehreren Linux-Diensten Zugriff auf die GPU-Geräteknoten des Hosts gewähren. Die GPU bleibt dem Proxmox-Hosttreiber unterstellt, sodass mehrere Container Hardware-Transkodierung oder Rechenaufgaben nutzen können, ohne das gesamte PCI-Gerät einer einzelnen Gastumgebung zuzuweisen.

Das aktuelle Proxmox-Beispiel von XDA erklärt, wie LXC die vom Host verwaltete GPU gemeinsam nutzen kann, statt sie per VM-Passthrough exklusiv zuzuweisen. Dasselbe Betriebsmodell eignet sich für Jellyfin, Plex, Frigate oder mehrere Docker-Dienste, sofern Treiber- und Berechtigungsanforderungen erfüllt sind.

Die gemeinsame Nutzung führt zu Versionsabhängigkeiten. Der Host-Kerneltreiber, die User-Space-Bibliotheken in LXC, die Docker-Laufzeitintegration und die Anwendungspakete müssen kompatibel bleiben. Ein Upgrade des Proxmox-Kernels oder -Treibers kann sich daher gleichzeitig auf alle Container auswirken, die die GPU nutzen.

Exklusives GPU-Passthrough spricht meist für eine VM

Eine VM ist die bessere Wahl, wenn ein Workload direkten Zugriff auf eine dedizierte GPU, einen proprietären Gasttreiber, Windows-Unterstützung, CUDA-Isolation oder einen Kernel-Stack benötigt, der nicht auf Proxmox installiert werden soll. Die VFIO-Zuweisung trennt das Gerät vom Host und stellt es dem Gast bereit.

Das PCI-Modell von Proxmox ist auf die Zuweisung eines physischen PCI-Geräts an einen KVM-Gast ausgelegt. Eine Docker-Diskussion auf Level1Techs bringt die praktische Folge auf den Punkt: Eine VM nutzt die durchgereichte GPU normalerweise exklusiv, während LXC den Zugriff des Hosts auf das Gerät zwischen Diensten teilen kann.

Diese Wahl kann sich umkehren, wenn die GPU vermittelte Geräte oder SR-IOV unterstützt. Consumer-GPUs und Home-Server-Plattformen bieten jedoch keine universelle Möglichkeit zur gemeinsamen Nutzung. Prüfe IOMMU-Gruppen, das Reset-Verhalten, die Firmware, die Displayinitialisierung und ob der Host diese GPU benötigt, bevor du eine ausschließliche Passthrough-Nutzung einplanst.

Docker in LXC fügt eine verschachtelte Verwaltungsebene hinzu

LXC bietet bereits Isolation auf Betriebssystemebene, und Docker fügt darin eine weitere Container-Laufzeitumgebung hinzu. Das kann effizient sein, bringt aber verschachtelte Namespaces, cgroups, Speichertreiber, Capabilities und Mount-Verhalten mit sich. Einige Docker-Funktionen erfordern Verschachtelungsoptionen oder zusätzliche Berechtigungen im Proxmox-Container.

Eine VM stellt Docker einen herkömmlichen Linux-Host bereit. Docker-Dokumentation, Kernelmodule, Firewall-Verhalten und Speichertreiber lassen sich leichter nachvollziehen, weil der Gast seine Kernelkonfiguration selbst verwaltet. Dafür fallen ein vollständiges Gastbetriebssystem, reservierter Arbeitsspeicher, die Verwaltung virtueller Festplatten und eine zusätzliche Patch-Ebene an.

Wähle LXC nicht nur, um ein paar hundert Megabyte zu sparen, wenn die erforderliche Konfiguration einen privilegierten Container, weitreichende Geräteberechtigungen und undokumentierte Änderungen am Host erzwingt. Die schlanke Option verliert an Wert, wenn jedes Upgrade davon abhängt, dass du dir Ausnahmen merkst, die die VM innerhalb des Gasts kapseln würde.

Isolation und Sicherheit können den Leistungssieger umkehren

LXC nutzt den Kernel des Hosts gemeinsam. Ein falsch konfigurierter privilegierter Container oder eine zu weit gefasste Gerätezuordnung kann daher mehr vom Proxmox-Knoten offenlegen als beabsichtigt. Nicht privilegiertes LXC, eng gefasste Geräteberechtigungen, schreibgeschützte Einbindungen und minimale Fähigkeiten verbessern die Abschottung, doch die Architektur bleibt stärker gekoppelt als bei einer vollständigen VM.

Eine VM stellt einen separaten Kernel bereit und kann proprietäre GPU-Stacks, Docker-Netzwerke, Firewall-Module und experimentelle Software von der Proxmox-Basis isolieren. Diese Trennung ist wertvoll, wenn der Docker-Host Images von Drittanbietern, öffentliche Dienste, lokale KI-Pakete oder häufige Treiberexperimente ausführt.

Die VM ist nicht automatisch sicher. PCI-Passthrough, gemeinsam genutzte Speichereinbindungen, Verwaltungszugangsdaten und überbrückte Netzwerke schaffen weiterhin Angriffs- und Fehlerquellen. Wählen Sie sie, wenn die unabhängige Kernel- und Treibergrenze das Bedrohungs- und Wartungsmodell tatsächlich vereinfacht.

Backups und Migration sprechen für unterschiedliche Arten von Einfachheit

LXC-Backups sind kompakt und schnell, da der Gast keinen vollständigen virtuellen Hardware-Stack enthält. Um den Hardwarezugriff auf einem anderen Proxmox-Knoten wiederherzustellen, müssen jedoch Geräteknoten, Gruppen, Treiber und Berechtigungen übereinstimmen. Das Container-Dateisystem kann migriert werden, die Vereinbarung zur Nutzung des physischen Geräts jedoch nicht.

Ein VM-Backup enthält das Gastbetriebssystem und die Treiberkonfiguration, wodurch sich Anwendungen eigenständiger wiederherstellen lassen. USB-Verbindungen und PCI-Adressen müssen auf dem Zielsystem weiterhin neu zugeordnet werden, und eine durchgereichte GPU kann die Live-Migration verhindern, weil das physische Gerät an einen einzelnen Knoten gebunden ist.

Der Proxmox-Backup-Workflow von ZimaSpace schützt Gäste. Für diesen Vergleich gilt die Wiederherstellung erst dann als abgeschlossen, wenn Docker startet und die auf USB oder GPU angewiesene Anwendung das Ersatzgerät erkennt.

Testen Sie die Wiederherstellung von Geräten, bevor Sie den Gasttyp auswählen

1. Listen Sie alle USB- und PCI-Geräte auf, die die Docker-Anwendungen benötigen.
2. Entscheiden Sie für jedes Gerät, ob es gemeinsam mit dem Host genutzt oder einem einzelnen Gast zugewiesen werden soll.
3. Testen Sie den Host-Treiber, den Geräteknoten, die UID/GID-Zuordnung und die Docker-Berechtigungen für LXC.
4. Testen Sie die IOMMU-Gruppierung, die Treiberinstallation im Gast und das Rücksetzverhalten einer VM.
5. Starten Sie den Proxmox-Host neu und bestätigen Sie, dass die Gerätezuordnung automatisch wiederhergestellt wird.
6. Stellen Sie den Gast aus dem Backup wieder her und richten Sie die Hardware-Zuordnung anhand der Dokumentation erneut ein.
7. Wiederholen Sie den Test auf einem anderen kompatiblen Knoten, wenn Migration oder Hardwareaustausch wichtig sind.

Messen Sie das Verhalten der Anwendungen und nicht nur den Overhead des Gasts. Stabilität der Hardware-Transkodierung, Wiederverbindung von USB-Geräten, Treiberaktualisierungen, Host-Wartung und Wiederherstellungszeit sind meist wichtiger als ein geringer CPU-Unterschied zwischen LXC und KVM.

Welcher Proxmox-Gast eignet sich für den Docker-Host?

Wann Sie LXC wählen sollten

Wählen Sie LXC, wenn alle Workloads auf Linux basieren, der Host die Treiber verwalten kann, USB-Geräte stabile Gerätenamen haben und eine GPU von mehreren Diensten gemeinsam genutzt werden soll. Lassen Sie den Container nach Möglichkeit unprivilegiert und dokumentieren Sie jede Geräte- und Gruppenzuordnung.

Wann Sie eine VM wählen sollten

Wählen Sie eine VM, wenn der Docker-Host exklusiven Zugriff auf die PCI-GPU, proprietäre oder experimentelle Treiber, stärkere Kernel-Isolierung oder eine einfachere Portabilität des gesamten Softwarestacks benötigt. Planen Sie ausreichend RAM und Speicher für den Gast ein und testen Sie das Zurücksetzen des Geräts nach einem Neustart.

Wann sich die Aufteilung der Workloads lohnt

Führen Sie leichte Medien- und USB-Dienste in LXC aus und betreiben Sie rechenintensive GPU-Aufgaben mit exklusivem Zugriff, Windows-abhängige Tools oder nicht vertrauenswürdige Docker-Stacks in einer VM. Eine Proxmox-fähige Plattform kann beides unterstützen, doch für jedes physische Gerät sollte ein dokumentiertes Zuordnungsmodell festgelegt werden.

FAQs

Kann Docker zuverlässig in einem unprivilegierten LXC ausgeführt werden?

Ja, für viele Workloads. Verschachtelung, Speichertreiber, Einbindungen, Netzwerk und Gerätezugriff können jedoch zusätzliche Konfiguration erfordern. Testen Sie die konkreten Docker-Funktionen und wechseln Sie nicht zu einem privilegierten Container, nur um ein unerklärliches Berechtigungsproblem zu umgehen.

Kann eine GPU sowohl von einem LXC als auch von einer VM genutzt werden?

Nicht gleichzeitig über gewöhnliches VFIO-Passthrough des gesamten Geräts. LXC kann ein vom Host verwaltetes Rendergerät gemeinsam nutzen, während das Gerät für eine VM normalerweise vom Host getrennt werden muss. SR-IOV oder die Unterstützung für vermittelte Geräte können dies bei bestimmter Hardware ändern.

Welche Option eignet sich besser für einen USB-Zigbee-Koordinator?

Beides kann funktionieren. LXC ist effizient, wenn ein stabiler Pfad über die Geräte-ID und zuverlässige Berechtigungen gewährleistet sind. Eine VM ist die sauberere Lösung, wenn der Softwarestack oder Treiber des Koordinators unabhängig vom Proxmox-Host bleiben soll.

Fazit

Verwenden Sie LXC für einen Docker-Host, wenn USB- und GPU-Ressourcen über den Linux-Treiberstack des Proxmox-Hosts gemeinsam genutzt werden können und ein geringer Overhead wichtig ist. Verwenden Sie eine VM, wenn die Hardware dem Gast gehören soll, Treiber isoliert werden müssen oder bei der Wiederherstellung ein eigenständiges Betriebssystem erhalten bleiben soll. Entscheiden Sie anhand der Gerätezuordnung und des Wiederherstellungsverhaltens, nicht in der Annahme, dass Container immer einfacher sind.