Windows 11 Pro kvm Guest random lockups

[jb044]

Mijn vraag

Sinds kort heb ik een setup onder AlmaLinux 9.2 met via Qemu-kvm een Windows 11 Pro guest. Deze heeft een dedicated nVidia 4090 GPU. IN het begin werkte alles prima, de nodige software in alle rust kunnen instaleren, grafisch en cpu intensieve benchmarks kunnen draaien en ook wat spelletjes gespeeld, zij het niet heel lang. Maar nu valt op dat de virtuele WIndows soms vastloopt. Symptonen zijn altijd bijna geheel gelijk op 1 ding na: de VM is meestal idle als het gebeurd dus kan ik niet zien wat er dan gebeurd (is). Maar wel iig 1x mee gemaakt dat ik rustig zat te browser, volgens mij zelf op tweakers.net maar dat terzijde en patst muis vast. Geen BSOD, niks. Op de host is de load altijd 100% op alle 32 vCores en de cpu heeft het duidelijk ook zwaar als is Linux gewoon responsive.

Wel wat gevonden op het proxmox forum, niet geheel toevallig nb op AMD cpu's. Lees daar vooral veel over Hyper-V. Heb dat gecheched en bij mij heb ik dat 1 niet expliciet uitgezet, en staat het ook uit. Wel heb ik de drivers van RedHat voor virtuele Windows guests geinstalleerd. Alma levert deze niet mee dus deze heb ik van RockyLinux 'geleend'. Reden hiervoor virtio op de NIC en HDD.

Relevante software en hardware die ik gebruik

AMD 7950X Ryzen 9 CPU
128GB 4800MT DDR% Kingston geheugen @4000 MT
Inno 3D nVidia 4090
6x 18TB Toshiba HDD's
1x Samsung PM9A3 3.6TB m2 PCIe 4x4 SSD
1000W Bequeit Titatium voeding
Asus Blu-ray brander
2x logitech remote hw: 1x keybord/trackpad combo, 1x toetsenbord muis.

Host: AlmaLinux 9.2 met de nodige podman containers, reguliere services en GNOME 40 desktop, deze gebruikt de AMD iGPU als grafische backend en de trackpad keybord voor input,
Guest: Windows 11 Pro met 32GB geheugen, 8TB qcow2 image, de nVidia GPU in passthrough mode, de logitch muis/toetsenbord combo in passthrough mode.

Wat ik al gevonden of geprobeerd heb

Zoals gezegd het proxmox forum en de check of Hyper-V aanstond.

Mijn vraag is vooral of anderen dit bekend voorkomt specifiek met Ryzen of eventueel Epic of Threadripper hardware. En natuurlijk of zij het hebben kunnen oplossen en wat ze dan gedaan hebben?

Voor alle duidelijkheid het is nniett zo dat het systeem onbruikbaar is het probleem lijkt zich juist NIET onder load voor te doen, maar ook niet alleen in een idle toestand.

[jb044]

Niemand? Ik snap dat dit niet de meest voor de hand liggende setup is maar kreeg de indruk dat steeds meer mensen kiezen voor een dergelijke manier om Windows + GPU te draaien. Al dan niet in de vorm van yesterday's profi hw + dikke nVidia kaart in de kelder en dan streamer naar de stille desktop of whatever inde woonkamer.

Wat ik intussen al geprobeerd heb:
- <ioapic>kvm</ioapic> (schijnt het beyter te doen op AMD hw)
- powermanagement in Windows waar mogelijk uitzetten
- hyper-v via bcdedit uitschakelen

Symptomen zijn steeds gelijk:
- windows staat te idlen, ik browse wat of de windows instantie wordt een poosje niet gebruikt.
- cpu op de host gaat naar 100%
- windows reaheert helemaal niet meer, geen BSOD maar gewoon simpelweg totaal geen response meer

[zetje01]

Deze eeuw kan je over algemeen zeggen: als windows vastloopt komt het door hardware.
Wijs eens een simpele grafische kaart toe.

[Dennism]

Het kan geheugen zijn, 4000MT/s is met 4 dimms immers nog altijd een overclock, gooi dat eens op 3600MT/s en auto timings (als je timers getuned hebt). Ik zou, in ieder geval om te testen, de cpu ook stock draaien mocht je dan niet hebben (dus zaken als PBO e.d. uit).

Hoeveel vCPU's wijs je toe aan Windows (zorg bijv. dat de host genoeg 'eigen' resources heeft), bij VM's wil je ook over het algemeen niet teveel vCPU's toewijzen (zeker niet meer dan nodig voor het draaien van je workload. Liever beginnen met weinig vCPU's en dan opbouwen wanneer echt nodig.
Verder zou ik inderdaad beginnen te troubleshooten met minimale hardware in de windows machine (dus geen pass through GPU e.d.) en dan langzaam maar zeker opbouwen tot je het issue vind.

