ProxMox als Gaming Unterbau - Frage wegen besserer GPU-Isolation

Christyria

New Member
Apr 22, 2023
8
0
1
Grüß euch,

ich selber bin kein Neuling mehr in Sachen ProxMox und nutze diese tolle Virtualisierung schon sehr viele Jahre (wenn ich mich nicht irre schon ab dem Jahr 2010+) als meine persönliche Virtualisierungslösung an meinem 19" Server. Und Linux/Debian nutze ich seit den 2000er Anfängen.

Als Server nutzte ich einen sehr effizienten und stromsparenden AsRock Rack Pentium Dual Core ECC und 16 GB DDR4 ECC und 5x 4 TB RAIDZ2 Brutto-Speicher von denen ich nur grob unter einem TB nutzte.

Wegen den stark angestiegenen Energiepreise (Bitte keine Diskussionen darüber - Eingefleischte wissen wohl sehr genau warum weshalb und wieso) habe ich mich entschlossen meinen Ryzen 5 Gaming-Rechner als All-In-One ProxMox Server & Gaming-Maschine umzubauen - Mit Erfolg :)

Da ich den tollen AMD X570 Chipset habe schreit dieses System förmlich nach IOMMU und Virtualisierung. Und noch dazu ist dieser Gaming-Rechner auch noch Solarelektrifiziert und Energieeffizient, da ich im Stromspar-Gaming mit meiner Radeon RX480/580 8GB mit -50% Power Limit und -40% CPU Clock inklusive 4x 2TB Hitachi SATA sowie 2x NVMe sowie 1x SSD und 2x 2,5" HDDs 1TB im Gehäuse hab ~ 285 Watt im Gaming Modus fahre und entsprechend ~ 100 Watt weniger im Desktop-Surf-Modus.

Meine ProxMox-Config sieht so aus dass ich 2x 1TB WD Reds im ZFS Mirror als rpool-Boot fahre.

Falls wer den Gaming-Unterbau (PlaýStatión) nachbauen möchte:


IOMMU sowie die Virtualisierung muss zwingend im BIOS aktiviert werden. PCIe AER wäre auch noch cool aber kein Muss.

Damit eine PCIe-Grafikkarte in einer VM bereitgestellt werden kann muss der Host hier zwingend zwei GPUs besitzen ansonsten
funktioniert die VM-Virtualisierung nicht mit nur einer GPU. Im Idealfall hat das System eine Onboard-GPU (Prozessorintern etc) oder
eine GPU eines anderen Herstellers die auch als Boot-GPU im Bios gesetzt ist. Die zweite GPU - in meinem Fall meine Radeon darf nicht
als Haupt-GPU im System gestartet sein - ansonsten auch hier keine VM-Virtualisierung.

Hier ist es wichtig dass man zwei unterschiedliche Hersteller der GPUs im System hat und nicht zwei gleiche - z.B. zwei Radeon Grafikkarten.
Da die Radeon-Linux-Treiber im Debian/Proxmox deaktiviert werden ist das halt dann etwas doof weil man hier nicht mit zwei gleichen Herstellern
auftrennen kann.

Wer Legacy Boot benutzt muss unter /etc/default/grub folgende Zeile abändern:


# If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 GRUB_TIMEOUT=2 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt" GRUB_CMDLINE_LINUX=""
Hier amd_iommu=on und iommu=pt hinzufügen.

Wer den UEFI Boot benutzt muss unter /etc/kernel/cmdline folgende Zeile abändern:

root=ZFS=rpool/ROOT/pve-1 boot=zfs amd_iommu=on iommu=pt
Hier amd_iommu=on und iommu=pt hinzufügen.

(Damit man sich nicht wundert warum im Legacy/UEFI-Modus man zwar die PCI-IDs in der VM sehen und auswählen kann aber ProxMox meckert dass kein IOMMU aktiviert ist ...)

