1. Einleitung
Die Virtualisierungstechnologie hat in den letzten Jahren erhebliche Fortschritte gemacht und ermöglicht es Benutzern, mehrere Betriebssysteminstanzen auf einem einzigen physischen Host auszuführen. Eine der fortgeschrittenen Anwendungen dieser Technologie ist die GPU-Passthrough, bei der eine dedizierte Grafikkarte direkt an eine virtuelle Maschine weitergeleitet wird. Diese Methode ermöglicht es, die Leistung und Funktionalität der Grafikkarte vollständig in der virtuellen Umgebung zu nutzen, was besonders für Anwendungen wie Gaming, Grafikdesign und Datenverarbeitung von Vorteil ist.
Unter Linux bietet die Kombination von QEMU/KVM eine leistungsstarke Plattform für die Virtualisierung, die es ermöglicht, eine Windows 10-Instanz in einer virtuellen Maschine auszuführen und dabei die GPU-Passthrough-Technik zu nutzen. Durch diese Konfiguration kann ein Benutzer ein Windows-Betriebssystem mit vollständiger Grafikbeschleunigung in einer isolierten Umgebung ausführen, ohne die Leistungseinbußen zu erleiden, die oft mit herkömmlichen Virtualisierungsmethoden verbunden sind.
In dieser Arbeit wird die Einrichtung und Konfiguration von GPU-Passthrough unter Linux mit QEMU/KVM für die Ausführung einer virtuellen Windows 10-Maschine detailliert behandelt. Zunächst werden die Voraussetzungen und Hardware-Anforderungen erläutert, gefolgt von den Schritten zur Einrichtung der Virtualisierungsumgebung. Anschließend wird die Konfiguration der GPU-Passthrough-Funktion beschrieben, einschließlich der erforderlichen Treiberinstallationen und Konfigurationsanpassungen. Darüber hinaus werden bewährte Methoden zur Optimierung der Leistung und Stabilität diskutiert sowie potenzielle Herausforderungen und Lösungen bei der Implementierung von GPU-Passthrough unter Linux behandelt.
Insgesamt bietet die GPU-Passthrough-Technik unter Linux mit QEMU/KVM eine leistungsstarke Lösung für Benutzer, die die Vorteile der Virtualisierung nutzen möchten, ohne Kompromisse bei der Grafikleistung einzugehen. Diese Arbeit soll als umfassende Anleitung dienen, um Benutzern bei der erfolgreichen Einrichtung und Konfiguration dieser fortschrittlichen Virtualisierungstechnik zu unterstützen.
Inhalt
2. Ziel
Windows 10 in einer virtuellen Maschine auf einem Linux Desktop unter Qemu/KVM zu betreiben. Dabei soll eine 2. Grafikkarte so durchgereicht werden, als ob diese in einem Windows 10 PC stecken würde, so daß auch grafisch aufwendige Spiele oder Anwendungen möglich sind. Ferner soll ansonsten keine weitere Hardware, wie eine zusätzliche Tastatur/Maus Kombination benötigt werden.
3. Voraussetzung
Damit die Grafikkarte komplett an eine virtuelle Maschine durchgereicht werden kann, sind einige Voraussetzungen zu erfüllen:
- Es wird ein Prozessor von Intel oder AMD, mitsamt des passenden Mainboards benötigt, das die Virtualisierung beherrscht. Im BIOS des Mainboards muss zum einen IOMMU verfügbar und auch aktiviert sein, sowie SVM (bei AMD Systemen) oder Vt-x als auch Vt-d (bei Intel Systemen). Bei Rechnern der letzten Jahre sollte dies problemlos möglich und aktivierbar sein. Je besser der Chipsatz auf dem Mainboard, desto weniger Probleme sind zu erwarten.
- Es werden zwei Grafikkarten (GPUs) benötigt. Entweder in der Form, dass schon auf dem Mainboard, bzw. Prozessor eine GPU integriert ist, oder das zwei PCIe Grafikkarten im Rechner eingesteckt sind. Die Grafikkarte, die durchgereicht werden soll, muss den UEFI Boot Modus unterstützen. Ggf. kann dieser bei einigen Modellen per Firmwareupdate nachgerüstet werden.
- Viele Grafikkarten schalten sich quasi ab, wenn kein Monitor angeschlossen ist. Es muss also dafür gesorgt werden, dass die Grafikkarte einen Monitor erkennt. Dazu gibt es drei Möglichkeiten:
- Ein weiterer externer Monitor
- Der Hauptmonitor besitzt mindestens einen weiteren Eingang
- Einen sogenannten “DDC Dummy Plug“. Das ist ein kleiner Dongle, der in den Ausgang der Grafikkarte gesteckt wird. Dieser täuscht der Grafikkarte vor, das ein aktiver Monitor angeschlossen ist. Diese gibt es für HDMI, Displayport und auch DVI.
- Lauffähige Qemu/KVM Installation, wie zum Beispiel HIER beschrieben.
- Windows 10 x64 mit entsprechender Lizenz und Key zum installieren.
Meine, in diesem Beispiel verwendete Hardware sieht wie folgt aus:
- AMD Ryzen 9 3950X CPU auf einem Gigabyte X570 AORUS MASTER Mainboard
- AMD ATI Radeon RX 5700 XT Grafikkarte für Linux (im ersten PCIe Slot)
- AMD ATI Radeon RX 5500 XT Grafikkarte für Windows 10 (im zweiten PCIe Slot)
- 128GB RAM
4. Installation
4.1 IOMMU im Host aktivieren
Der entsprechende Paramter wird beim Booten des Linux Host Rechners über den Grub Bootmanager mitgegeben. Dazu muss die Datei /etc/default/grub editiert werden. In dieser Datei befindet sich eine Zeile, die mit GRUB_CMDLINE_LINUX_DEFAULT= beginnt. Diese muss um weitere Parameter ergänzt werden.
4.1.1 Intel Systeme
IOMMU aktivieren -> intel_iommu=on
IOOMU Passthrough aktivieren -> iommu=pt
In meiner Konfiguration standen schon zwei vorhandene Parameter, die dann um die beiden oben genannten erweitert werden müssen:
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_enforce_resources=lax intel_iommu=on iommu=pt"
4.1.2 AMD Systeme
Bei AMD ist es ähnlich, nur das hier das Schlüsselwort Intel durch AMD ersetzt wird.
IOMMU aktivieren -> amd_iommu=on
IOOMU Passthrough aktivieren -> iommu=pt
In meiner Konfiguration standen schon zwei vorhandene Parameter, die dann um die beiden oben genannten erweitert werden müssen:
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_enforce_resources=lax amd_iommu=on iommu=pt"
4.1.3 GRUB Bootloader aktualisieren
Anschließend muss mit dem Befehl update-grub das System aktualisieren:
$ sudo update-grub
4.2 Grafikkarte für die VM zuweisen
VFIO (Virtual Function I/O) ist eine Technologie, die es ermöglicht, Hardwaregeräte direkt an virtuelle Maschinen (VMs) anzubinden, die unter einem Hypervisor wie QEMU/KVM (Kernel-based Virtual Machine) laufen. Es ermöglicht eine nahezu native Leistung und Zugriff auf Hardware-Ressourcen für virtuelle Maschinen, was besonders wichtig ist für Anwendungen, die eine hohe Leistung erfordern, wie zum Beispiel 3D-Grafikanwendungen, Spiele oder Hochleistungsrechenanwendungen.
Normalerweise ist der Zugriff auf Hardwaregeräte durch den Hypervisor (wie KVM) beschränkt, da dieser die Ressourcen verwaltet und zwischen den virtuellen Maschinen aufteilt. VFIO umgeht diese Beschränkungen, indem es eine Schnittstelle bereitstellt, über die bestimmte Hardwaregeräte (wie Grafikkarten, Netzwerkkarten oder Speichergeräte) direkt von einer virtuellen Maschine angesprochen werden können, ohne dass der Hypervisor dazwischengeschaltet ist.
Durch die Verwendung von VFIO kann eine bessere Leistung und eine geringere Latenz für VM-Anwendungen erreicht werden, indem diese den direkten Zugriff auf bestimmte Hardwaregeräte ermöglichen.
4.2.1 IDs heraus suchen
Im weiteren Verlauf wird sowohl die PCI-ID, als auch die Vendor- und Device ID der Grafikkarte benötigt. Diese kann über den Befehl lspci ausgelesen werden:
$ lspci -nn
Es kommt, je nach System und Hardwareausstattung eine recht lange Liste mit Geräten, die am PCI Bus des Rechners hängen. Bei mir sieht die Liste (gekürzt dargestellt) so aus:
... 0d:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch [1002:1478] (rev c1) 0e:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch [1002:1479] 0f:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c1) 0f:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38] 10:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch [1002:1478] (rev c5) 11:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch [1002:1479] 12:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] [1002:7340] (rev c5) 12:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38] 13:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a] 14:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] ...
In einem AMD System wird man extrem viele AMD Einträge finden, weswegen es hier keinen Sinn macht, nach AMD einzuschränken. Dazu kommt noch, dass heutige Grafikkarten auch eine Soundkarte integriert haben, die ebenfalls durchgereicht werden muss.
Am besten sucht man als erstes nach dem Begriff “VGA”, bzw. schränkt die suche mit lspci -nn | grep VGA entsprechend ein. Es sollten zwei Einträge zurück geliefert werden:
0f:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c1) 12:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] [1002:7340] (rev c5)
Am Anfang der Zeile steht die PCI-ID, also die Nummer, die ein Gerät im PCI-Bus erhalten hat. Man sieht hier auch die Kennung der jeweiligen Grafikkarte, also die RX 5600 und RX 5500. Letztere möchte ich für Windows benutzen. Also wäre hier die PCI-ID 12:00.0 die richtige. Die letzte Ziffer gibt dabei eine aufsteigende Kennung an, wenn mehrere Funktionen in einem PCI Gerät vorhanden sind, wird diese fortgezählt.
Also jetzt einfach auf diese ID eingrenzen, also in diesem Beispiel die 12:00, denn die 0f:00 ist die Grafikkarte des Host Betriebssystemes, als Linux:
$ lspci -nn | grep 12:00
Und schon bekommt man genau die Informationen, die benötigt werden:
12:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] [1002:7340] (rev c5) 12:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38]
Am besten notiert man sich nun die beiden Zeilen in einem Editor, und behält diese bis zum Ende. Benötigt werden die PCI-ID am Anfang der beiden Zeile und die Zahlen innerhalb der eckigen Klammer [xxxx:xxxx]:
- 12:00.0 –> [1002:7340]
- 12:00.1 –> [1002:ab38]
4.2.2 Kernelmodul konfigurieren
4.2.2.2 Sofern zwei Grafikkarten gleichen Herstellers verwendet wird
Wenn also beide Grafikkarten AMD/AMD oder NVIDA/NVIDIA sind, gilt diese Sektion, ansonsten zum nächsten Punkt springen.
Nun werden die Vendor und Device IDs in die Datei /etc/modprobe.d/vfio.conf eingetragen, bzw. neu erstellt. Dazu mit root diese Datei öffnen und folgendes eintragen:
options vfio-pci ids=1002:7340,1002:ab38 softdep amdgpu pre: vfio-pci
Hat man eine Nvidia Grafikkarte, so lautet die zweite Zeile softdep nouveau pre: vfio-pci.
4.2.2.3 Grafikkarten unterschiedlicher Hersteller
Hat man Grafikkarten von zwei verschiedenen Herstellern verbaut, muss die Karte, die für die VM benutzt werden soll, geblacklistet werden. Damit diese nicht versehentlich auch unter Linux verwendet werden kann, was zu Konflikten führen würde und beim starten der VM einen Systemcrash auslöst.
Das wird als erstes die Datei /etc/modprobe.d/blacklist.conf mit root Rechten editiert und folgender Eintrag hinzugefügt, sofern die Karte für Windows vom Hersteller NVIDIA ist:
blacklist nouveau
Für eine Grafikkarte des Herstellers AMD würde der Eintrag wie folgt lauten:
blacklist amdgpu
Nun werden die Vendor und Device IDs in die Datei /etc/modprobe.d/vfio.conf eingetragen, bzw. neu erstellt. Dazu mit root diese Datei öffnen und folgendes eintragen:
options vfio-pci ids=1002:7340,1002:ab38
4.2.3 Kernelmodule automatisch beim Start laden
Damit die entsprechenden Module beim Start des Host Rechners automatisch geladen werden, müssen diese in die Datei /etc/modules eingetragen werden. Dazu diese Datei mit root Rechten in einem Editor öffnen, und folgende Zeilen hinzufügen (diese können einfach am Ende der Datei hinzugefügt werden:
vfio vfio_iommu_type1 vfio_pci vfio_virqfd
4.2.4 AMD Reset Fehler
Viele AMD Grafikkarten haben den sogenannten “AMD Reset Bug”. Ein Fehler, der dazu führt, dass man eine VM nur einmal starten kann. Startet man die VM erneut und führt nur einen Neustart innerhalb der VM durch, lässt sich die Grafikkarte nicht mehr ansprechen. Dieser Fehler liegt an der Grafikkarte. Es gibt aber eine Abhilfe, in Form des kleinen Kernelmodul “Vendor-Reset”, welches auf https://github.com/gnif/vendor-reset zu finden ist.
Dieses Modul kann einfach von Github heruntergeladen werden und mit Hilfe des Befehls dkms installiert werden (dkms wird bei den meisten Linux Distributionen über die Paketverwaltung installiert, sowie der Befehl git:
$ git clone https://github.com/gnif/vendor-reset.git $ cd vendor-reset/ $ sudo dkms install . $ cp udev/99-vendor-reset.rules /etc/udev/rules.d/
Anschließend muss dieses Kernel Modul ebenfalls in die Datei /etc/modules eingetragen werden. Dieses sollte möglichst früh geladen werden, daher am besten direkt am Anfang der Datei eintragen:
vendor-reset
4.2.5 MSR ignorieren
Model Specific Registers (MSRs) sind spezielle Register in der x86-Architektur von PCs, die von Herstellern wie Intel und AMD für spezielle Zwecke oder Funktionen verwendet werden. Diese Register sind nicht in den allgemeinen x86-Registern wie den Datensegmentregistern oder den allgemeinen Zweckregistern enthalten, sondern sind für spezifische Aufgaben reserviert.
MSRs können für eine Vielzahl von Aufgaben verwendet werden, darunter Leistungsüberwachung, Energieverwaltung, Debugging, und andere hardwarenahe Funktionen. Sie können von Betriebssystemen, Treibern und Anwendungen verwendet werden, um auf Hardwarefunktionen zuzugreifen, die nicht über herkömmliche Anweisungen oder Schnittstellen zugänglich sind.
Einige Beispiele für die Verwendung von MSRs sind das Ändern von CPU-Taktfrequenzen, das Lesen von Temperatursensordaten, das Aktivieren von speziellen CPU-Funktionen wie Virtualisierungserweiterungen (wie Intel VT-x und AMD-V), und vieles mehr.
Beim Einsatz von QEMU (Quick Emulator) und KVM (Kernel-based Virtual Machine) können bestimmte Probleme im Zusammenhang mit MSR (Model Specific Registers) auftreten, insbesondere wenn es um die Virtualisierung von CPUs geht. Das kann bei Windows 10 in einer virtuellen Maschine zu öfteren Bluescreen-Abstürzen führen.
Daher sollten in die Datei /etc/modprobe.d/kvm.conf folgende Einträge hinzugefügt werden:
options kvm ignore_msrs=1 options kvm report_ignored_msrs=0
4.3 Reboot des Host
Nun sollte der Rechner einmal neu gestartet werden, damit alle Änderungen wirksam werden.
5. Windows VM anpassen
In meinem Beispiel gehe ich davon aus, dass schon eine funktionierende Windows 10 VM unter Qemu/KVM eingerichtet worden ist. Sofern dies noch nicht passiert ist, habe ich in dem Artikel Desktop Virtualisierung mit QEmu und KVM unter Debian eine entsprechende Anleitung hinterlegt, wie dies zum Beispiel unter Debian gemacht werden kann. Wobei bis auf unterschiedliche Paketverwaltungen diese Anleitung auch auf andere Distributionen übertragbar ist.
5.1 Looking Glass Host unter Windows 10 installieren
“Looking Glass” ist eine Technologie, die es ermöglicht, die Grafikausgabe einer virtuellen Maschine (VM), die auf einem Host-System läuft, direkt auf dem Bildschirm des Host-Systems anzuzeigen. Diese Technologie wurde speziell für Gamer entwickelt, die Virtualisierung nutzen möchten, um verschiedene Betriebssysteme und Anwendungen auszuführen, ohne die Leistungseinbußen zu haben, die mit herkömmlichen Methoden wie Remote-Desktop-Verbindungen einhergehen.
QEMU (Quick Emulator) und KVM (Kernel-based Virtual Machine) sind beide Virtualisierungstechnologien, die in Linux-Umgebungen häufig verwendet werden. Looking Glass ist jedoch keine integrierte Funktion von QEMU oder KVM, sondern ein separates Projekt, das von der Community entwickelt wurde, um die Grafikleistung von VMs zu verbessern.
Im Wesentlichen funktioniert Looking Glass, indem es die Grafikausgabe der VM direkt an den Host weiterleitet, wodurch die Notwendigkeit für eine separate Grafikschnittstelle wie VNC (Virtual Network Computing) vermieden wird. Dies ermöglicht eine schnellere und reaktionsschnellere Anzeige der VM-Grafiken auf dem Host-System.
Es ist wichtig zu beachten, dass Looking Glass bestimmte Hardwareanforderungen hat und dass nicht alle Grafikkarten oder Treiber unterstützt werden. Auch die Konfiguration kann etwas komplex sein, da sie die Einrichtung einer passenden Umgebung erfordert, die sowohl auf dem Host- als auch auf dem Gastsystem installiert werden muss.
Die Software kann unter https://looking-glass.io/artifact/stable/host heruntergeladen werden. Die Bezeichnung Host mag hier etwas verwirrend sein, weil doch der Linux Rechner der Host ist. Host bezieht sich hier auf den “Anbieter”. Linux ist der Host für die virtuelle Maschine. Aber Windows 10 ist dann der Host für die Grafikausgabe. Und Linux ist dann der Client für den Empfang dieser Grafik und dessen Darstellung.
Die virtuelle Windows 10 Maschine dazu einfach starten und in einem Browser den Link eingeben und das Tool herunterladen. Anschließend die EXE ausführen und das Tool installieren. Looking Glass installiert als Host einen entsprechenden Dienst. Ansonsten hat unter Windows 10 das Tool selber keine Funktion, also man kann dort nichts weiter mit machen.
5.2 Looking Glass Client unter Linux installieren
Der Client ist bei den meisten Linux Repositories enthalten und kann unter Debian zum Beispiel so installiert werden:
$ sudo apt install looking-glass-client
Der Client ist ein reines Kommandozeilen Tool, es gibt also kein Icon, welches über den Desktop gestartet werden kann. Wenn man sich über
$ looking-glass-client --help
die Hilfe ausgeben lässt, wird man ein wenig mit den Parametern erschlagen.
Mit Hilfe diesen Parametern kann Looking Glass beeinflusst werden. Am besten legt man sich eine Konfigurationsdatei im Homeverzeichnis an:
$ vi ~/.looking-glass-client.ini
Meine Datei sieht wie folgt aus:
[app] shmFile=/dev/shm/looking-glass renderer=auto allowDMA=yes [win] title=looking-glass-client autoResize=yes keepAspect=yes dontUpscale=yes noScreensaver=yes quickSplash=yes borderless=no fullScreen=no uiFont=pango:Iosevka uiSize=16 maximize=no showFPS=no [egl] vsync=yes multisample=yes scale=2 [wayland] warpSupport=yes fractionScale=no [input] escapeKey=70 grabKeyboardOnFocus=yes releaseKeysOnFocusLoss=yes autoCapture=yes rawMouse=yes [spice] enable=yes host=/dev/shm/win10-4game_spice port=5900 clipboard=yes clipboardToVM=yes clipboardToLocal=yes
Diese muss man entsprechend seinen Vorlieben, oder Linux/Windows Umgebung entsprechend anpassen.
Noch funktioniert Looking Glass nicht optimal, da noch einige Konfigurationsparameter in der virtuellen Maschine geändert werden müssen. Aber man kann jetzt schon die Windows 10 VM darüber steuern. Wenn man die entsprechende Konfigurationsdatei angelegt hat, reicht ein einfacher Aufruf über die Kommandozeile aus:
$ looking-glass-client
Es erscheint das Windows Fenster, mit ein paar Hinweis Fenstern (wegen der noch fehlenden Anpassungen), die man einfach weg klicken kann. Mit der Taste <SCRL LOCK> kann man die Tastatur und Maus fangen, also auf den Windows Desktop umschalten. Ferner kann man mit der Taste auch wieder die Tastatur und Maus freigeben, so dass diese wieder für Linux zur Verfügung steht. Drückt man länger diese Taste, öffnet sich ein Menü mit weiteren Funktionen.
5.3 Spice Guest Tools installieren
Als nächstes müssen die Spice Guest Tools installiert werden. Die Spice-Gasttools sind eine Reihe von Softwarekomponenten, die in virtuellen Maschinen (VMs) verwendet werden, um die Integration und Interaktion zwischen dem Host- und Gastsystem zu verbessern, insbesondere wenn die Spice-Protokollsuite für die Virtualisierung verwendet wird. Spice steht für “Simple Protocol for Independent Computing Environments”.
Diese können unter https://www.spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-latest.exe herunter geladen werden. Auch diese wieder in Windows 10 installieren.
Danach wird die virtuelle Maschine, bzw. Windows 10 heruntergefahren.
5.4 Konfiguration der XML Datei
Da die folgenden Änderungen nicht über die grafische Benutzeroberfläche des virt-manager durchgeführt werden können (Diese Funktionen sind dort nicht verfügbar), muß die XML Konfigurationsdatei der entsprechenden VM geändert werden.
Dazu wird der Name der entsprechenden VM benötigt, welchen man sich mit folgenden Befehl anzeigen lassen kann:
$ virsh -c qemu:///system list --all
Man bekommt dann eine Liste aller installierten virtuellen Maschinen angezeigt:
Id Name Status --------------------------------------------- - macOS_Ventura ausgeschaltet - Windows_10 ausgeschaltet
Bei mir heißt die Windows 10 Instanz “Windows_10” (Leer- und Sonderzeichen sind im Namen nicht erlaubt). Diese wird jetzt zum editieren geöffnet:
$ virsh --connect qemu:///system edit Windows_10
Es wird der Standardeditor (in meinem Fall der vi) mit der entsprechenden Konfiguartionsdatei im XML Format geöffnet.
5.4.1 Vendor-ID
Dort wird in dem Block:
<hyperv ...> ... </hyperv>
folgendes zu den schon vorhandenen Einträgen hinzugefügt:
<vendor_id state="on" value="<VENDOR-ID>"/>
Die Vendor-ID ist eine Kennung, die angibt, von welchem Hersteller die CPU stammt, und sie wird normalerweise von Betriebssystemen und Anwendungen verwendet, um festzustellen, welche Funktionen und Optimierungen von der CPU unterstützt werden. Hier kann irgend etwas eingetragen.
5.4.2 Hidden-ID
Und eine Ebene höher unter:
<features> ... </features>
muss noch folgendes hinzugefügt werden:
<kvm> <hidden state='on'/> </kvm> <ioapic driver='kvm'/>
Bei mir sieht der ganze Block am Schluß dann wie folgt aus (Kann bei anderen Installationen etwas abweichen):
<features>
<acpi/>
<apic/>
<hyperv mode="custom">
<relaxed state="on"/>
<vapic state="on"/>
<spinlocks state="on" retries="8191"/>
<vendor_id state="on" value="deadbeaf"/>
</hyperv>
<kvm>
<hidden state="on"/>
</kvm>
<ioapic driver="kvm"/>
<vmport state="off"/>
</features>5.4.3 Maus & Tastatur hinzufügen
Anschließend den folgenden Eintrag suchen:
<input type='mouse' bus='ps2'/>
Und direkt darüber folgendes hinzufügen:
<input type='mouse' bus='virtio'/> <input type='keyboard' bus='virtio'/>
5.4.4 Memballon deaktivieren
Und diesen Eintrag suchen:
<memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </memballoon>
Und durch folgenden ersetzen:
<memballoon model='none'/>
5.4.5 Gemeinsamen Speicher aktivieren
Der nächste Eintrag, der gesucht werden muss:
<currentMemory unit='KiB'>33554432</currentMemory>
Direkt darunter folgendes hinzufügen:
<memoryBacking> <source type='memfd'/> <access mode='shared'/> </memoryBacking>
5.4.6 Shared Memory aktivieren
Danach geht man bis zum Ende Datei, bis zum Eintrag </devices> (sollte direkt unter den gerade eingefügten Block aus Kapitel 5.4.5 sein) und fügt direkt darüber folgenden Block ein:
<shmem name="looking-glass"> <model type="ivshmem-plain"/> <size unit="M">X</size> </shmem>
Dort wo jetzt noch ein X steht, muss der entsprechende Wert für den Bildschirmspeicher eingetragen werden. Dieser kann recht leicht ausgrechnet werden.
Breite * Höhe * Pixel Farbtiefe * 2 = Anzahl Bytes (Für die normale Darstellung ist die Pixel Farbtiefe = 4, für HDR wäre diese 8)
Würde man eine Auflösung von 1920 x 1080 unter Windows einstellen, wäre die Rechnung wie folgt:
1920 * 1080 * 4 * 2 = 16588800
Diese teilt man durch 1024 und wieder 1024, um die Zahl in Megabyte zu erhalten:
16588800 / 1024 / 1024 = 15,8203125
Aufgerundet wären dies also 16 MiB. Dazu müssen noch 10 MiB dazu addiert werden:
16 MiB + 10 MiB = 26 MiB
Diese Zahl muss zur nächsten Zweierpotenz (2-4-8-16-32-64-128-256 etc.) aufgerundet werden. Es ergibt sich hier also einen Wert von 32, welcher an der Stelle von X eingetragen werden muss. Von HDR rate ich persönlich ab. Zum einen funktioniert dies unter dem Linux Host selber bisher eher schlecht bis gar nicht, und es kostest deutlich mehr Rechenleistung und Ressourcen. Wenn dies also nicht unbedingt benötigt wird und der Linux Host entsprechend eingerichtet ist, wird dies nicht benötigt. Wayland oder Xorg können beide stand heute kein HDR. Wer also einen dieser beiden Display Server nutzt, wird kein HDR nutzen können.
Man kann auch problemlos mehr Speicher reservieren, als benötigt. Je höher der Wert, desto länger braucht die VM beim initialisieren, also beim starten.
Jetzt noch die Datei abspeichern und den Editor verlassen.
5.4.7 Rechte für shared Memory anpassen
Die gemeinsam genutzte Speicherdatei, die von der IVSHMEM (Inter-VM Shared Memory) verwendet wird, ist unter dem Pfad /dev/shm/looking-glass zu finden. Diese Datei wird standardmäßig von QEMU erstellt und verwaltet. Normalerweise sind die Zugriffsrechte so konfiguriert, dass nur der QEMU-Prozess darauf zugreifen kann, und Ihrem Benutzer werden keine Lese- oder Schreibberechtigungen gewährt. Allerdings sind diese Berechtigungen notwendig, damit Looking Glass ordnungsgemäß funktioniert. Sie müssen daher die Zugriffsrechte entsprechend ändern, damit Looking Glass korrekt ausgeführt werden kann.
Dafür muss die Datei /etc/tmpfiles.d/10-looking-glass.conf angelegt und folgendes dort eingetragen werden:
# Type Path Mode UID GID Age Argument f /dev/shm/looking-glass 0660 <BENUTZER> kvm -
<BENUTZER> muss durch den Usernamen ersetzt werden, der später die VM startet und aufruft, also im Normalfall der eigene Benutzer.
5.4.8 Komplette XML Datei
Anbei meine Version der XML Datei. Diese bitte nicht 1:1 übernehmen, da Pfade und Dateinamen unterschiedlich sein werden. Aber so kann man leichter vergleichen, ob etwas vergessen wurde, oder fehlt.
Meine XML Konfiguration
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
virsh edit Windows_10
or other application using the libvirt API.
-->
<domain type='kvm'>
<name>Windows_10</name>
<uuid>36a11587-9691-42f6-a82f-b26ca54f67af</uuid>
<metadata>
<libosinfo:libosinfo xmlns:libosinfo="https://libosinfo.org/xmlns/libvirt/domain/1.0">
<libosinfo:os id="https://microsoft.com/win/10"/>
</libosinfo:libosinfo>
</metadata>
<memory unit='KiB'>33554432</memory>
<currentMemory unit='KiB'>33554432</currentMemory>
<memoryBacking>
<source type='memfd'/>
<access mode='shared'/>
</memoryBacking>
<vcpu placement='static'>16</vcpu>
<os firmware='efi'>
<type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
<firmware>
<feature enabled='no' name='enrolled-keys'/>
<feature enabled='no' name='secure-boot'/>
</firmware>
<loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
<nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/Windows_10_VARS.fd</nvram>
<bootmenu enable='no'/>
</os>
<features>
<acpi/>
<apic/>
<hyperv mode='custom'>
<relaxed state='on'/>
<vapic state='on'/>
<spinlocks state='on' retries='8191'/>
<vendor_id state='on' value='deadbeaf'/>
</hyperv>
<kvm>
<hidden state='on'/>
</kvm>
<vmport state='off'/>
</features>
<cpu mode='custom' match='exact' check='none'>
<model fallback='allow'>EPYC-IBPB</model>
<topology sockets='1' dies='1' cores='8' threads='2'/>
</cpu>
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
<timer name='hypervclock' present='yes'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' discard='unmap'/>
<source file='/var/lib/libvirt/images/Windows_10.qcow2'/>
<target dev='vda' bus='virtio'/>
<boot order='1'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/dirk/driver-images/Windows-Driver.iso'/>
<target dev='sdc' bus='sata'/>
<readonly/>
<boot order='2'/>
<address type='drive' controller='0' bus='0' target='0' unit='2'/>
</disk>
<controller type='usb' index='0' model='qemu-xhci' ports='15'>
<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</controller>
<controller type='pci' index='0' model='pcie-root'/>
<controller type='pci' index='1' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='1' port='0x10'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
</controller>
<controller type='pci' index='2' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='2' port='0x11'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
</controller>
<controller type='pci' index='3' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='3' port='0x12'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
</controller>
<controller type='pci' index='4' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='4' port='0x13'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
</controller>
<controller type='pci' index='5' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='5' port='0x14'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
</controller>
<controller type='pci' index='6' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='6' port='0x15'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
</controller>
<controller type='pci' index='7' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='7' port='0x16'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
</controller>
<controller type='pci' index='8' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='8' port='0x17'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/>
</controller>
<controller type='pci' index='9' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='9' port='0x18'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
</controller>
<controller type='pci' index='10' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='10' port='0x19'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
</controller>
<controller type='pci' index='11' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='11' port='0x1a'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
</controller>
<controller type='pci' index='12' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='12' port='0x1b'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/>
</controller>
<controller type='pci' index='13' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='13' port='0x1c'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/>
</controller>
<controller type='pci' index='14' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='14' port='0x1d'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/>
</controller>
<controller type='pci' index='15' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='15' port='0x1e'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x6'/>
</controller>
<controller type='pci' index='16' model='pcie-to-pci-bridge'>
<model name='pcie-pci-bridge'/>
<address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
</controller>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</controller>
<controller type='virtio-serial' index='0'>
<address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
</controller>
<interface type='bridge'>
<mac address='52:54:00:08:a9:37'/>
<source bridge='virbr0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
</interface>
<serial type='pty'>
<target type='isa-serial' port='0'>
<model name='isa-serial'/>
</target>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<channel type='spicevmc'>
<target type='virtio' name='com.redhat.spice.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>
<input type='mouse' bus='virtio'>
<address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
</input>
<input type='keyboard' bus='virtio'>
<address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
</input>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='spice' autoport='yes' listen='0.0.0.0'>
<listen type='address' address='0.0.0.0'/>
<image compression='off'/>
<gl enable='no'/>
</graphics>
<sound model='ich9'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
</sound>
<audio id='1' type='spice'/>
<video>
<model type='none'/>
</video>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x12' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x12' slot='0x00' function='0x1'/>
</source>
<address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/>
</hostdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='2'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='3'/>
</redirdev>
<watchdog model='itco' action='reset'/>
<memballoon model='none'/>
<shmem name='looking-glass'>
<model type='ivshmem-plain'/>
<size unit='M'>256</size>
<address type='pci' domain='0x0000' bus='0x10' slot='0x01' function='0x0'/>
</shmem>
</devices>
</domain>5.5 IOMMU Gruppen anzeigen lassen
In den diversen IOMMU Gruppen sind die Devices zusammengefasst. Wichtig ist es zu beachten, dass immer alle Geräte innerhalb einer IOMMU Gruppe durchgereicht werden. Wenn in einer Gruppe zum Beispiel die Grafikkarte und die auf der Grafikkarte enthaltende Soundkarte in einer Gruppe stehen, müssen zwingend auch beide durchgereicht werden. Ansonsten führt dies unweigerlich zu einem Systemcrash des Linux Host, sobadl die VM gestartet wird.
Daher lässt man sich als erstes die Gruppen ausgeben, mit den dort enthaltenen Devices. Dazu dient folgendes Script, welches man entweder direkt auf der Kommandozeile ausführt oder zuvor in einer Datei schreibt, und dann diese ausführt:
#!/bin/bash
shopt -s nullglob
for g in `find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V`; do
echo "IOMMU Group ${g##*/}:"
for d in $g/devices/*; do
echo -e "\t$(lspci -nns ${d##*/})"
done;
done;Es wird eine, je nach Ausstattung des Rechners mehr oder weniger lange Liste ausgegeben, die ich hier verkürzt zeige:
...
IOMMU Group 32:
0d:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch [1002:1478] (rev c1)
IOMMU Group 33:
0e:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch [1002:1479]
IOMMU Group 34:
0f:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c1)
IOMMU Group 35:
0f:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38]
IOMMU Group 36:
10:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch [1002:1478] (rev c5)
IOMMU Group 37:
11:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch [1002:1479]
IOMMU Group 38:
12:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] [1002:7340] (rev c5)
IOMMU Group 39:
12:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38]
IOMMU Group 40:
13:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a]
IOMMU Group 41:
14:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485]
IOMMU Group 42:
14:00.1 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP [1022:1486]
...In Kapitel “4.2.1 IDs heraus suchen” wurden die entsprechenden PCI-IDs ja schon heraus gesucht. Diese finden sich auch in der Liste wieder:
IOMMU Group 38:
12:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] [1002:7340] (rev c5)
IOMMU Group 39:
12:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38]In diesem Fall belegt die AMD RX-5500 XT Grafikkarte, zusammen mit der integrierten Soundkarte, die Gruppen 38 und 39. Man könnte hier auch nur die Grafikkarte durchreichen, was aber nicht sehr sinnvoll wäre. Es kann aber auch passieren, dass in einer dieser Gruppen noch ein ganz anderes Device auftaucht. Sollte dies der Fall sein, dann kann es helfen, die Grafikkarte in einen anderen PCIe Slot zu stecken. Ansonsten muss auch dieses Device unter allen Umständen durchgereicht werden.
5.6 Grafikkarte an die VM weiterreichen
Als nächstes wird die virtuelle Maschinenverwaltung (virt-manager) aufgerufen. Dort die entsprechende Windows 10 VM ausgewählt und auf “Öffnen” (die VM darf nicht gestartet sein!) klicken.
Dort auf den Reiter “Details” wechseln. Hier kann nun über “Gerät hinzufügen”, die Grafikkarte, bzw. Soundkarte hinzugefügt werden. In der linken Spalte auf “PCI Host-Gerät” klicken und auf der rechten Seite dann in diesem Fall erst das Device “0000:12:00:0 Advanced Micro Devices, Inc. [AMD/ATI] Navi 14 [Radeon RX 5500/5500M / Pro 5500M] [1002:7340] (rev c5)” hinzufügen:
Und das ganze mit einem Klick auf “Fertig” bestätigen.
Dieser Schritt wird nun erneut durchgeführt, nur wird diesmal noch die Soundkarte “0000:12:00:1 Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio [1002:ab38]” hinzugefügt. Anschließend wird auf “Fertig” klicken.
Anschließend sieht man in der Übersicht die beiden hinzugefügten Geräte:
5.7 Grafikkartentreiber installieren
Nun kann die virtuelle Maschine mit Windows 10 gestartet werden. Wenn man kurz nach dem Start sich den Geräte Manager anschaut, wird man ein zusätzliches Gerät mit einem Ausrufezeichen finden:
Kurz nach dem Start deswegen, weil Windows natürlich versucht, einen passenden Treiber über die Windows Update Funktion zu finden und zu installieren. Bei den meisten älteren Grafikkarten wird da auch recht schnell ein Treiber installiert sein, und der Geräte Manager sieht anschließend dann so aus:
Persönlich würde ich empfehlen, die Grafikkartentreiber des Herstellers zu installieren, in diesem Fall die AMD Radeon Treiber.
Bei der Installation kann folgender Fehler auftauchen, den man aber einfach ignorieren, bzw. mit <OK> bestätigen kann:
Wenn der Treiber installiert wurde, die Windows 10 VM wieder herunterfahren.
5.8 Den zweiten virtuellen Bildschirm entfernen
Windows und zwei Bildschirme, sind ein Thema für sich. Hauptproblem ist, dass man Windows schwer beibringen kann, welcher der primäre Monitor ist. Aber letztendlich werden hier ja nur ein Monitor benötigt, und dieser auch nur virtuell. Bei zwei Monitoren kann es passieren, dass der eigentlich primäre, in diesem Fall Looking Glass, zum sekundären degradiert wird, mit der Folge, dass das Bild schwarz bleibt.
Daher sollte die virtuelle Grafikkarte im virt-manager abgeschaltet werden. Dazu in den Einstellungen der virtuellen Maschine unter Video: xxx (Hier steht der Typ, also z.B. QXL) gehen, und den Treiber auf “none” stellen:
Auf <Apply> klicken und das Fenster schließen.
6. Windows 10 starten
Nun kann die virtuelle Maschine mit Windows 10 gestartet werden.
Wenn diese gestartet ist, also der Status auf “Wird ausgeführt” steht, kann in in der Kommandozeile der Looking Glas Client aufgerufen werden:
$ looking-glass-client
et voilà… Eine Windows VM mit einer eigener Grafikarte:
Man braucht auch jetzt nicht mehr die Tastatur und die Maus fangen, sondern das passiert automatisch, wenn man in das Fenster mit der Maus fährt, bzw. klickt. Jetzt kann man auch problemlos grafikintensive Anwendungen, wie zum Beispiel CAD, aber auch Spiele in einer virtuellen Maschine unter Linux benutzen.
7. Fazit
Zusammenfassend lässt sich sagen, dass die Verwendung von Passthrough und VFIO, um eine Windows-VM mit 3D-Grafikunterstützung unter Linux zu betreiben, eine leistungsfähige Lösung bietet, um Windows-Anwendungen und -Spielemit hoher Grafikanforderung in einer virtualisierten Umgebung auszuführen. Hier sind einige wichtige Punkte:
- Leistung und Grafikqualität: Durch die direkte Anbindung einer dedizierten Grafikkarte an die Windows-VM mittels Passthrough und VFIO können Anwender eine nahezu native Grafikleistung erzielen. Dies ist besonders wichtig für Anwendungen wie 3D-Spiele oder CAD-Software, die eine hohe Grafikleistung erfordern.
- Flexibilität: Die Verwendung von Passthrough und VFIO ermöglicht es Benutzern, spezifische Hardwaregeräte, wie Grafikkarten, direkt an virtuelle Maschinen anzubinden. Dadurch können sie die Hardware-Ressourcen effizienter nutzen und spezielle Anforderungen erfüllen.
- Konfiguration und Komplexität: Die Einrichtung von Passthrough und VFIO erfordert eine gewisse technische Kompetenz und kann komplex sein, insbesondere wenn es um das UEFI-BIOS und die Treiberkonfiguration geht. Es ist wichtig, sorgfältig die Dokumentation zu lesen und die Kompatibilität der Hardware zu überprüfen, um mögliche Probleme zu vermeiden.
- Treiberunterstützung: Die Treiberunterstützung für Passthrough und VFIO kann variieren und hängt oft von der spezifischen Hardware ab. Es ist ratsam, zu prüfen, ob die verwendeten Komponenten von gängigen Virtualisierungs- und Grafikkartentreibern unterstützt werden, um eine reibungslose Funktion zu gewährleisten.
- Community und Ressourcen: Es gibt eine aktive Community von Benutzern, die Erfahrungen mit Passthrough und VFIO austauschen und bei Problemen unterstützen können. Online-Foren, Wikis und Anleitungen können hilfreiche Ressourcen sein, um bei der Einrichtung und Fehlersuche zu unterstützen.
Insgesamt bietet die Verwendung von Passthrough und VFIO eine leistungsstarke Möglichkeit, Windows-Anwendungen mit 3D-Grafikunterstützung unter Linux zu betreiben, obwohl es einige technische Herausforderungen gibt, die bewältigt werden müssen. Bei richtiger Konfiguration kann diese Lösung jedoch eine ausgezeichnete Alternative für Benutzer bieten, die eine flexible und leistungsfähige Virtualisierungsumgebung benötigen.
Quellen:
https://wiki.debianforum.de/QEMU/KVM_mit_GPU_Passthrough
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF
https://www.debugpoint.com/kvm-share-folder-windows-guest
https://github.com/gnif/vendor-reset
https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md
https://de.wikipedia.org/wiki/X86-Virtualisierung#Intel-VT-d
https://looking-glass.io/
https://www.spice-space.org/download.html#windows-binaries
https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Virtiofs:-Shared-file-system
