Windows 11 instabiel als qemu/kvm guest

[jb044]

Mijn vraag

Mijn hoofd OS is AlmaLinux 9.2, voor spelletjes gebruik ik hiernaast een gevirtualiseerde Windows 11 Pro. Maar dan wel met de gpu toegewezen aan Windows.

Mijn vraag is gezien onderstaande:
- zijn er zaken die ik kan doen om de timing van host naar guest te verbeteren?
- kan ik op een eenvoudige manier het qemu/kvm process meer prio geven boven eventuele taken van het main OS. Liefst eenvoudig in de libvirt xml.

Relevante software en hardware die ik gebruik

Asus Prime 670-P MB
AMD Ryzen 9 7950X
Inno3d nVidia 4090
128GB Kingston 4800MR DDR5
Samsung P9A3 3.7TB DC nvme PCIe4 SSD
6x Toshiba 18TB hdd's
1000W BeQuiet Titinium voeding
Asus Bluray writer

AlsmaLinux 9.2
Windows 11 Pro

Wat ik al gevonden of geprobeerd heb

Best wel veel eigenlijk, maar resultaat is altijd hetzelfde: Windows werkt, best goed ook. Alleen loopt het soms vast zonder verdere logging aan de Windows of libvirt kant. Het heeft er de schijn van dat dit vooral gebeurd tijdens idle gebruik, maar heb het ook gezien onder load.

Wat opvalt is dat er met enige regelmaat audio artifacts zijn, alsof ie het even niet bij kan benen. Wel meer dan eens gezien dat dat dan verergerd en een crash tot gevolg heeft.

Zoals ik hierboven al schijf lijkt het een timing probleem icm met onvoorspelbare load op de host, al moet ik zeggen dat idlen zijn core business is .... alleen niet altijd en overal

Natuurlijk heb ik wel onderoek gedaan maar er zijn zoveel settings en deze worden vaak maar sumier toegelicht. Dus wellicht anderen met meer kennis en ervaring en hopelijk oplossingen die ik kan proberen.

Voor de volledigheid mijn libvirt xml:

code:

<domain type="kvm">
  <name>win11pro</name>
  <uuid>5a7056b0-d057-4fb2-99ee-c059438ba481</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://microsoft.com/win/11"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit="KiB">33554432</memory>
  <currentMemory unit="KiB">33554432</currentMemory>
  <memoryBacking>
    <source type="memfd"/>
    <access mode="shared"/>
  </memoryBacking>
  <vcpu placement="static">32</vcpu>
  <iothreads>2</iothreads>
  <cputune>
    <vcpupin vcpu="0" cpuset="4"/>
    <vcpupin vcpu="1" cpuset="5"/>
    <vcpupin vcpu="2" cpuset="6"/>
    <vcpupin vcpu="3" cpuset="7"/>
    <vcpupin vcpu="4" cpuset="8"/>
    <vcpupin vcpu="5" cpuset="9"/>
    <vcpupin vcpu="6" cpuset="10"/>
    <vcpupin vcpu="7" cpuset="11"/>
    <vcpupin vcpu="8" cpuset="12"/>
    <vcpupin vcpu="9" cpuset="13"/>
    <vcpupin vcpu="10" cpuset="14"/>
    <vcpupin vcpu="11" cpuset="15"/>
    <vcpupin vcpu="12" cpuset="16"/>
    <vcpupin vcpu="13" cpuset="17"/>
    <vcpupin vcpu="14" cpuset="18"/>
    <vcpupin vcpu="15" cpuset="19"/>
    <vcpupin vcpu="16" cpuset="20"/>
    <vcpupin vcpu="17" cpuset="21"/>
    <vcpupin vcpu="18" cpuset="22"/>
    <vcpupin vcpu="19" cpuset="23"/>
    <vcpupin vcpu="20" cpuset="24"/>
    <vcpupin vcpu="21" cpuset="25"/>
    <vcpupin vcpu="22" cpuset="26"/>
    <vcpupin vcpu="23" cpuset="27"/>
    <vcpupin vcpu="24" cpuset="28"/>
    <vcpupin vcpu="25" cpuset="29"/>
    <vcpupin vcpu="26" cpuset="30"/>
    <vcpupin vcpu="27" cpuset="31"/>
    <emulatorpin cpuset="0-1"/>
    <iothreadpin iothread="1" cpuset="2-3"/>
    <vcpusched vcpus="0" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="1" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="2" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="3" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="4" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="5" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="6" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="7" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="8" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="9" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="10" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="11" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="12" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="13" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="14" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="15" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="16" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="17" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="18" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="19" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="20" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="21" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="22" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="23" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="24" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="25" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="26" scheduler="fifo" priority="1"/>
    <vcpusched vcpus="27" scheduler="fifo" priority="1"/>
  </cputune>
  <os>
    <type arch="x86_64" machine="pc-q35-rhel9.2.0">hvm</type>
    <loader readonly="yes" secure="yes" type="pflash">/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/win11pro_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv mode="custom">
      <relaxed state="on"/>
      <vapic state="on"/>
      <spinlocks state="on" retries="8191"/>
      <vpindex state="on"/>
      <runtime state="on"/>
      <synic state="on"/>
      <reset state="on"/>
      <vendor_id state="on" value="nv4090"/>
      <frequencies state="on"/>
    </hyperv>
    <kvm>
      <hidden state="on"/>
    </kvm>
    <vmport state="off"/>
    <smm state="on"/>
    <ioapic driver="kvm"/>
  </features>
  <cpu mode="host-passthrough" check="none" migratable="off">
    <topology sockets="1" dies="1" cores="16" threads="2"/>
    <cache mode="passthrough"/>
    <feature policy="require" name="hypervisor"/>
    <feature policy="require" name="cmp_legacy"/>
    <feature policy="require" name="perfctr_core"/>
    <feature policy="require" name="virt-ssbd"/>
    <feature policy="require" name="monitor"/>
    <feature policy="require" name="x2apic"/>
    <feature policy="require" name="topoext"/>
    <feature policy="require" name="invtsc"/>
    <feature policy="disable" name="svm"/>
  </cpu>
  <clock offset="utc">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="yes"/>
    <timer name="kvmclock" present="yes"/>
    <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/libexec/qemu-kvm</emulator>
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2" discard="unmap"/>
      <source file="/var/lib/libvirt/images/win11pro.qcow2"/>
      <target dev="vda" bus="virtio"/>
      <boot order="2"/>
      <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
    </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="0x01" slot="0x00" function="0x0"/>
    </controller>
    <controller type="sata" index="0">
      <address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
    </controller>
    <interface type="network">
      <mac address="52:54:00:17:7b:7d"/>
      <source network="default"/>
      <model type="virtio"/>
      <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
    </interface>
    <input type="mouse" bus="ps2"/>
    <input type="keyboard" bus="ps2"/>
    <tpm model="tpm-tis">
      <backend type="emulator" version="2.0"/>
    </tpm>
    <audio id="1" type="none"/>
    <hostdev mode="subsystem" type="pci" managed="yes">
      <source>
        <address domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
      </source>
      <address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
    </hostdev>
    <hostdev mode="subsystem" type="pci" managed="yes">
      <source>
        <address domain="0x0000" bus="0x01" slot="0x00" function="0x1"/>
      </source>
      <address type="pci" domain="0x0000" bus="0x07" slot="0x00" function="0x0"/>
    </hostdev>
    <hostdev mode="subsystem" type="usb" managed="yes">
      <source>
        <vendor id="0x2357"/>
        <product id="0x0604"/>
      </source>
      <address type="usb" bus="0" port="2"/>
    </hostdev>
    <memballoon model="virtio">
      <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
    </memballoon>
  </devices>
</domain>

[Hero of Time]

Dit klinkt heel erg als gerelateerd aan Windows 11 Pro kvm Guest random lockups, je vorige topic in WOS over je problemen met deze setup.

Issues zoals dit is erg lastig te achterhalen. Logs over libvirt hoeven niet veel te zeggen als het in de kernel van het host OS gebeurt, daar lees je dan omheen/voorbij.

In het verleden was het erg lastig om een nVidia videokaart naar een VM te sturen en te laten werken. Iets in de driver zag dat het virtueel draaide en weigerde fatsoenlijk te 'starten'. Hoe dat tegenwoordig zit, weet ik niet, maar mijn eigen poging op een ouder systeem met een oudere kaart was vorig jaar kansloos te noemen. Het zou mij daarom niet verbazen als er iets in die combinatie zit wat dit veroorzaakt.

Hoe dan ook, in hoeverre is het zinvol voor dit topic tov in je andere topic verder gaan?

[jb044]

Ik heb HyperV virtualisatie in Windows uitgezet, dat heeft geholpen. Ik weet stom: Windows defender had een geel uitroepteken en klik daarop. Bleek dat dat allerlei virtualisatie opties in Windows 11 activeert voor een verbeterde veilighied (boze tongen beweren ten koste van prestatie). Gevolg no boot.