Wer ein Intel System mit VT-d (IOMMU Pendant) und Vanderpool (Virtualisierungsmodus) besitzt muss entsprechend anstatt amd_iommu=on intel_iommu=on umschreiben.
Man kann auch in beiden Dateien die Addons eintragen ohne dass was in Rauch aufgeht :D

Als finaler Schritt müssen die Eintragungen dem Kernel / InitRAMFS mitgeteilt werden sowie der Host neu gestartet werden:

update-grub proxmox-boot-tool refresh reboot
Ist IOMMU - was zwingend für den PCIe-Virtualisiermodus benötigt wird - aktiviert ?:

dmesg | grep -e DMAR -e IOMMU
Wer hier folgende Konsolen-Meldung sieht darf sich freuen. Alle anderen die nichts von enabled sehen oder gar nix bekommen brauchen nicht weiter zu machen:

[ 0.396517] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported [ 0.403545] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 [ 0.403759] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 counters/bank).
Unter dem Dateinamen /etc/modules müssen folgende Module geladen werden:

# /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. vfio vfio_iommu_type1 vfio_pci vfio_virqfd
Unter /etc/modprobe.d/ müssen folgende Dateien erstellt werden:

Hier muss zwingend die Secondard GPU - in meinem Fall meine Radeon-GPU die ich virtualisiert nutzen möchte vom System ausgeklammert werden.
(Wer eine nVidia-Karte hat muss entsprechend das nVidia-Modul blacklisten)

Meine Config für eine Radeon-Grafikkarte:

blacklist.conf:

blacklist amdgpu blacklist radeon
vfio.conf:

options vfio-pci ids=1002:67df,1002:aaf0 disable_vga=1
Um die PCIe-IDs herauszufinden - um diese dann in der Config korrekt einzutragen - müssen folgende Befehle eingegeben werden:

find /sys/kernel/iommu_groups/ -type l
Wer hier folgende Konsolen-Meldung sieht darf sich freuen. Alle anderen die nichts von enabled sehen oder gar nix bekommen brauchen - wie immer - nicht weiter zu machen:

/sys/kernel/iommu_groups/17/devices/0000:06:00.0 /sys/kernel/iommu_groups/17/devices/0000:02:08.0 /sys/kernel/iommu_groups/17/devices/0000:06:00.3 /sys/kernel/iommu_groups/17/devices/0000:06:00.1 /sys/kernel/iommu_groups/7/devices/0000:00:07.0
Jetzt kommt der lustige Teil indem man die Hardware-IDs der Grafikkarte finden und in die vfio.conf oben ersetzen muss:

lspci -n -v
In meinen Fall ist meine Secondary GPU interessant:

a:00.0 0300: 1002:67df (rev c7) (prog-if 00 [VGA controller]) Subsystem: 1682:9480 Flags: bus master, fast devsel, latency 0, IRQ 134, IOMMU group 24 Memory at c0000000 (64-bit, prefetchable) [size=256M] Memory at d0000000 (64-bit, prefetchable) [size=2M] I/O ports at f000 [size=256] Memory at fbd00000 (32-bit, non-prefetchable) [size=256K]
Hier spring euch die PCIe-ID 1002:67df in die Augen. Gut! Also oben eintragen.

Wer noch den Audio-Output der GPU nutzt muss entsprechend die PCIe-ID der GPU-Audioausgabe eintragen:


0a:00.1 0403: 1002:aaf0 Subsystem: 1682:aaf0 Flags: bus master, fast devsel, latency 0, IRQ 132, IOMMU group 24 Memory at fbd60000 (64-bit, non-prefetchable) [size=16K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3
Hier spring euch die PCIe-ID 1002:aaf0 in die Augen. Gut! Also oben dazuschreiben.

Herzlichen Glückwunsch! Nun könnt ihr eine VM erstellen, die GPU unter Proxmox hinzufügen und das System starten! Wenn alles reibungslos ist solltet ihr an der Secondary GPU am Ausgang ein Bild bekommen.

Natürlich kann man auch andere PCI(e)-Gerätschaften wie Netzwerkcontroller oder Speichercontroller etc so hinzufügen wobei man theoretisch nichts in der vfio.conf eintragen muss, das sollte für Nicht-Grafikkarten out of the box funktionieren.

Viel Spaß :D
 
Und nun zu meinem eigentlichen Feintuning-Problem / harter Absturz-Problem:

Ich muss zugeben dass die Gaming-Virtualisierung fast perfekt läuft. Es kommen keine Abstürze/Stalls innerhalb der Windows-VM zustande - nur Micro-Ruckler, besonders wenn der Server noch andere Tasks wie VM-Backups fährt, was ja normal ist.

Das System läuft im Gaming-Modus fast perfekt, nur gelegentliche Sound-Glitches / Mikro-Ruckler im Spiel muss man im Kauf nehmen. Eventuell kann man hier mittels KVM-Additive in der .conf noch bessere Abhilfe gegen die Sound-Glitches / Mikro-Rukler schaffen indem man wo die Priorität der VM hochschraubt o.ä.

Was aber nervig ist und ziemlich reproduzierbar ist ist folgende Konstellation bei mir die zum vollständigen Stall mit Komplettabsturz ohne ACPI Soft Power Off führt:

Man fährt den Rechner hoch und dieser startet mir automatisch meine Gaming-VM indem sich zwei virtuelle Festplatten befinden:

1x Windows 11 sowie 1x Manjaro Linux im Dual-Boot. Als CPU nutze ich EPYC wegen den Instruktionen.

Zusätzlich werden andere VMs wie eine Hardware-Firewall, ein File-Server der die 4x2 TB Platten ansteuert, ein DHCP/DNS Server als Debian Server etc.

Alles harmoniert soweit und läuft auch ohne harten Absturz oder dergleichen. Übrigens scheibe ich hier in einem Manjaro ArchLinux System. Sobald ich hier Windows 11 per ACPI-Call neu starte sodass der ProxMox-UEFI gestartet wird wo ich meine Manjaro-Festplatte bzw dessen Boot-Menü auswähle startet mir Manjaro hier auch einwandfrei BIS die Radeon-Grafikkarte initialisiert wird - sprich der Radeon-Treiber amdgpu gestartet wird.

Sofort fangen alle Lüfter des Rechners sehr hoch zu drehen, die Tastatur reagiert nicht mehr und auch der ACPI Knopf zum sauberen Herunterfahren ist ausser Funktion. Der Rechner ist komplett und zu 100% eingefroren.

Was ganz wichtig ist: Es läuft meistens einwandfrei, man kann hin und herbooten und das mit dem Komplettabsturz ist dann nur sporadisch.
Man kann jetzt nicht sagen starte dies und starte das, es startet und bootet...


Doof wenn hier andere Dienste wie ein FileServer, eine Firewall etc laufen die dann nach einem Reset sich neu sortieren müssen / Virtuelle Festplatten auf Beschädigungen geprüft werden müssen etc.

Startet man z.B. Manjaro direkt ohne die Windows HDD zu starten läuft Manjaro zu 85% einwandfrei hoch. Nur gerade heute hatte sich die GPU wohl wieder aufgehangen mit dem selben Lüfter-Hochdrehen und Komplettabsturz-Problem.

Interessanterweise lief Windows 11 ohne Absturz bis jetzt und ich habe hier so eine Idee:

Ich denke dass der Manjaro Linux amdgpu Treiber wohl so tief die GPU initialisiert dass sich vielleicht der proxmox-vfio dermaßen gestört fühlt und das komplette System einfriert.

Meine Frage dazu:

Gibt es eine Möglichkeit die GPU jedesmal wenn die VM gestartet/rebootet wird dass der KVM sich irgendwie neu resettet bzw die GPU sagt hey starte doch mal bitte intern neu. Eventuell ist die GPU mit dem Windows-Grafiktreiber dermaßen eingefahren dass nach einem Soft-Reboot der VM dann bei der Initialisierung der GPU in Manjaro mittels amdgpu wohl dann den ganzen Rechner zum Komplettabsturz bringt wo nur ein Resetknopf hilft.

Es ist ja sporadisch, meistens gibt es ja keine Probleme nur wenn es auftritt ist es halt nervig.

Kann man die VM configtechnisch noch weiter mit Argumenten soweit feintunen dass man die Sound-Lags / Microruckler besser in den Griff bekommt?

Meine VMs haben in der GamingVM virtio komplett (Netzwerk/Virtuelle Festplatten) sowie WriteBack als Cache. Alle übrigen Server VMs haben WriteTrough.

Sollte ich vielleicht zwei VMs erstellen indem eine VM Windows startet und in der zweiten VM Manjaro ohne Dual Boot ?

Danke.
 
Last edited:
Hey @Falk R.

Das ist doch schon mal sehr vielversprechend. Dies werde ich in der VM in der Bootzeile hinzufügen und dann mal schauen.
Unter ProxMox muss es ja nicht getätigt werden da ja die amdgpu/radeon sowieso geblacklistet ist.

Was ich noch sagen kann - erfolgreich:

Hatte ja das Problem wenn ich die VM ja mittels Betriebssystem reboote um dann in den ProxMox UEFI Loader zu kommen um hier Manjaro Arch zu starten kommt es ja vereinzelnt zu kompletten Stalls die das gesamte Hostsystem inklusiver aller VMs mitreißt wo ja nur ein reset mit evtl. Datenverlust/Recovery hilft.

Wenn ich aber den kompletten Server reboote um in der VM ein anderes Betriebssystem - Hier Manjaro Arch zu starten scheint es mir so dass es wohl so stabil ist und nicht das komplette System abstürzt - ohne Bootkonfig amdgpu Änderung.

Gruß
 
Hi, ich habe da eigentlich keine Ahnung von,
Da sind wir schon zu zweit :)

