Willkommen zurück, liebe Tech-Enthusiasten und Leidensgenossen des ewigen Tweaking! Nach meinem ersten Tauchgang in die faszinierende Welt des GPU Passthrough ist es Zeit für Teil 2 – und dieser wird, so viel sei verraten, ein echter Härtetest. Diesmal geht es ans Eingemachte: Wie schlagen sich nicht nur eine, sondern gleich zwei unterschiedliche Grafikkarten – eine AMD und eine NVIDIA – auf einem leistungsstarken Ryzen-System, wenn sie an getrennte virtuelle Maschinen (VMs) durchgereicht werden sollen? Kann mein Linux-Host dies alles stemmen, und welche Fallstricke lauern in den Tiefen der Kernel-Parameter und BIOS-Einstellungen?
Die Ausgangslage: Mein Ryzen-System und die GPUs
Bevor wir uns ins Getümmel stürzen, hier ein kurzer Blick auf die Hardware-Grundlage, die für dieses Experiment herhalten musste. Mein System basiert auf einem AMD Ryzen 9 5900X, einem Prozessor, der mit seinen 12 Kernen und 24 Threads eine exzellente Basis für anspruchsvolle VM-Workloads bietet. Als Mainboard dient ein ASUS ROG Crosshair VIII Hero (Wi-Fi), bekannt für seine Robustheit und zahlreichen PCIe-Lanes – ein entscheidender Faktor für mehrere GPUs. 64 GB DDR4 RAM und schnelle NVMe-SSDs runden das Paket ab. Als Host-Betriebssystem vertraue ich weiterhin auf Arch Linux mit einem aktuellen Kernel, da es maximale Flexibilität und Kontrolle über die Systemkomponenten bietet.
Die Hauptprotagonisten dieses Berichts sind jedoch die Grafikkarten: Für die primäre Gaming-VM kam eine NVIDIA GeForce RTX 3070 zum Einsatz, während die zweite VM, die für Linux-Gaming und bestimmte Produktivitätsanwendungen gedacht war, eine AMD Radeon RX 6700 XT erhielt. Eine kleine, integrierte GPU (z.B. von einem älteren Intel-Prozessor oder einer separaten, kleinen Karte) hätte das Leben des Hosts erleichtern können, aber der Reiz lag darin, die leistungsstarken Karten direkt vom Host zu entreißen und an die VMs zu übergeben. Das war der eigentliche Knackpunkt.
Grundlagen des GPU Passthrough – Eine kurze Auffrischung (und Vertiefung)
Für alle, die meinen ersten Bericht verpasst haben oder einfach eine Auffrischung brauchen: GPU Passthrough ermöglicht es einer virtuellen Maschine, direkten Zugriff auf eine physische Grafikkarte zu erhalten. Das Ergebnis? Nahezu native Leistung in Spielen und Anwendungen innerhalb der VM. Klingt einfach, ist es aber selten. Die Königsdisziplin ist die saubere Trennung der Hardware-Ressourcen des Hosts von denen des Gastes. Schlüsseltechnologien hierfür sind IOMMU (Input/Output Memory Management Unit) und das VFIO (Virtual Function I/O) Framework unter Linux.
Der Hauptgrund, warum ich mich dieser Herausforderung stellte, war klar: Ich wollte die Flexibilität eines Linux-Hosts (Entwicklung, Server-Dienste, generelle Produktivität) nicht missen, aber gleichzeitig auch ohne Kompromisse aktuelle AAA-Titel spielen oder spezielle Windows-Software nutzen können. Und das Ganze idealerweise auf zwei getrennten virtuellen Systemen mit voller GPU-Power.
Die Herausforderung: IOMMU-Gruppen und die Lösung
Der erste und oft größte Stolperstein auf Ryzen-Systemen sind die IOMMU-Gruppen. Diese Gruppen definieren, welche Hardware-Komponenten zusammengehören und daher nur gemeinsam an eine VM durchgereicht werden können. Im Idealfall befindet sich jede GPU in ihrer eigenen, separaten Gruppe, zusammen mit ihren zugehörigen Audio-Controllern. Die Realität auf vielen Mainboards ist jedoch eine andere: Oft sind GPUs mit anderen Geräten (z.B. USB-Controllern oder NVMe-Schnittstellen) in einer Gruppe, was ein Passthrough unmöglich macht, ohne auch die anderen Geräte abzugeben.
Auf meinem ASUS ROG Crosshair VIII Hero waren die IOMMU-Gruppen erfreulicherweise relativ sauber. Die beiden PCIe-Slots, in denen die RTX 3070 und die RX 6700 XT steckten, trennten die GPUs jeweils gut ab. Dennoch gab es kleinere Herausforderungen, die ich überwinden musste. Hier kamen die bekannten Kernel-Parameter zum Einsatz:
amd_iommu=on(für AMD CPUs) oderintel_iommu=on(für Intel CPUs)iommu=pt(für pass-through mode)- Optional, aber manchmal hilfreich:
pcie_acs_override=downstream,multifunction. Auf meinem System war dies glücklicherweise nicht zwingend notwendig, da die Gruppierung bereits gut war.
Nachdem ich diese Parameter in die GRUB-Konfiguration eingefügt und ein grub-mkconfig -o /boot/grub/grub.cfg ausgeführt hatte, konnte ich mit lspci -nnv | grep -i "VGA|audio" und for d in /sys/kernel/iommu_groups/*/devices/*; do n=${d##*/}; printf 'IOMMU Group %s %sn' "${d%/*}" "$n"; done | sort -V überprüfen, ob die GPUs mit ihren Audio-Controllern in ihren eigenen, isolierten IOMMU-Gruppen lagen.
Die Vorbereitung des Host-Systems (Arch Linux)
Die Weichenstellung für den Passthrough erforderte mehrere Schritte auf dem Host:
- Kernel-Module laden: Ich sorgte dafür, dass die Module
vfio,vfio_iommu_type1,vfio_pciundvfio_virqfdbeim Systemstart geladen wurden. - Grafikkarten-Treiber vom Host entziehen: Dies ist entscheidend, damit der Host die GPUs nicht selbst initialisiert. Die proprietären NVIDIA-Treiber (
nouveaublacklisten), sowie die AMD-Treiber (amdgpuundradeonblacklisten) mussten auf die Blacklist. Das war besonders wichtig, da das System sonst versuchen würde, beide Karten für den Host zu nutzen. - VFIO an die GPUs binden: Über die Vendor- und Device-IDs der GPUs (und ihrer zugehörigen Audio-Controller) habe ich das
vfio-pciModul gezwungen, diese Geräte zu beanspruchen. Dies geschah überoptions vfio-pci ids=10de:2487,10de:228b,1002:73bf,1002:ab28(Beispiel-IDs für die RTX 3070 und RX 6700 XT). - BIOS-Einstellungen: SVM Mode (AMD-V) musste aktiviert sein. Ebenso war „Above 4G Decoding” und „ReBAR” (Resizable BAR) eine Option, die ich aktivierte, obwohl letzteres für den Passthrough nicht zwingend erforderlich ist, aber die Gaming-Leistung verbessern kann.
Die NVIDIA-Karte im Gast-System: Der erste Kandidat
Die Windows-VM für die RTX 3070 war mein erstes Ziel. Die Konfiguration in libvirt (QEMU) war wie gewohnt komplex:
- CPU-Pinning: Um die Leistung zu maximieren und Jitter zu minimieren, habe ich dedizierte CPU-Kerne und Threads der VM zugewiesen und diese an physische Kerne des Ryzen 9 5900X gebunden.
- RAM: Ein großzügiger Anteil von 24 GB RAM wurde der VM zugewiesen.
- virtio-Treiber: Für Netzwerk, Festplattencontroller und Ballooning-Gerät wurden die virtio-Treiber verwendet, um bestmögliche I/O-Leistung zu erzielen.
- Passthrough der GPU: Die RTX 3070 samt ihres HDMI-Audio-Controllers wurde als PCI-Gerät direkt an die VM durchgereicht.
Das größte Problem, das ich bei NVIDIA-Karten im Passthrough immer wieder antreffe, ist der berüchtigte „Error 43” unter Windows. NVIDIA-Treiber erkennen, wenn sie in einer virtuellen Maschine laufen und verweigern dann ihren Dienst. Die Lösung ist das sogenannte „Hypervisor Hiding”, das der VM vortäuscht, auf echter Hardware zu laufen. Dies wird durch das Hinzufügen von Parametern wie
Nach einigen Neustarts, Treiberinstallationen in der VM und Feinabstimmungen lief die RTX 3070 schließlich in der Windows-VM. Die Leistung war beeindruckend. Spiele wie Cyberpunk 2077, Starfield oder Alan Wake 2 liefen mit hohen Details flüssig. Die FPS waren fast identisch mit einer nativen Installation auf dem Host – ein voller Erfolg!
Die AMD-Karte im Gast-System: Der zweite Kandidat
Als Nächstes war die AMD Radeon RX 6700 XT an der Reihe, die an eine zweite Windows-VM (alternativ hätte ich auch eine Linux-VM wählen können, aber für den direkten Vergleich bot sich Windows an) durchgereicht werden sollte. Die Konfiguration war ähnlich der NVIDIA-VM, mit dedizierten Kernen, RAM und virtio-Treibern.
AMD-Karten sind oft einfacher im Passthrough, da sie in der Regel keinen „Hypervisor Hiding” Trick benötigen. Allerdings sind sie berüchtigt für den sogenannten „Reset Bug”, der verhindert, dass die GPU nach dem Herunterfahren der VM korrekt zurückgesetzt wird, was einen Neustart des Hosts erforderlich machen würde, bevor die VM erneut gestartet werden kann. Glücklicherweise war mein spezifisches Modell der RX 6700 XT davon nicht betroffen, oder zumindest nicht in einer Weise, die zu einem permanenten Problem führte. Ich konnte die VM problemlos starten und neu starten, ohne den Host rebooten zu müssen – ein echter Segen!
Auch die AMD-Karte lieferte in ihrer dedizierten VM eine hervorragende Leistung. Ich testete ebenfalls anspruchsvolle Spiele und Benchmarks. Die Erfahrung war sehr nah am nativen Hardware-Betrieb. Es gab keine spürbaren Verzögerungen oder Einbußen, die auf die Virtualisierung zurückzuführen wären.
Der Härtetest: Beide GPUs im Einsatz – Gleichzeitig oder wechselnd?
Jetzt kam der eigentliche Härtetest: Was passiert, wenn beide virtuellen Maschinen gleichzeitig laufen und auf ihre jeweiligen dedizierten GPUs zugreifen? Der Plan war, die NVIDIA-VM für intensives Gaming zu nutzen, während die AMD-VM für Hintergrundaufgaben oder eine zweite Spielesession (z.B. mit Freunden) bereitstand.
Ich startete beide VMs und begann, sie jeweils zu belasten. Auf der NVIDIA-VM lief ein anspruchsvoller Spieletitel, während auf der AMD-VM ein Grafik-Benchmark oder ein weniger anspruchsvolles Spiel ausgeführt wurde. Der Ryzen 9 5900X meisterte diese Belastungssituation erstaunlich gut. Die CPU-Auslastung auf dem Host blieb in einem akzeptablen Rahmen, und die zugewiesenen Cores der VMs lieferten die erwartete Leistung. Die Systemstabilität des Host-Systems war beeindruckend – keine Abstürze, keine Hänger.
Die größte Herausforderung hierbei war das Thermalmanagement. Zwei Grafikkarten unter Volllast in einem Gehäuse erzeugen ordentlich Abwärme. Eine gute Gehäuselüftung und ein potenter CPU-Kühler waren essenziell, um die Temperaturen im grünen Bereich zu halten. Ich überwachte kontinuierlich die Temperaturen der GPUs und der CPU, und obwohl sie unter Volllast natürlich anstiegen, blieben sie im sicheren Bereich.
Die Input-Latenz war ein Punkt, den ich besonders genau beobachtete. Selbst bei simultaner Belastung beider VMs und GPUs war kein spürbarer Unterschied zur nativen Hardware zu erkennen. Maus- und Tastatureingaben (durchgereicht via dedizierte USB-Controller oder virtio-input) reagierten sofort, und die Frametimes in Spielen waren konstant.
Fallstricke und Lektionen gelernt
Trotz des Erfolgs gab es auch einige Lektionen zu lernen:
- BIOS-Updates: Manchmal können BIOS-Updates die IOMMU-Gruppierung verbessern oder verschlechtern. Ein Blick in die Changelogs ist immer ratsam.
- Kernel-Updates: Ein neues Kernel-Release kann gelegentlich die VFIO-Funktionalität beeinträchtigen oder zusätzliche Tweaks erfordern. Ein stabiler LTS-Kernel ist oft die sicherere Wahl, wenn man nicht ständig an der Konfiguration arbeiten möchte.
- USB-Controller: Für eine optimale Erfahrung ist das Durchreichen eines separaten USB-Controllers an jede VM Gold wert. So sind Maus, Tastatur und andere Peripheriegeräte fest an die VM gebunden und es gibt keine Konflikte oder Latenzen.
- Sound: Neben dem HDMI-Audio-Controller der GPU kann es sinnvoll sein, eine dedizierte Soundkarte (falls vorhanden) oder einen virtuellen Audio-Ausgang (virtio-sound) zu nutzen und diesen dann an den physischen Ausgang des Hosts weiterzuleiten.
- Netzwerk: Immer virtio-net für die beste Netzwerkperformance in den VMs verwenden.
- Die Lernkurve: GPU Passthrough ist nichts für Ungeduldige. Es erfordert Zeit, Geduld und die Bereitschaft, tief in die Materie einzutauchen. Aber die Belohnung ist ein System, das unglaublich flexibel und leistungsstark ist.
Fazit und Ausblick
Mein Erfahrungsbericht Teil 2 zum GPU Passthrough mit AMD und NVIDIA-Karten auf einem Ryzen-System hat eindrucksvoll gezeigt, dass dieses Setup nicht nur machbar, sondern auch äußerst performant und stabil sein kann. Der Härtetest mit zwei gleichzeitig laufenden, GPU-intensiven VMs wurde vom System bravourös gemeistert. Die Kombination aus der rohen Rechenleistung des Ryzen 9 5900X, der sauberen IOMMU-Gruppierung des Mainboards und der Flexibilität von Arch Linux als Host-System hat ein virtuelles Kraftpaket geschaffen, das kaum Wünsche offenlässt.
Ist es perfekt? Nein, der Installations- und Wartungsaufwand ist definitiv höher als bei einem reinen Dual-Boot-System. Aber die Vorteile – die Möglichkeit, Windows-Anwendungen mit nativer Geschwindigkeit zu nutzen, ohne Linux verlassen zu müssen, und das Ganze mit dedizierten Ressourcen für unterschiedliche Workloads – überwiegen für mich bei Weitem. Es ist ein System, das sowohl das Beste aus der Windows-Gaming-Welt als auch aus der flexiblen Linux-Umgebung vereint.
Für zukünftige Experimente schwebt mir vor, SR-IOV (Single Root I/O Virtualization) zu erforschen, um vielleicht noch granulareren Zugriff auf GPU-Ressourcen zu erhalten oder die Möglichkeit zu schaffen, eine einzige GPU an mehrere VMs aufzuteilen – aber das ist eine Geschichte für einen dritten Teil. Bis dahin bin ich mehr als zufrieden mit meinem virtualisierten Gaming- und Arbeitsplatz-Setup, das den Härtetest mit Bravour bestanden hat!