Aangezien het echt om ouderwets 'hangen' gaat, geen blauw scherm of andere foutmeldingen dus, verwacht ik daar niet veel van. En ja grote kans dat de GPU passthrough op zijn minst deel van het probleem is. Belangrijk om te vermelden is dat Linux gewoon stabiel doordraait bij dit alles dus hardware errors durf ik wel uit te sluiten.

edit:

laatste sessie kreeg ik wel allerlei problemen die ik eerder niet had, inclusief blauwe schermen. Normaal reboot ik Linux voor de zekerheid als de gevirtualiseerde Windows problemen heeft. Deze keer was een powerdown nodig. Wat ik echt niet snap is dat Linux tot nu toe gewoon stug blijft doordraaien, het is geen renderbak maar volledig idle is ie ook alleszins

Waar ik naar zoek is de optimale libvirt configuratie waarbij het probleem niet/nauwelijk of in elk geval veel minder optreedt. Het is een lastige om te deguggen. Zo ben ik inmiddels zeker op 30% van Facry6, maar zit ik vast in Doom forever, maar dat ligt aan de moeilijkheidsgraad van die laatste en domheid van mijn kant
Soms heb ik een dag lekkere achtergrond muziek met Kodi, soms maar een paar uur.

Iets zegt me dat als ik Linux zo ver krijg dat ie zonder al teveel kunst en vliegwerk qemu/kvm de hoogst mogelijke prioriteit geeft ik al halverwege ben. In games maar ook het eerder genoemde kodi dat ik gebruik voor mijn muziek collectie is het gewoon hoorbaar dat ie (windows) het soms even niet kan bijbenen, vaak zijn het glitches soms is het in toenemende mate gevolg door de bekende crash.

Dus lang verhaal, maar op dit moment zoek ik het vooral aan de Linux kant, vandaar dit topic. Eerder kreeg ik vooral hardware adviezen, natuurlijk kan dat helpen, maar als het echt hardware was anders dan de nvidia driver, dan zou ik ook problemen verwachten met AlmaLinux. Daar heb ik in 6 maanden non-stop gebruik slechts 1x een niet geplande reboot gehad. Dat ging is fases, zfs gaf een degraded array, systeem werd in toenemende mate unresponsive en uiteindelijk rebootte het. 1x! De zfs array heeft zichzelf overigens zonder blijvende fouten kunnen herstellen, maar dat kosste wel een paar uurtjes.

Ik snap dat dit een edge case is, maar verzuip een beetje in allerlei gemu opties, dus wishlist:
- Fijn zou zijn als Windows mijn cpu cache zag (is nu niet het geval maar was op een zeker moment wel zo)
- Must have is hoge prio op het qemu proces
- Nested virtualisatie gaf bij mij alleen maar problemen met de nvidia kaart dus mag wel uit

Dit alles heeft 0 relatie (of iig heel weinig) met Windows clients lijkt me.

[ Voor 7% gewijzigd door jb044 op 04-08-2023 10:04 ]

[jb044]

Niet alles is ruk zeg maar Wat zeg ik, ooit begonnen met een vmware toen dat nog gratis was .... toen was je al blij als je muis bewoog

[Hero of Time]

Ik heb op m'n werk een W10 en W11 VM die ik zo nu en dan eens start. W10 vaker, want dat is een bedrijfsimage die ik in KVM heb geïnstalleerd, zodat ik een zo goed lijkende omgeving heb zoals onze gebruikers. Daar merk ik gewoon dat het wat minder snappy is en wat vooral idioot is te noemen, is dat de cpu grafiek in virt-manager eigenlijk aangeeft dat het enorm druk is met de cpu. Terwijl in de VM zelf dat eigenlijk nog wel meevalt.

Er is gewoon iets met Windows in KVM dat voor rare dingen zorgt. Dat achterhalen is voor ons als gebruiker praktisch onmogelijk, als het ook echt blijkt te liggen aan wat er in de software er tussen gebeurt. Sommige bugs ga je gewoonweg niet vinden in logs.

[jb044]

Ja dat klopt wel, ik had ook een AlmaLinux vm voor gitlab en zo wat meer Linux vm's met als doel daar wat in te duiken als hobby projectje. Is er een beetje bij gebleven tot nu toe. Maar dat was echt set it and forget it. Tuurlijk het koste geheugen en wat andere resources, maar verder heb ik er nooit veel aandacht aan gegeven of wat van gemerkt, anders dan dat ik er af en op inlogde om de boel bij te werken om mijn security fetish te bevredigen