Die amdgpu.Bootänderung entfaltet tatsächlich ihre Wirkung - zwar nicht zufriedenstellend - aber der Proxmox Host friert nicht mehr komplett ein.

Bedeutet:

Winblows starten benutzen und neustarten. Die VM rebootet, Bootauswahl auf Manjaro und siehe da die Lüfter drehen nicht mehr hoch und der Rechner lebt noch, aber es startet der Desktop von Manjaro/Arch nicht. Strg+Alt+Entf lässt die VM neustarten aber Manjaro startet nicht. Starte ich den gesamten Proxmox-Host neu und boote dann Manjaro startet es :D

Scheint also tatsächlich irgendwas mit dem Linux Kernel / amdgpu-Treiber zu sein. Werde ich aber weiterhin noch beobachten wie es sich weiter verhält. Wenn der ganze Proxmox-Host zumindest nicht mehr komplett einfriert ist das schon mal gut.

Kann also wirklich sein dass der amdgpu-Linux-Treiber zu tief in die GPU initialisiert und wohl den PCIe-Bus kurzschließt (So ähnlich) und wohl dadurch das komplette System inklusive Proxmox-Kernel abgeschossen wird ...
 
So, neueste Erkenntnis:

Wage es ja nicht von Windows über einen VM-Reboot (Nicht den Host) auf Linux zu booten, sobald der Desktop erscheinen müsste startet der ganze ProxMox Host neu (Bleibt nicht mehr hängen). Und wenn der ProxMos Host unkontrolliert neu startet reißt es natürlich alle VMs mit :)

So wie es aussieht ist es viel stabiler wenn man das Betriebssystem in der VM wechseln möchte wenn davor der Windows GPU Treiber geladen war erst der ganze Proxmox-Host sauber neugestartet wird mittels Reboot.

So fährt auch Linux in der VM hoch...

Wie gesagt es beißt sich heftig wenn erst Windows benutzt wird und in der VM Linux gestartet werden soll - mittels VM Reboot.

Vielleicht gibt es ein KVM Argument dass die GPU resettet bevor der UEFI Screen kommt.
 
