GPU-Passthrough unter Proxmox: Anleitung und Fallen

Eine Grafikkarte an eine virtuelle Maschine durchzureichen ist die Ausbaustufe mit dem größten Verhältnis von Aufwand zu Frust. Die Anleitungen im Netz sind zahlreich, widersprüchlich und meist auf eine bestimmte Hardware zugeschnitten.

Dieser Artikel geht anders vor: erst die Frage, ob du es überhaupt brauchst, dann die Voraussetzungen, dann die Schritte – und zuletzt die Stellen, an denen es tatsächlich hängen bleibt.

Zuerst: brauchst du es wirklich?

Passthrough bedeutet exklusive Zuweisung. Die Karte gehört danach einer VM, und der Wirt sieht sie nicht mehr. Für zwei der vier häufigsten Anwendungsfälle ist das die falsche Lösung.

Was du vorhast	Der bessere Weg
Videos umkodieren (Medienserver)	Integrierte Grafikeinheit in einen LXC-Container durchreichen
Mehrere Dienste sollen beschleunigen	Container, sie können sich das Gerät teilen
Ein Arbeitsplatz mit Bildschirm an der VM	Passthrough, ja
Rechenlast auf der GPU in einer VM	Passthrough, ja

Der erste Fall ist der häufigste. Wer nur Videos umkodieren will, spart sich den gesamten Aufwand: In einem Container reicht die Freigabe des Geräts, mehrere Container dürfen gleichzeitig darauf zugreifen, und der Wirt behält seine Bildausgabe. Warum das bei Containern einfacher ist, steht in VM oder LXC-Container.

Bleiben die beiden unteren Zeilen. Dafür lohnt der Weg.

Voraussetzungen prüfen, bevor du etwas änderst

Drei Dinge müssen stimmen. Fehlt eines, hilft keine Anleitung.

1. Die Hardware muss IOMMU können

CPU und Mainboard, und im BIOS muss es eingeschaltet sein. Die Einstellung heißt je nach Hersteller „VT-d“, „AMD-Vi“, „IOMMU“ oder „SVM“.

# Nach dem Einschalten im BIOS und einem Neustart:
dmesg | grep -e IOMMU -e DMAR

Kommt hier nichts Sinnvolles, ist alles Weitere zwecklos.

2. Die Karte muss in einer eigenen IOMMU-Gruppe sitzen

Die Gruppe ist die kleinste Einheit, die sich durchreichen lässt. Steckt die Grafikkarte in einer Gruppe mit dem Netzwerkchip, müsstest du beide zusammen durchreichen – und verlierst damit das Netz des Wirts.

for g in /sys/kernel/iommu_groups/*/devices/*; do
  # Ohne aktives IOMMU gibt es das Verzeichnis nicht, und das Suchmuster
  # bleibt unaufgelöst stehen. Ohne diese Zeile listet lspci dann jedes
  # Gerät des Rechners auf – was wie ein Ergebnis aussieht und keines ist.
  [ -e "$g" ] || { echo "Keine IOMMU-Gruppen – IOMMU ist nicht aktiv."; break; }

  n=${g#*groups/}                       # z. B. 12/devices/0000:01:00.0
  echo "Gruppe ${n%%/*}: $(lspci -nns "${g##*/}")"
done | sort -V

Diese Ausgabe ist der eigentliche Prüfstein. Sitzt die Karte sauber allein in ihrer Gruppe, ist der Rest Fleißarbeit. Sitzt sie zusammen mit anderem, hast du drei Möglichkeiten: einen anderen Steckplatz probieren, ein BIOS-Update, oder aufgeben.

Es gibt einen Kernelschalter, der Gruppen künstlich aufteilt. Er umgeht eine Sicherheitszusage der Hardware. Für einen Bastelrechner vertretbar, für alles, worauf Daten liegen, nicht. Wer ihn setzt, sollte wissen, dass die durchgereichte VM damit theoretisch auf Speicher anderer Geräte zugreifen kann.

3. Die VM muss modern aufgesetzt sein

• Maschinentyp q35
• BIOS OVMF (UEFI), dazu ein EFI-Datenträger
• Beim Gerät die Option für das primäre Anzeigegerät, wenn die Karte den Bildschirm bedienen soll

Eine bestehende VM mit älterem Maschinentyp lässt sich umstellen, aber das Gastsystem sieht danach andere Hardware. Bei Windows heißt das im Zweifel Neuaktivierung. Leg für den ersten Versuch eine neue VM an.

Die Einrichtung

IOMMU im Kernel aktivieren

Hier scheitern viele an einer Kleinigkeit: Proxmox verwendet nicht immer GRUB. Bei einer Installation mit ZFS als Wurzeldateisystem kommt in der Regel der andere Startvorgang zum Einsatz, und Änderungen an der GRUB-Konfiguration bleiben wirkungslos.

# Welcher Startvorgang ist aktiv?
proxmox-boot-tool status

Je nach Ergebnis werden die Kernelschalter an unterschiedlicher Stelle eingetragen. Auf Intel-Systemen ist intel_iommu=on nötig; auf AMD-Systemen ist IOMMU bei aktuellen Kerneln bereits aktiv, sobald es im BIOS eingeschaltet ist.