Eerlijksheidshalve moet ik er wel bij opmerken dat het probleem pas begon nadat ik Windows zijn eigen HDMI aansluiting gaf en er echt mee begon te werken, bij de initiële installatie zonder de nVidia kaart actief had ik geen last van vastlopers. Maar goed behalve Windows een installeren en een beetje optuigen heb ik toen ook niet gedaan.

Wat jij zegt over cpu gebruik herken ik wel, maar dat is niet Windows specifiek. Door de jaren heen heb ik ook wel geleerd dat een VPS met bizarre specs voor bizar weinig met een enorme korrel zout genomen moet worden: virtuele cpu's != echte cpu's. Daarom kon ik het ook niet laten om bovenstaande screenshots te posten, vooral Cinebench vond ik erg indrukwekkend. We komen van ver zeg maar, maar de stelling blijft: er zal altijd overhead zijn en de boel zal altijd minder responsive zijn.

Pff weer een heel verhaal: waar ik tegenaanloop is dat er 100.000 opties zijn voor Qemu/KVM en dat deze vaak sumier of gewoon slecht gedocumenteerd zijn, dat er 1000.0000 code snippets op reddit staan die allemaal claimen alles wat denkbaar is op te lossen. Maar dat ik stiekem hoop op instellingen die mij verder gaan helpen, ik vraag dan ook gericht om tips: met name hoe je qemu meer prio geeft binnen Linux. Kan vast zelf wat prutsen met een scripje om wat cgroup settings te definiëren als ik ik Windows start, maar wellicht kan dat eleganter? Dat met die CPU cache geloof ik wel een beetje. Ik heb echt niet gedroomd dat er op een gegeven moment reële waardes stonden bij L1/2/3 cache. Nu staat er "Virtuele machine"en L1 cache "nvt" .... dat is wat anders dan "niet aanwezig help!" Wat wel heel vervelend is dat ik nu al meerdere malen heb gezien dat een reboot of zelfs een power cycle de zaken veranderd, kennelijk zit KVM zo dicht op de hardware dat dat nodig kan zijn. Als Linux man wordt ik daar wat verdrietig van maar wat jij zegt: je gaat niet alles wat je tegenkomt zelf oplossen.

Om het kort op te sommen: het heeft er alle schijn van dat Windows slecht kan tegen load in de host als het gevirtualiseerd wordt. Wat mij wel bezighoud is dat dat effect juist minder lijkt te spelen als Windows zelf de bron van de load is. Hoop dat dat voor zover mogelijk te minimaliseren is.

[jb044]

Vragen stellen stelt je natuurlijk niet vrij van zelf onderzoek te doen

Hier staat (zoals zo vaak bij archlinux) wel een aardige uitleg:
https://wiki.archlinux.or...a_OVMF#Performance_tuning

Komt erop neer dat als performance belangrijker wordt, zoals als je een snelle GPU op native snelheid gaat gebruiken, ook cpu optimalisatie een rol gaat spelen. Specifiek cpu layout: bij Intel heb je dan virtuele cpu's (als HT aan staat) die L2 cache delen, bij AMD zelfs cluster core paren die een die delen, en dus dedicated L3 cache delen. Schijnt allerlei problemen te geven zoals micro stuttering (en naar mij lijkt nog grotere problemen).

Dussss, iets minder gehinderd door een totaal gebrek aan kennis aan de slag gegaan en eea anders geconfigueerd ... ben heel benieuwd

[jb044]

Hero of Time schreef op vrijdag 4 augustus 2023 @ 20:33:
Daar merk ik gewoon dat het wat minder snappy is en wat vooral idioot is te noemen, is dat de cpu grafiek in virt-manager eigenlijk aangeeft dat het enorm druk is met de cpu. Terwijl in de VM zelf dat eigenlijk nog wel meevalt.

Zie dit nu niet trouwens, de perf monitor van virt-manager geeft vrijwel dezelfde grafiek als task manager van windows. Wel wat ik eerder zei: ben gewend van VPS'en dat de koek daar een stuk sneller op is dan op dezelfde echte hardware. En ja ik ben bekend met de term overboeking, maar zag dat ook toen ik voor het eerst wat speelde met VM's onder Linux en ik redelijk objectief kon bepalen dat de host uit zijn neus stond te vreten. Iets waar je bij $vpsboer alleen maar naar kan gissen natuurlijk.

[spone]