Warum machst du überhaupt dualboot bei ner VM?
Mach doch ne zweite VM mit Linux und eventuell klappt das ja dann, musst nur drauf achten, dass die erste sauber beendet ist vor dem Einschalten der zweiten. ;)
Guggst du:

Hab ja der einen VM meine HID-Devices zugewiesen und behandle die VM somit so als wäre es eine echte Maschine ohne Virtualisierung. Deswegen der Dual Boot.

So erspare ich mir über die ProxMox IP / SSH manuell die andere VM zu starten.

Ich könnte aber tatsächlich eine getrennte VM erstellen und die Linux-VM-Platte dorthin verschieben und am Windows mittels SSH-Script folgendes bauen:

ssh root@haumichblau.local qm shutdown XXX && sleep 10 && qm start XXX

Wäre einen Test wert :)
 
So,

neueste Erkenntnis:

VM-HDD der Manjaro ArchLinux auf eine neue VM verschoben und diese gestartet (Mit allen Änderungen wie USB-HIDs und Grafikkarte durchreichen (Windows-VM ist abgeschaltet). Selber Fehler, Harter Absturz.

Als Behelf muss ich, wenn ich Linux starten möchte den ganzen Proxmox-Server rebooten, dann klappt es auch mit der Bildausgabe in Manjaro.

Man darf also definitiv nach einem sehr stabilen Windows-Gaming nicht mal ebene die VM im Dual-Boot auf Manjaro Linux rebooten oder eine neue VM mit Manjaro starten, sofortiger harter Absturz des Proxmox-Hosts. Komplett-Reboot und Auswahl klappt soweit.

Starte ich direkt Manjaro ohne Windows läuft es auch sofort ohne Komplettabsturz. Nur der Wechsel von Windows auf Linux in der VM crashed.

Übrigens meine VM-Config (Nutze DualBoot mittels UEFI Bootauswahl):

sata0: none,media=cdrom scsihw: virtio-scsi-single smbios1: uuid=babe8ef3-8304-4ac4-9fca-74376e8b75d7 sockets: 1 startup: order=4 tpmstate0: NVMe-Storage:vm-100-disk-1,size=4M,version=v2.0 usb0: host=152d:0579 usb1: host=1e7d:2e22 usb2: host=05ac:0250 usb3: host=0c45:5004 usb4: host=0416:c345 usb5: host=13fd:0840 usb6: host=058f:6387 usb7: host=0644:0000 usb8: host=0644:0000 virtio0: NVMe-Storage-2:vm-100-disk-0,cache=writeback,discard=on,iothread=1,size=128G virtio1: NVMe-Storage:vm-100-disk-3,backup=0,cache=writeback,discard=on,iothread=1,size=512G virtio2: NVMe-Storage:vm-100-disk-2,cache=writeback,discard=on,iothread=1,size=128G vmgenid: 20fa5faa-7b48-4d25-b65f-b64c5b0acc49
Evtl. gibt es ein VM-QEMU Argument damit beim herunterfahren die Grafikkarte resettet wird o.ä.
 
Last edited:
Ich fürchte da wird es nix geben, da scheinen sich die Treiber von Windows und Linux nicht zu vertragen. Ein Reset der Graka müsste der PVE machen, aber für den ist die ja maskiert.
Eventuell kann man den PCI Bus resetten, habe ich aber auch noch nie gemacht.
 
Ich denke ich habe da eine neue Möglichkeit zum Testen und zu spielen:

PCI(e)-Bus Hotplugging:
echo 1 >/sys/bus/pci/<pci-id-of-device>/remove echo 1 >/sys/bus/pci/rescan
Oder ohne Rescan (falls ReScan zu gefährlich für den Host):
echo 0 >/sys/bus/pci/<pci-id-of-device>/remove
Spielewiese :)

Falls das funktioniert und Hotplugging wird ja per QEMU unterstützt könnte man daraus ein schönes Reboot-Script bauen, ...

Werde später berichten.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!