„Man kann nicht beides haben”: Die harte Wahrheit über das Teilen einer einzelnen GPU zwischen VMs und LXC in Proxmox

Es beginnt immer mit Schwung.

Sie bekommen GPU-Passthrough für eine VM in Proxmox 9.1.1 endlich zum Laufen. Das PCIe-Gerät erscheint sauber. Die VM bootet. Treiber installieren sich. CUDA funktioniert. Sie fühlen sich unaufhaltsam.

Dann kommt der nächste Gedanke: Kann ich das auch für LXC-Container machen?

Genau das ist der Scheideweg hier. GPU-Passthrough funktioniert einwandfrei für VMs – aber sobald Sie fragen, ob dieselbe GPU auch von LXC-Containern genutzt werden kann, wird die Antwort schnell unangenehm.

Denn was wie eine kleine Erweiterung aussieht, ist in Wirklichkeit ein fundamentaler architektonischer Konflikt.

Passthrough zu einer VM bedeutet Loslassen

Ein Kommentator hat es klar auf den Punkt gebracht: Wenn Sie ein PCIe-Gerät an eine VM durchreichen, interagiert der Proxmox-Host nicht mehr damit.

Das ist nicht nur ein technisches Detail. Das ist der gesamte Sinn von Passthrough.

Die PCIe-Kommunikation wird direkt an die VM übergeben. Der Host lädt keine Treiber. Er verwaltet das Gerät nicht. Er tritt zur Seite.

Und sobald das passiert, kann nichts anderes es nutzen. Nicht der Host. Nicht ein LXC. Nicht eine andere VM.

Die GPU wird exklusives Eigentum dieses einen Gasts.

Wenn Ihr Plan also lautet: „GPU-Passthrough zur VM behalten und die GPU gleichzeitig LXC-Containern zugänglich machen", kämpfen Sie gegen die Definition von Passthrough selbst an.

LXC-„Passthrough" ist nicht dasselbe

Hier stolpern die meisten über die Terminologie.

Ein anderer Nutzer erklärte, dass das Durchreichen eines PCIe-Geräts an ein LXC eigentlich eine Fehlbezeichnung ist. Sie übergeben nicht wirklich den Hardware-Bus wie bei einer VM.

Bei LXC verwaltet der Host die GPU weiterhin. Der Host lädt die Kernel-Module. Dann geben Sie Gerätedateien in den Container frei, damit dieser die Fähigkeiten der GPU nutzen kann.

Dieser Unterschied ist entscheidend.

VM-Passthrough = direkte Hardware-Kontrolle durch die VM.

LXC-GPU-Zugriff = vom Host verwaltetes Gerät, das in den Container freigegeben wird.

Das sind grundlegend unterschiedliche Modelle.

Und sie lassen sich nicht mischen.

Wenn die GPU für eine VM an vfio-pci gebunden ist, kann der Host sie nicht verwalten. Wenn der Host sie nicht verwalten kann, kann er sie auch nicht für LXC freigeben.

Sie müssen sich für eines der beiden Modelle entscheiden.

„Kann ich sie auf mehrere LXCs aufteilen?"

Jetzt wird das Gespräch pikanter.

Ein Kommentator sagte ja, es sei möglich, die GPU an ein LXC durchzureichen – riet aber dringend davon ab, Passthrough für mehrere LXCs mit derselben GPU zu verwenden.

Die Begründung ist einfach: Passthrough ist darauf ausgelegt, dass eine Maschine den gesamten Geräte-Bus besitzt.

Der Versuch, ihn auf dieser Ebene zu „teilen", führt zu Instabilität. Fehlern. Merkwürdigem Verhalten. Zeitverschwendung.

Wenn Sie eine saubere Aufteilung wollen, brauchen Sie vGPU-Profile – echte fraktionierte GPU-Zuweisung auf Treiberebene.

Das ist ein völlig anderes Biest.

Ohne vGPU bitten Sie im Grunde mehrere Workloads, gleichzeitig nach demselben physischen Lenkrad zu greifen.

Es könnte sich bewegen. Es könnte abstürzen.

Elegant ist das selten.

Die vGPU-Versuchung

Ein weiterer Kommentar deutete den Unterschied zwischen Passthrough und vGPU an. Bei vGPU vermittelt der Host die Kommunikation, statt sich vollständig vom Geräte-Bus zurückzuziehen.

Das ist die saubere Methode, eine GPU in Scheiben zu schneiden.

Aber jetzt sind Sie im Lizenzierungsterritorium. Treiber-Einschränkungen. Kompatibilitätsfragen. NVIDIA-Richtlinien. Plötzlich wird aus „Kann ich meine GPU teilen?" die Frage „Wie tief will ich in die Enterprise-Virtualisierung eintauchen?"

Für Homelab-KI-Workloads über mehrere LXCs hinweg kann diese Komplexität schnell eskalieren.

Kernel-Mismatch und Treiber-Frust

Dann gibt es noch die Proxmox-9.1.1-Falte.

Der ursprüngliche Poster stieß auf NVIDIA-Paketprobleme, die nicht zum neuesten Kernel passten.