Enige wat ik zo kan bedenken is dat ie het wat lastig krijgt met schedulen als je alle 32 beschikbare threads gaat uitdelen aan de guest. Gaat het beter als je bijvoorbeeld 16 of 24 CPU's toewijst aan je VM?

Laat maar, ik zie dat je er 28 aan de VM toewijst. Dat zou het host os zat ruimte moeten geven.

[ Voor 20% gewijzigd door spone op 05-08-2023 10:11 ]

[jb044]

Wel geprobeerd ja, natuurlijk ten koste van rauwe performance. Daar zou ik mee kunnen leven, voornaamste doel is grafisch intensieve games. Maar probleem bleef.

Het enige mitigerende dat ik tot nu toe had kunnen bepalen dat als de 'hang' problemen eenmaal beginnen ik op zijn minst Linux beter kan rebooten. Anders is het schering en inslag.

Hopen dat betere cpu pinning helpt, fingers crossed

[Hero of Time]

Dat is wel iets waar ik zelf nog aan dacht voor je systeem. Je hebt 16 fysieke cores, elk met 2 'rijstroken' per core. Het is onverstandig om alle 32 'rijstroken' aan de VM toe te kennen. Het is ook niet erg verstandig om alle 16 fysieke cores aan de VM te geven.

Je zegt zelf dat je vooral problemen merkt zodra de host wat load krijgt. In zo'n geval krijg je te maken met thread wait en core wait (niet exacte termen, gaat even om het idee). Een VM dat 2 cores/threads toegewezen heeft, kan werk doen als het tijd krijgt op die twee cores/threads. Geef je een VM 16 threads, dan kan het pas werk doen als alle 16 beschikbaar zijn voor werk. Ook als de workload single threaded is en er dus 15 uit de neus staan te vreten.

De haperingen die je ervaart klinkt namelijk als dat de guest moet wachten op cpu tijd, want de host is met wat bezig en kan op dat moment niet alle threads aan de VM vrijgeven.

Ik raad je aan om maximaal 8 cores, 1 CCD, aan Windows te geven. De CPU is krachtig genoeg hiervoor en wat je er in Windows mee doet, heeft weinig tot geen voordeel aan meer. Ga maar eens kijken naar game benchmarks waar men een 7600X, 7700X en 7950X gebruikt. Tussen de 7700X en 7950X zou je geen winst moeten zien. Je zou zelfs een daling kunnen verwachten omdat de workload opeens op een andere CCD komt en dat is funest voor performance, want het moet de data in de cache uit de andere CCD halen.

[jb044]

De load is tot nu toe slechts een theorie. Wat wel vaak gebeurt is dat Windows blijft hangen juist tijdens idle gebruik. Aan de host kant staan alle cores dan te stampen op 100%. Hoeveel fysieke cores ik toewijst lijkt niet echt uit te maken. Hoewel echt laag ben ik nooit gegaan.

En stampen mag je met een korrel zout nemen, de temperatuur van het systeem blijft namelijk wel laag. Bij zeg een multithreaded kernel compile vliegt ie naar de 90 graden 😀

't Is even afwachten nu wat de cpu pinning volgens bovenstaande guide doet. Ben niet thuis nu, maar ssh lijkt aan te geven dat de boel nog draait.

Oja vannacht flink potje farcry 6 gespeeld, moeilijk sublevel 😁, heel veel stutters en zelf af en even geen respons. Maar vreemd genoeg 0 vastlopers.

[deHakkelaar]

jb044 schreef op donderdag 3 augustus 2023 @ 03:53:
- kan ik op een eenvoudige manier het qemu/kvm process meer prio geven boven eventuele taken van het main OS.

$ man nice
[..]
DESCRIPTION
       Run  COMMAND  with  an  adjusted  niceness,  which affects process
       scheduling.  With no COMMAND, print the current  niceness.   Nice‐
       ness  values  range from -20 (most favorable to the process) to 19
       (least favorable to the process).

$ man renice
[..]
DESCRIPTION
       renice  alters the scheduling priority of one or more running pro‐
       cesses.  The first argument is the priority value to be used.  The
       other  arguments  are  interpreted  as  process  IDs (by default),
       process group IDs, user IDs, or user names.  renice'ing a  process
       group  causes  all  processes  in  the process group to have their
       scheduling priority altered.  renice'ing a user  causes  all  pro‐
       cesses  owned  by  the  user to have their scheduling priority al‐
       tered.

Wikipedia: nice (Unix)

EDIT:

SEE ALSO
       nice(1), chrt(1), getpriority(2), setpriority(2),  credentials(7),
       sched(7)