[jb044]

Ja dat geheugen is wel een ding, zeg maar rustig baalmomentje: 64 was net te weinig voor hetgeen ik wil doen met deze pc maar ik had niet van te voren gedacht dat 128 zo ongeveer altijd problematisch zou zijn voor AMD. Zal eens proberen, het weer allemaal @stock te zetten. Op een gegeven moment is iets gewoon snel en is er alleen nog sneller Geen zware overclock btw wel wat performance vinkjes is het Asus bios dat wel.

Moet er wel bij zeggen dat de host gewoon doordraait tijdens de Windows lockups, maar qemu geeft helaas weinig clue over het hoe en waarom ervan.

[jb044]

Dank, gereboot en alles zoveel mogelijk op default gezet ... boeltje staat nu al sinds vanochtend vroeg te semi-idlen en ik heb nog geen vastlopers gezien. Dat was eerst wel anders!

Wat ik me nog wel bedacht: eerder koos ik steeds eerst tuned profiel "kvm-host" ipv "desktop". Desktop komt er vooral op neer dat ie de cpu's zover mogelijk terugklokt als ze idle zijn, precies wat ik fijn vind voor dit uiteindelijk toch vooral hobby systeem waar ik zelf de stroomrekening voor betaal Hij staat nu toevallig nog wel op "Desktop". Al zou je daar juist eerder dit soort problemen van verwachten lijkt me, maar dacht meld het toch.

[jb044]

Toch nog een vraag: cpu-scaling wat is daarin wijsheid? Want je raadt het al: toch weer een vastloper

Ik kan me voorstellen dat als de host continue loopt te switchen met cpu frequenties en de guest daar weinig van mee krijgt je problemen kunt krijgen qua stabiliteit of op zijn minst stotteringen in de guest. Hoe doen anderen dit? Kan daar niet veel over vinden nl.

Helemaal uit is misschien ook niet verstandig, want er is ook zoiets als bescherming van de cpu middels trothling onder hoge(re) belasting. Of zie ik nu apen en beren?

Kortom cpu-freq-scaling aan of helemaal uit en gewoon continue @stock draaien?

[jb044]

Ok het heeft even geduurd maar volgens mij heb ik m nu stabiel:
- scaling zet ik uit het tuned profile "None"
- boost zet ik ook uit met

code:

echo 0 > /sys/devices/system/cpu/cpufreq/boost

- deze setting heb ik toegevoegd:

code:

<feature policy="require" name="hypervisor"/>

Online las ik namelijk dat de laatste, maar dan omgekeerd nodig is voor nested virtualisatie, iets waar bij mij icm een passthrough nvidia kaart juist de problemen een stuk erger werden. Van niet willen booten tot de eerder gemelde random lockups.

Boeltje draait nu praktisch 24 uur hartstikke stabiel, ook nauwelijks hoorbare artifacts tijdens het luisteren van muziek met Kodi vanaf een nfs share.

Mocht ie weer gaan bokken dan meld ik me wel weer Tot die tijd hoop ik iemand anders te kunnen helpen met dit verhaal. Ik weet er zijn geen bosladingen met soortgelijke setups, maar ik ben vast niet de enige

[jb044]

En toch weer een update: het valt me op dat het geluid van Windows met grote regelmaat even vastloopt om het zo maar te omschrijven. Ik gebruik mijn nvidia kaart in passthrough mode via hdmi en dus ook het geluid via de nvidia kaart en toen las ik een paar dagen terug dit:

Anoniem: 1849202 in 'GeForce Game Ready Driver 536.67 WHQL'

Wellicht is dit gewoon het probleem en het hele kvm virtualisatie verhaal alleen een dwaalspoor
Meer mensen met recente nvidia kaarten last van (semi) vastlopers waarbij het geluid in elk geval een aantal seconden blijft hangen/ernstig vertraagd?

Wat ik inmiddels wel geleerd heb is dat Linux welliswaar geen last lijkt te hebben van vastlopende virtuele Windows instanties maar dat een reboot daarna wel helpt, als het eenmaal raak is is het schering en inslag. Op die manier weinig last meer gehad van vastlopers in Windows maar helaas ook niet helemaal niet De theorie dat het komt door mijn hardware anders dan de nvidia kaart heb ik inmiddels een beetje losgelaten. Noem het eigenwijsheid, maar als het geheugen of cpu instellingen zouden zijn die mijn systeem instabiel maakt zou ik ook met Linux problemen verwachten. Dat is niet het geval, sterker nog die reboot ik alleen als het zo uitkomt, bij flinke updates aan de software bijvoorbeeld wat tegenwoordig de aangeraden methode is.