Nach jeder Änderung: Konfiguration aktualisieren, neu starten, mit dmesg prüfen. Ohne Neustart ändert sich nichts, und ohne Prüfung baut man auf einer Annahme weiter.

Die Karte vom Wirt fernhalten

Damit die Karte für die VM frei ist, darf der Grafiktreiber des Wirts sie nicht beanspruchen. Zwei Bausteine:

1. Die vfio-Module beim Start laden.
2. Den Grafiktreiber des Wirts für diese Karte ausschließen – entweder über eine Sperrliste oder gezielt über die Geräte-Kennung aus lspci -nn.

Die Zuweisung über die Geräte-Kennung ist die sauberere Variante. Sie trifft genau die gewünschte Karte. Eine pauschale Sperrliste erwischt bei zwei Karten desselben Herstellers auch die, die der Wirt behalten sollte.

Danach muss die Initramfs neu gebaut und neu gestartet werden. Zur Kontrolle:

lspci -nnk
# Beim gewünschten Gerät muss stehen:
#   Kernel driver in use: vfio-pci

Steht dort etwas anderes, ist der Durchreichversuch zwecklos – egal, was die Oberfläche anzeigt. Das ist der eine Befehl, den man vor jedem Fehlersuchversuch ausführt.

Gerät der VM zuweisen

In der Oberfläche unter Hardware, „PCI Device“. Als Rohgerät auswählen, „All Functions“ aktivieren, damit der Tonteil der Karte mitkommt.

Wo es tatsächlich hängen bleibt

Der Wirt verliert seine Bildausgabe

Reichst du die einzige Grafikkarte durch, hat der Wirt keinen Bildschirm mehr. Das ist gewollt und normalerweise unproblematisch – solange der Netzzugang steht.

Solange. Genau in dieser Konstellation ist ein Fehler in der Netzkonfiguration nicht mehr reparabel, weil auch die lokale Konsole weg ist. Wenn irgend möglich: eine zweite Grafikeinheit für den Wirt, und sei es die integrierte.

Der Neustart der VM funktioniert nicht

Manche Grafikkarten lassen sich nach einem Neustart der VM nicht sauber neu initialisieren. Das Symptom: Der erste Start läuft, der zweite hängt oder liefert kein Bild. Betroffen sind vor allem ältere AMD-Karten.

Behelfsweise hilft ein Neustart des Wirts, was den Zweck einer VM ziemlich untergräbt. Für einige Kartengenerationen gibt es ein Zusatzmodul, das das Rücksetzen nachbildet.

Das ist ein Punkt, den man vor dem Kauf prüft, nicht danach.

Der Treiber im Gast verweigert die Arbeit

Bei NVIDIA-Karten gab es jahrelang eine Erkennung virtueller Umgebungen, die den Treiber mit einem Fehler abbrechen ließ. Für Consumer-Karten wurde das seitens des Herstellers aufgegeben; mit aktuellen Treibern tritt es nicht mehr auf.

Wenn du auf Anleitungen stößt, die Optionen zum Verstecken der Virtualisierung beschreiben: Die stammen aus dieser Zeit. Probiere es erst ohne.

Es funktioniert, verbraucht aber dauerhaft Strom

Der Punkt, den keine Anleitung erwähnt. Eine durchgereichte Karte in einer laufenden VM geht selten in einen sparsamen Zustand. Bei einem Rechner, der rund um die Uhr läuft, ist das die teuerste Nebenwirkung des ganzen Aufbaus.

Miss es, bevor du dich daran gewöhnst, und rechne es hoch: Stromkostenrechner. Bei einer Karte, die nur abends gebraucht wird, kann es sich lohnen, die VM tagsüber anzuhalten.

Was es nicht kann

Eine Karte auf mehrere VMs aufteilen geht mit gewöhnlichen Consumer-Karten nicht. Die Aufteilung einer physischen Karte auf mehrere Gäste ist Server-Hardware mit entsprechender Lizenzierung vorbehalten.

Wenn mehrere Gäste beschleunigen sollen, ist der Weg über Container die praktikable Lösung – siehe oben.

Vor dem Anfangen

Der ganze Vorgang berührt Startparameter des Kernels und Treiberzuweisungen. Ein Fehler führt im schlechtesten Fall zu einem Wirt, der nicht mehr startet.

Also: vorher eine Sicherung, die auch den Wirt umfasst, und einmal überlegt, wie du an das Gerät herankommst, wenn Netz und Bildschirm weg sind. Zum Sicherungsteil: Proxmox Backup Server einrichten und Restore testen.

Und noch etwas: Eine VM mit durchgereichter Grafikkarte lässt sich nicht ohne Weiteres mit Arbeitsspeicher-Snapshot sichern oder im laufenden Betrieb migrieren. Der Zustand der Karte lässt sich nicht mitnehmen. Wer den Gast in einem Cluster betreibt, verliert damit einen Teil der Beweglichkeit – siehe Proxmox-Cluster ohne Shared Storage und Proxmox-Snapshots richtig nutzen.

Weiter im Cluster

• Proxmox VE im Homelab: der Einstieg – warum q35 und UEFI schon beim Anlegen zählen
• VM oder LXC-Container – der einfachere Weg für Medienserver
• Proxmox-Snapshots richtig nutzen – was mit durchgereichter Hardware nicht mehr geht
• Proxmox-Cluster ohne Shared Storage – und was das für die Migration bedeutet