[ Voor 36% gewijzigd door deHakkelaar op 05-08-2023 20:40 ]

[deHakkelaar]

Voor sshd:

$ chrt -m $(pidof -s sshd)
SCHED_OTHER min/max priority    : 0/0
SCHED_FIFO min/max priority     : 1/99
SCHED_RR min/max priority       : 1/99
SCHED_BATCH min/max priority    : 0/0
SCHED_IDLE min/max priority     : 0/0
SCHED_DEADLINE min/max priority : 0/0

[deHakkelaar]

Ow in deze staat een boel uitgelegd:

$ man sched
[..]
DESCRIPTION
       Since  Linux 2.6.23, the default scheduler is CFS, the "Completely
       Fair Scheduler".  The CFS scheduler replaced  the  earlier  "O(1)"
       scheduler.

   API summary
       Linux  provides the following system calls for controlling the CPU
       scheduling behavior, policy, and priority of processes  (or,  more
       precisely, threads).

       nice(2)
              Set a new nice value for the calling thread, and return the
              new nice value.

       getpriority(2)
              Return the nice value of a thread, a process group, or  the
              set of threads owned by a specified user.
[..]
   Scheduling policies
       The  scheduler is the kernel component that decides which runnable
       thread will be executed by the CPU next.
[..]

[ Voor 12% gewijzigd door deHakkelaar op 05-08-2023 21:14 ]

[deHakkelaar]

Ik heb or ook nog nooit direct mee gespeeld

$ pidof sshd
8174 8168 8135 8125 418

$ sudo renice -n -5 -p 8174
8174 (process ID) old priority 0, new priority -5

$ sudo renice -n 0 -p 8174
8174 (process ID) old priority -5, new priority 0

EDIT: Ow nog eentje:

$ ps -o pid,ni,cmd -C sshd
  PID  NI CMD
  418   0 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
10902   0 sshd: pi
10908   0 sshd: pi
10927   0 sshd: pi
10966  -5 sshd: pi

[ Voor 29% gewijzigd door deHakkelaar op 06-08-2023 01:16 ]

[jb044]

Dank voor het meedenken sowieso

Gisteren toch weer een vastloper. Maar wat hoopvol is dat ik de nodige oudere threads heb gevonden van mensen met eigenlijk exact hetzelfde probleem waarbij virtio als boosdoener werd aangewezen. Virtio is niet alleen een optie van qemu/kvm maar RedHat voorziet ook in signed drivers voor Windows daarvoor. Leek erop dat ik voor dat laatste al de latest&greatest geïnstalleerd had, dus daar verwacht ik weinig van. Het zou zomaar kunnen, 9 van de 10x is er niet of nauwelijks sprake van serieuze load als de crashes zich voordoen en disk io is natuurlijk wel iets dat op een modern OS continue in meer of mindere mate speelt, als dat onder water errors geeft, tja...

Eerst maar eens verdiepen in alternatieven daarvoor dan ..... maar uiteindelijk blijft het hobby er is ook werk en iets dat op een privé leven lijkt

[jb044]

OK I stand corrected in de andere thread werd ik ook al gewezen op hardware problemen. Mijn boerenverstand zei me dat als Linux gewoon zonder errors doordraaid dat moeilijk het geval kan zijn maar dat was nogmaals simpel geredeneerd.

AM5 is gewoon ruk, een ander woord heb ik er niet voor. Niet stabiel en niet af, jammer maar goed dat risico loop je als je voor de latest en greatest gaat. Net een dag bezig geweest om het systeem uberhaupt te laten booten, en ik weet nu hoe ik er omheen moet werken maar snap er nog steeds de helft van anders dan dat AM5 nog niet helemaal af is en er hard aan wordt gewerkt door AMD. Zal vast goed komen of er zal vast ergens in de 100 miljoen miljard opties van mijn UEFI bios een heilige graal zitten voor Windows virtualisatie maar ik geloof het zo langzamerhand wel Anyway door al het gedoe wel in geslaagd om ook mijn bluray drive te virtualiseren. Zit nu een geripte bluray in van coldplay te luisteren in Kodi op Windows 11 om de dag enigzins positief af te sluiten Daadwerkelijk eens een echte bluray aanschaffen en kijken hoe je dat in Windows fatsoenlijk op de oled krijgt is voor een andere dag.