Das ist ein häufiger Proxmox-Schmerzpunkt. LXCs nutzen den Host-Kernel. Wenn Ihr Host-Kernel den paketierten Treibern voraus ist, bleibt Ihnen nur, selbst zu kompilieren oder den NVIDIA-.run-Installer zu verwenden.

Und genau das beschrieben andere, getan zu haben:

• NVIDIA-Treiber über die .run-Datei auf dem Host installieren.
• Nouveau dadurch deaktivieren lassen.
• Neu starten.
• Im LXC nur die User-Space-Utilities mit --no-kernel-module installieren.

Es funktionierte für manche – auch bei unprivilegierten LXCs.

Aber selbst das kam mit Vorbehalten. Ein Nutzer erwähnte Timing-Probleme beim Neustart, bei denen das LXC versuchte, Treiber zu initialisieren, bevor der Host das Laden abgeschlossen hatte. Die Lösung? Den Containerstart um 90 Sekunden verzögern.

Das ist die Art von Workaround, die funktioniert … bis man vergisst, warum man sie eingerichtet hat.

Privilegiertes vs. unprivilegiertes LXC

Es stellte sich auch die Frage: Muss das LXC privilegiert sein?

Eine Antwort stellte klar, dass LXCs auf dem Host-Kernel laufen. Ein anderes Beispiel zeigte erfolgreiche GPU-Nutzung in einem unprivilegierten LXC.

Nein, Sie brauchen also nicht zwingend einen privilegierten Container. Aber Sie brauchen korrekte Gerätezuordnungen, Cgroup-Berechtigungen und eine saubere Treiberschichtung.

Womit wir wieder bei der zentralen Spannung sind.

Der Kernkonflikt: VM + LXC gleichzeitig

Wenn Ihre GPU über vfio-pci an eine VM durchgereicht ist, kann der Host sie nicht nutzen.

Wenn der Host sie nicht nutzen kann, kann er sie nicht für LXC freigeben.

Das ist die harte Grenze.

Ihre echten Optionen sehen also so aus:

1. GPU-Passthrough zu einer einzelnen VM.

Maximale Isolation. Kein Host-Zugriff. Keine LXC-Nutzung. 2. Host-verwaltete GPU, geteilt an mehrere LXCs.

Kein VM-Passthrough. Container nutzen die GPU über freigegebene Gerätedateien. 3. vGPU-Konfiguration.

Fortgeschrittenes Setup. Fraktionierte GPU-Zuweisung. Lizenzierungs- und Treiberkomplexität.

Was Sie nicht sauber machen können, ist die GPU an eine VM zu binden und gleichzeitig zu erwarten, dass sie mehrere LXCs bedient.

So funktioniert PCIe-Passthrough nicht.

Die Lizenzierungsangst

Es gab sogar Bedenken, dass NVIDIA „Gebühren verlangt", wenn mehrere Container die GPU nutzen.

Diese Befürchtung entsteht oft aus einer Verwechslung zwischen physischer GPU-Nutzung und virtualisierten Enterprise-Funktionen. Wenn der Host die GPU verwaltet und sie an Container freigibt, ist es immer noch eine physische GPU auf einer Maschine.

Lizenzierungskomplikationen kommen in der Regel erst ins Spiel, wenn Sie vGPU- oder Enterprise-Virtualisierungsfunktionen nutzen.

Aber technisch gesehen ist es der GPU egal, wie viele Container auf sie zugreifen – solange der Host sie ordnungsgemäß verwaltet.

Die Einschränkung ist architektonisch, nicht moralisch.

Was sollten Sie also tun?

Wenn Sie mehrere KI-fokussierte LXCs benötigen, die die GPU nutzen, lösen Sie sie von vfio-pci und lassen Sie den Host sie verwalten.

Installieren Sie Treiber auf dem Host. Geben Sie /dev/nvidia* in Container frei. Handhaben Sie Kernel-Neukompilierungen, wenn nötig. Akzeptieren Sie die gelegentliche Unannehmlichkeit der Treiberpflege.

Wenn Sie eine einzelne High-Performance-VM mit vollständigem Hardware-Eigentum benötigen, bleiben Sie bei Passthrough – und akzeptieren Sie, dass die GPU allein dieser VM gehört.

Der Versuch, beides gleichzeitig zu tun, ist der Ort, an dem Frustration entsteht.

Die Architektur biegt sich nicht, nur weil die Hardware leistungsstark ist.

Fazit

Ja, GPU-Zugriff in LXC ist möglich.

Ja, Passthrough zu einer VM funktioniert.

Nein, Sie können nicht gleichzeitig exklusives VM-Passthrough und host-verwaltetes LXC-Sharing haben.

Sie entscheiden, wem der Geräte-Bus gehört.

Und sobald Sie das verstanden haben, lautet die Frage nicht mehr „Ist es möglich?"

Sondern: Welches Eigentumsmodell passt am besten zu Ihrer Workload?

Denn in Proxmox kann die GPU flexibel sein.

Sie kann nur nicht an zwei Orten gleichzeitig sein.