Warum eine einzelne GPU in Proxmox nicht gleichzeitig an eine VM und an LXC-Container gehen kann

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, und 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. 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 kein technisches Detail am Rande, 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, weder der Host noch ein LXC noch 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, weil Sie den Hardware-Bus nicht wirklich übergeben wie bei einer VM.

Bei LXC verwaltet der Host die GPU weiterhin und 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 heißt direkte Hardware-Kontrolle durch die VM, LXC-GPU-Zugriff heißt ein vom Host verwaltetes Gerät, das in den Container freigegeben wird. Das sind grundlegend unterschiedliche Modelle, und sie lassen sich nicht mischen. Ist die GPU für eine VM an vfio-pci gebunden, kann der Host sie nicht verwalten, und kann er sie nicht verwalten, 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 und verschwendeter Zeit.

Wenn Sie eine saubere Aufteilung wollen, brauchen Sie vGPU-Profile, also echte fraktionierte GPU-Zuweisung auf Treiberebene, und 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.

Damit sind Sie aber im Lizenzierungsterritorium, mit Treiber-Einschränkungen, Kompatibilitätsfragen und 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, weil LXCs den Host-Kernel nutzen. Ist Ihr Host-Kernel den paketierten Treibern voraus, 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.

Für manche funktionierte das, auch bei unprivilegierten LXCs. Selbst das kam aber 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. Seine Lösung war, den Containerstart um 90 Sekunden zu verzögern. Das ist die Art von Workaround, die funktioniert, bis man vergisst, warum man sie eingerichtet hat.

Privilegiertes gegen unprivilegiertes LXC

Es stellte sich auch die Frage, ob das LXC privilegiert sein muss. Eine Antwort stellte klar, dass LXCs auf dem Host-Kernel laufen, und ein anderes Beispiel zeigte erfolgreiche GPU-Nutzung in einem unprivilegierten LXC.

Sie brauchen also nicht zwingend einen privilegierten Container. Was Sie brauchen, sind korrekte Gerätezuordnungen, Cgroup-Berechtigungen und eine saubere Treiberschichtung. Womit wir wieder bei der zentralen Spannung sind.

Der Kernkonflikt: VM und LXC gleichzeitig

Ist Ihre GPU über vfio-pci an eine VM durchgereicht, kann der Host sie nicht nutzen, und kann der Host sie nicht nutzen, 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, die Container nutzen die GPU über freigegebene Gerätedateien.
3. vGPU-Konfiguration: fortgeschrittenes Setup mit fraktionierter GPU-Zuweisung sowie 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. Verwaltet der Host die GPU und gibt sie an Container frei, 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. Technisch gesehen ist es der GPU egal, wie viele Container auf sie zugreifen, solange der Host sie ordnungsgemäß verwaltet. Die Einschränkung ist architektonisch, moralisch ist sie es nicht.

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, und 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

GPU-Zugriff in LXC ist möglich, und Passthrough zu einer VM funktioniert. Beides gleichzeitig, also exklusives VM-Passthrough und host-verwaltetes LXC-Sharing, geht nicht. Sie entscheiden, wem der Geräte-Bus gehört.

Sobald Sie das verstanden haben, geht es nur noch darum, welches Eigentumsmodell am besten zu Ihrer Workload passt. Denn in Proxmox kann die GPU flexibel sein, nur nicht an zwei Orten gleichzeitig.