Voor de meelezers: ik denk dat het een combinatie is van al die obscure bios opties van Asus(? of is dat AMD) en de neiging van consumenten hardware om standaard de boel over te klokken ten koste van stabiliteit. Dat in combo met tuned van RedHat/AlmaLinux dat mij in de vorm van het desktop profiel de optie geeft om de boel onder milde load drastisch terug te klokken wat het systeem merkbaar koeler en zuiniger maakt (cores draaien standaard onder de 1Ghz), dat gebruik ik nu dus even niet, Windows vind dat niet zo fijn

[Hero of Time]

Gezien de geschiedenis van Asus met AM5, zou ik het eigenlijk eerder gooien op Asus zelf en niet direct op AM5 als platform.

Uiteraard, het is nieuw. Maar het punt van een platform is dat het altijd op een bepaald moment nieuw is. Als er structurele problemen zijn in het platform zelf, zal die iteratie van het platform altijd issues hebben. AM4 is ondertussen verleden tijd, maar vergeleken met toen het net uit kwam en dat exact zelfde bord en processor nu zal ook issues geven. Er is maar zoveel dat met BIOS updates gefixt kan worden.

Enige wat verbetering zal brengen op het platform is software updates voor het OS. In dit geval dus nieuwere Linux kernels. Toen AM5 net uit was en ik nog eens Phoronix las, zag ik ook veel verbeteringen in de kernel met elke nieuwe release. En nog komen er verbeteringen voor het platform.

[jb044]

Je zult gelijk hebben en het was ook wel een beetje het gevoel van het moment. Een volle dag klooien om door de POST te komen is gewoon echt niet leuk. Maar eerlijk is eerlijk tot nu is het op Windows virtualisatie na dan een volstrekt stabiele build gebleken in het half jaar + dat ik het nu heb.

Ondertussen tussen wat experimenten met cuda/vulcan en podman door, cpu isolation toegepast, de windows guest daarbij 6 cores en 12 threads toegekend en cpu boost en het energie zuinige desktop profiel vervangen door wat anders. Het mooie is dat zodra ik Windows afsluit hij dat alles weer terugdraait naar de standaard waarden.

Van cpu isolation zie ik nog niet heel veel maar het zou goed kunnen dat draaiende processen nog even hun werk mogen afmaken en dat kernelthreads die er bij mij vanwege storage nogal aanwezig zijn gewoon bruut doordraaien. We gaan het zien

[jb044]

OK 3 dingen:

Cpu isolation werkt eigenlijk verassend goed. Ps zette mij even op het verkeerde been, maar als ik bv gtkstresstest aanzet zie ik keurig dat alle gereseveerde cores stil blijven, en dat het systeem ook lang zo heet niet wordt als normaal tijdens nummercrunchen, en dat Windows totaal geen last heeft van de stresstest. Windows 11 is door deze ingreep nu een stuk snappier, geen rare hickups meer ook en kvm start ook consequent factoren sneller op.

MB is echt een probleem aan het worden, de vraag is een beetje komt ie wel of niet door zijn POST als de SATA PCI-e 4x kaart in het systeem zit, waar dit eerder ook een probleem was maar toen opgelost was.

Instabiliteit is gebleven De vraag is zo langzamerhand een beetje of het niet gewoon een hw probleem is. Lees wel meer mensen die een 4090 en AM5 en Windows 11 hebben, maar dan gewoon native en ook last hebben van random lockups. Misschien toch maar eens overwegen om het MB te vervangen, uiteindelijk was dat 1 van de goedkoopste componenten in deze build.

[Hero of Time]

Eigenlijk bizar om te zeggen dat het moederbord het goedkoopste was, want AM5 planken zijn best aan de prijs. Of eigenlijk, moederborden in het algemeen. Mijn eerste PC, een socket 939 met een AMD Athlon 3500+, had een moederbord dat top of the line was en €250 kostte. Tegenwoordig is dat nog niet eens het midden segment te noemen.

Het moederbord wat ik nu heb voor m'n 7700X is net geen €300. En dat was niet eens het meest uitgebreide bord (het is een ASRock X670E Pro RS). Best bizar eigenlijk.

Ik hoop voor je dat een ander AM5 moederbord de POST problemen oplost. Heb je zo veel schijven in je systeem dat je die extra controller nodig hebt?

[jb044]

Ik weet uit mijn hoofd niet meer wat ik voor de Asus betaald heb eigenlijk, meen iets van 300 en het is slechts een X670 (Asus zet er dan nog een P achter maar het is gewoon de iets simpeler versie van wat jij hebt ). Klopt wat je zegt, vroegar betaalde je pas veel als je iets exotisch wou. 2 CPU slots en SCSI erbij ofzo, nu is hety kennelijk de norm. CPU's andersom in mijn beleving. De 7950X die ik nu heb is in mijn beleving een beest, maar de prijs viel me eigenlijk best mee. Over de nVidia kaart doe ik geen uitspraken, ik heb m betaald en gekregen en daarmee basta

