Hi,
ich hab mir seit Svens Notiz schon vorgenommen, hier mal rein zu schauen und auch von meiner Erfahrung zu berichten. Ich wollte so ein Thread selber mal starten, da meine Erwähnungen hier im Forum von meiner Gaming-VM doch immer ein gewisses Interesse hervorgerufen haben. Ich habe nun seit knapp einem Jahr ein virtualisiertes Windows auf einem Ryzen 1700X, X370 Taichi, passive RX460 (Gast) und Vega 64 unter Arch Linux. Alles in einem WaKü Custom Loop. Ende des Jahres wird dann hoffentlich auf Zen3 und einer neuen Grafikkarte aufgerüstet.
Die VM läuft wunderbar. Die Spiele-Performance ist auf einem Level mit einem nativen Windows. Bei schlechtem oder gar kein CPU Pinning waren die Frametimes je nach Spiel, jedoch nicht so gut. Doch mit ein bisschen probieren, lesen und testen hab ich auch das in den Griff bekommen. Achja, und beim starten der VM werden die Kerne exklusiv an die VM übergeben. Dies lässt sich z.B. mit cset (Infos z.B.
hier oder
hier) realisieren. Macht man das nicht, nutzt Linux weiterhin alle Kerne, was zu größeren Latenzen in der VM führen kann, insbesondere wenn der Host nicht nur idelt. Und das tut der Host bei mir nie, daher auch kein Dual-Boot.
Zur Bildausgabe habe ich Looking Glass getestet, war mit der Performance bei 1440p@144Hz aber nicht begeistert. Außerdem funktioniert Freesync so nicht. Daher wechsel ich jetzt einfach den Eingang am Monitor, wenn ich die VM starte. Maus und Tastatur reiche ich via USB-Passthrough durch und share sie dann über
Barrier mit meinem Host. Ich könnte das USB-Passthrough auch weg lassen und via Barrier Maus und Tastatur einfach an die VM sharen, doch handelt man sich damit ein wenig Latenz ein. Für Office kein Problem, bei Spielen evt schon.
Für Audio hab ich einfach einen USB-Controller meines Mainboards via PCI-Passthrough an die VM übergeben. An einem der Ports hängt eine USB-Soundkarte/Kopfhörerverstärker. Da ich das Windows nur für Spiele nutze, und dabei immer entweder meine Kopfhörer verwende oder wenn ich am TV spiele Sound über HDMI bekomme, habe ich mich mit Audio-Passthrough gar nicht mehr beschäftigt.
In der Zukunft will ich noch probieren, meine Gast-Grafik auch im Host für grafiklastige Anwendungen zu benutzen. Via GPU offloading ist das theoretisch möglich. Mal schauen, ob mir dann der AMD Resetbug dabei einen Strich durch die Rechnung macht.
Das war ein kleiner Einblick in meine Konfiguration und Erfahrung. Falls wer Fragen oder Anregungen hat, raus damit. Ich gehe gerne weiter ins Detail. Auch an Diskussionen über verschiedene Lösungen bin ich interessiert, sofern
@Arjab nichts dagengen hat.
__________
Zum Reset Bug: Ist das noch immer ein Problem? Ich dachte eigentlich, das würde in Verbindung mit libvirt nur noch bei harten Shutdowns Probleme machen, also z.B. wenn die VM abstürzt. Ich kann meine VM munter neustarten, herunterfahren und wieder starten. Oder nutzt ihr die Gast-Grafikkarte auch unter Linux? Ich habe recht häufig gelesen, dass das Probleme machen kann. Das habe ich damit umgangen, dass mein Kernel für die Grafikkarte nur den vfio-pci-Treiber laden darf.
@Mapman Welchen Treiber lädst du für die Gast-GPU unter Linux? Lässt sich mit "lspci -vv" herausfinden. Was ist der genaue Fehler, wenn du die VM versuchst zu booten? Startet die VM? Zeigt libvirt cpu usage an? Falls das Bild einfach schwarz ist, die CPU allerdings genutzt wird (schwakende Auslastung in libvirt): Das Problem hatte ich auch, wenn der AMD-Treiber noch nicht installiert war. Das Bild war schwarz, Windows allerdings gebootet. Nach etwa 10-15 Minuten kam das Bild dann aber. Ich vermute, das WIndows hat im Hintergrund einen Treiber installiert. Dann hab ich den AMD-Treiber installiert und von da an hatte ich nie wieder Probleme.
Übrigens, wenn deine beiden Grafikkarten in den ersten zwei Slots deines Mainboards sind, ist es von der Performance eigentlich egal, welche Grafikkarte wo steckt. Beide Grafikkarten sollten dann mit 8 PCIe-Lanes laufen. Somit kann die Host-GPU auch in Slot 1. Ich selber wollte das nicht, daher ist bei mir in Slot 1 die Vega und die Host-GPU in Slot 4. Somit läuft die Vega mit vollen 16 Lanes und die Host-GPU lediglich über den Chipsatz mit 4 PCIe-v2-Lanes, wenn ich mich richtig erinnere. Für die kleine GPU aber völlig in Ordnung.