Qua storage ja: 6x Toshiba 18TB en een 4TB nvme PCIe 4x kaartje. En om te beginnen had ik nog oude disks die overgezet moesten worden naar dit systeem. Dus toen was die jMicron kaart reuze handig. Nu gebruik ik m alleen nog voor een bluray drive met de intentie daar iets met 1 blurays onder windows te gaan doen eventueel en onder Linux long term storage via dat nieuwe bluray formaat.

Dat bleek ook de oorzaak, als ik die bluray drive loskoppel kom ik ook mijn bios weer in. Weet alleen zeker dat dit eerder niet zo was. Het begon toen ik een beta bios van Asus met de nieuwe AMD firmware voor betere DDR5 support, wou upgraden naar de stable variant van hetzelfde. "Load optiomal values" save en bam geen POST meer. Uiteindelijk de nieuwe bios handmatig via de herstelprocedure van Asus kunnen laden en heel veel uren later pas naar die PCIe kaart gekeken die toch echt een half jaar + probleem gedraaid heeft en ook een paar bios updates overleefd heeft.

Wellicht komt het nog goed, maar vetrouwen is een beetje weg door dit verhaal en natuurlijk de rare Windows problemen. Ik bedoel kan gamen tot ik er echt genoeg van heb, maar het boeltje idle laten draaien is geen optie, dan crashed ie om de haverklap

[jb044]

Wat ik me nog bedacht: ik gebruik nu USB passthrough ivm het gemak daarvan. Dat zit denk ik iets verder weg van de fysieke hardware dan daadwerkelijk een USB device inclusief alle aangesloten USB apparatuur daarop doorlussen. Wat zijn de meningen daarover?

[jb044]

Was ik weer

Ok USB passthrough vervangen door USB controller passthrough. Dat was best nog wel een ondernemening: mijn AM5 bordje heeft geloof ik 5 USB controllers, waarvan 3 in een eigen IOMMU group. DUs dat leuk easy peasy. Mooi niet dus, de laatste 3 heb ik niet kunnen betrappen op het aansturen van welke poort dan ook. Maar device 65 deelde een IMMO group met een PCIe PCI hub, EN bleek de frontpanel USB3 poorten aan te sturen. Uiteindelijk 3/4 craches van de host verder gekomen tot dit:
- USB device en PCI hub respecteievelijk voorzien van vfio-pci en pci-stub
- Udev wou voorvolgens niet oppkomen, dit bleek te zitten in de depricated service systemd-udev-settle. Dus die gemasked.
- Het fijne gevoel dat je weer een stap hebt genomen in een soepelere Windows ervaring, en als bonus plug&play usb poorten hebt. Las dat er nogal wat overhead zit in USB passthrough en dat met name audio gestotter, wat ik ook duidelijk had, ermee speelt.

Dat was het dus ook niet. Mijn Windows is inmiddels aardit snappy en responsive maar de vastlopers na een paar uur idle time of soms korter bleven.

Uiteindelijk kwam ik via een omweg op veel threads over AMD epyc/ryzen power management en dan met name de lagere C-States. Voor zover ik het begrijp is vooral de neiging om de halve chiplets en de interconnect in een low power mode te zetten toch wel vaak funest: leidt tot vastlopers. Hey dat kwam me bekend voor!

Mijn Bios biedt daarvoor 3 settings "Global C1 States"of woorden van die strekking, die heb ik op Off gezet, dooronder hangt iets met D-C states dat standaard afhangt van de waarde van de eerste. En last but not least is er een Power setting, met een typicval en een low value en natuurlijk Asus kennende: Automatic. Ik ben gegaan voor typical.

Wonder boven wonder typ ik dit op een Windows 11 die de hele nacht heeft staan idlen en nog als een zonnetje draait Zo het dan toch? ....

PS zo langzamerhand best veel kennis en ervaring opgedaan op dit gebied, zou er behoefte zijn aan een dedicated draaitje hierover? Kan me voorstellen dat er meer interesse in is anders dan de unraid en proxmox forums afstruinen naar antwoorden.

[Hero of Time]

Ik denk dat je hier al voldoende informatie hebt staan. Zie niet echt een voordeel in om het in een apart topic te plaatsen, tenzij meer mensen komen die hetzelfde willen bereiken en tegen issues aan lopen.