Unraid + Windows 10 vm lagging / stotter

[workermaster]

Beste Tweakers,

Na wat goede hulp uit dit draadje:
Unraid + Windows 10 vm installatie hulp gevraagd ben ik nu op een punt dat ik Unraid met wat Dockers en een Windows vm heb draaien. Op zich werkt alles wel en kan ik het nu gebruiken maar ik loop tegen een performance issue aan.

Het probleem

De Windows vm is traag. Slepen met een venster is laggy. Gamen gaat daarintegen wel goed. Ik haal met mijn 660ti nog 60fps in Skyrim op 1440p. Video playback op YouTube gaat ook goed. Het lijkt echt alsof de Windows verkenner een stotter heeft. Je kan het vergelijken met het besturen van een systeem via remote desktop of TeamViewer.

Nu is dat nog wel te doen maar zodra ik media van een externe hdd naar de media share schrijf, valt alles in elkaar. Windows lijkt dan ineens helemaal traag te worden. Klikken op een knop gaat met een vertraging van seconden. Als er een game open staat beweegd de muis wel vloeiend maar in super slowmotion. Het verplaatsen van data naar de media share gaat daarintegen wel op volle snelheid. (Dit gebeurd in mindere mate als ik data van de share naar een externe hdd schrijf)

Wat heb je al gedaan?

CPU pinning:


Windows template:


En de shares:


Windows staat op de unassigned ssd. Boot ik Windows zonder Unraid (schijnbaar kan dat) dan heb ik de normale performance.

Mogelijk relevant: Ik heb 2 660 ti kaarten in het systeem zitten. Unraid pakt de bovenste en windows de onderste. Beide zijn van Asus. Om mijn 660ti van Asus werkend te krijgen in Windows heb ik de vbios file van een MSI variant gebruikt. Het lukt mij niet om Windows de bovenste kaart te laten gebruiken dus ik neem aan dat Unraid echt een eigen gpu moet hebben?
Het is mij nog nooit gelukt om Seabios aan de gang te krijgen.

Ik heb de Diskspeed Docker gebruikt en kan daarmee zien dat alle schijven de maximale snelheid halen. Crystaldiskmark in Windows laat een raar beeld zien. Die geeft namelijk aan dat mijn ssd (die ongeveer 550mb max kan lezen en schrijven) toch wel erg snel is:


Ik heb overigens dezelfde vraag gesteld op het Unraid forum maar daar lijkt weinig te gebeuren. Ook zie ik daar superveel andere topics waar meestal geen reactie op komt. Vandaar dat ik het hier op Tweakers probeer.

[Voor 3% gewijzigd door workermaster op 21-02-2021 13:53]

[Thralas]

Zoiets al geprobeerd? [SOLVED] KVM low 2D graphics performance

Het lukt mij niet om Windows de bovenste kaart te laten gebruiken dus ik neem aan dat Unraid echt een eigen gpu moet hebben?

En je UEFI. Als je geen integrated graphics hebt loop je dan al snel tegen problemen aan.

Dat je disk snel is komt waarschijnlijk doordat je de host page cache wordt gebruikt als buffer.

[workermaster]

Thralas schreef op zondag 21 februari 2021 @ 17:17:
Zoiets al geprobeerd? [SOLVED] KVM low 2D graphics performance


[...]


En je UEFI. Als je geen integrated graphics hebt loop je dan al snel tegen problemen aan.

Dat je disk snel is komt waarschijnlijk doordat je de host page cache wordt gebruikt als buffer.

Zojuist geprobeerd maar helaas geen geluk. De protection staat nu uit maar de performance issues blijven.

[EnricovD]

Ik ben zelf al jaren gebruiker van Unraid (naar volle tevredenheid). Ik zie zo geen rare dingen in je screenshots...

Wat ik alleen niet snap, waarom heb je CPU pinning aangezet bij Docker? Unraid / Docker kan dit prima zelf bepalen...

Ik heb zelf even een test gedaan met mijn eigen Windows VM (geïnstalleerd op een Unassigned Device SSD) en ik heb nergens last van...

Haal de CPU pinning is van Docker af en test dan je VM nog eens...

[workermaster]

EnricovD schreef op maandag 22 februari 2021 @ 12:02:
Ik ben zelf al jaren gebruiker van Unraid (naar volle tevredenheid). Ik zie zo geen rare dingen in je screenshots...

Wat ik alleen niet snap, waarom heb je CPU pinning aangezet bij Docker? Unraid / Docker kan dit prima zelf bepalen...

Ik heb zelf even een test gedaan met mijn eigen Windows VM (geïnstalleerd op een Unassigned Device SSD) en ik heb nergens last van...

Haal de CPU pinning is van Docker af en test dan je VM nog eens...

Zal ik vanavond testen. Momenteel ben ik data aan het kopieren (en aan het werk). Ik had ook op internet gelezen dat schijnbaar je hyperthreading uitzetten nog wel wil helpen. Dat ga ik vanavond ook proberen.

[workermaster]

@EnricovD Zojuist getest. Ik heb de cache drive losgekoppeld dus Docker draait niet. Daarnaast heb ik de cpu pinning van de vm aangepast en hyperthreading uit gezet. Unraid werkt nu dus met 8 echte cores. 2 daarvan zijn voor Unraid en 6 naar de vm.

Helaas blijven de problemen. Er is ook geen kleine verbetering zichtbaar.

[EnricovD]

workermaster schreef op maandag 22 februari 2021 @ 18:08:
@EnricovD Zojuist getest. Ik heb de cache drive losgekoppeld dus Docker draait niet. Daarnaast heb ik de cpu pinning van de vm aangepast en hyperthreading uit gezet. Unraid werkt nu dus met 8 echte cores. 2 daarvan zijn voor Unraid en 6 naar de vm.

Helaas blijven de problemen. Er is ook geen kleine verbetering zichtbaar.

Ok, dat is duidelijk...

Wanneer je, je cache drive weer koppelt en Docker inschakelt (Let op! Zonder CPU pinning voor Docker) is er dan ook geen verbetering? Misschien dat je dan nog wel een beetje met CPU pinning voor de VM moet "spelen"...

Als dit niet werkt kan je natuurlijk ook even de videokaart loskoppelen en de VM even via VNC overnemen om te kijken of dit iets verbetering geeft... Als dit verbetering geeft ligt het misschien toch aan die aanpassing welke je hebt gedaan voor de videokaart...

EDIT 01: Wat ik trouwens wel raar vind... Ik gebruik zelf een Ryzen systeem voor Unraid met maar 1 GPU en deze kan ik delen met Unraid, Plex (transcoding), VM's etc. Dus dat betekent dat Unraid geen eigen GPU nodig heeft... Zou ook raar zijn, Unraid draait immers headless en je neemt deze over via het IP adres en de Webgui...

[Voor 14% gewijzigd door EnricovD op 23-02-2021 21:10. Reden: toevoeging 1]

[Thralas]

Long shot: je zou kunnen kijken of je met LatencyMon iets kunt zien.

Ik vermoed van niet, omdat dit waarschijnlijk een stuk virtueel hardware is dat niet helemaal lekker meewerkt. Dat is voor mij toch ook altijd de ervaring met passthrough geweest.

[workermaster]

EnricovD schreef op dinsdag 23 februari 2021 @ 21:07:
[...]


Ok, dat is duidelijk...

Wanneer je, je cache drive weer koppelt en Docker inschakelt (Let op! Zonder CPU pinning voor Docker) is er dan ook geen verbetering? Misschien dat je dan nog wel een beetje met CPU pinning voor de VM moet "spelen"...

Als dit niet werkt kan je natuurlijk ook even de videokaart loskoppelen en de VM even via VNC overnemen om te kijken of dit iets verbetering geeft... Als dit verbetering geeft ligt het misschien toch aan die aanpassing welke je hebt gedaan voor de videokaart...

EDIT 01: Wat ik trouwens wel raar vind... Ik gebruik zelf een Ryzen systeem voor Unraid met maar 1 GPU en deze kan ik delen met Unraid, Plex (transcoding), VM's etc. Dus dat betekent dat Unraid geen eigen GPU nodig heeft... Zou ook raar zijn, Unraid draait immers headless en je neemt deze over via het IP adres en de Webgui...

Ik heb de cache drive weer aangesloten en de pinning verwijderd. Helaas heeft dat geen impact gehad.
Daarna ben ik wat gaan rondspelen met de CPU isolation. Daarbij zag ik dat een van de cores die gereserveerd is voor de VM alsnog door Unraid wordt gebruikt. Die core heb ik niet meer aan de VM toegewezen en daarna leek het alsof Windows sneller was. Al heb ik daar het zeer sterke vermoeden dat dit een illusie is. Ik ga daar later nog wat meer aan testen.

Mij lukt het niet om de bovenste kaart aan een Windows vm te hangen. Als ik die selecteer in de Windows template en dan de VM start, chrashed de VM. Die lijkt gewoon niet te starten en geeft een zwart beeld. Een van de CPU cores van de VM staat ook altijd op 100% draaien als ik dat doe.

Ik heb ook even getest met de VNC ipv de GPU. Helaas is het daar hetzelfde verhaal. Al was dat nog moeilijk te beoordelen omdat de VNC van zichzelf al laggy is.

Thralas schreef op dinsdag 23 februari 2021 @ 21:58:
Long shot: je zou kunnen kijken of je met LatencyMon iets kunt zien.

Ik vermoed van niet, omdat dit waarschijnlijk een stuk virtueel hardware is dat niet helemaal lekker meewerkt. Dat is voor mij toch ook altijd de ervaring met passthrough geweest.

Klinkt als iets om te proberen. Ik die daar geen app van. Hoe werkt dat?

[Thralas]

Download het eens, zou ik zeggen.

[workermaster]

Thralas schreef op woensdag 24 februari 2021 @ 19:03:
Download het eens, zou ik zeggen.

Danku.

Ik heb het gedraaid maar kan niet veel soeps maken van de uitkomst:

Schijnbaar zijn er dus problemen alleen zie ik niet waar. Windows geeft geen foutmeldingen en apparaatbeheer ook niet.

Ik heb ook het programma "WhySoSlow" gedraaid:


Het valt op dat de "Kernel responsiveness" en "App responsiveness" regelmatig omhoog schieten. Ook hier heb ik geen idee wat dat moet zijn en wat ik eraan kan doen. Ik ga me daar later in verdiepen.

[workermaster]

Toevoeging:

WhySoSlow kan ook een analyse doen en daar een rapport van maken:


Er zijn dus inderdaad dingen langzaam. En ik merkte ook dat mijn systeem tijdens het testen even super langzaam reageerde. Dat is ook te zien in het rapport. Dan heb ik nu natuurlijk de vraag waarom een kernel zo traag is.

[Thralas]

Dat 'valt mee' dan. Ik was bang dat je niets zou zien, maar je ziet juist heel duidelijk dat het niet goed is.

Je kunt het tabblad drivers nog even bekijken om uit te sluiten dat het een enkele driver betreft. Maar er wijst al genoeg op dat alles traag is.

Dat komt dus waarschijnlijk inderdaad doordat je virtuele hardware 'traag' is. Dwz. hij spendeert teveel tijd in qemu zelf (of je systeem in een ander proces). Omdat je het nu meetbaar hebt gehaald kun je ook virtuele hardware verwijderen.

Ik meen dat bepaalde audioconfiguraties ook wel eens vervelend doen met qemu. Alles dat een virtio backend heeft (disk, network) is juist wel weer betrouwbaar. Ik zou eerst de audio adapters verwijderen, als dat niet helpt ook video (maar volgens mij werkt dat juist goed, want passthrough).

Helpt dat nog niet, kijk dan of je een libvirt config (xml, neem aan dat unraid dat onder water gebruikt) of de hele command line van het qemu-proces kan posten.

[geenwindows]

als je unraid boot in GIU Boot dan is het niet mogelijk om deze ook te gebruiken voor je VM. boot je met de 'default' boot instellingen dan zou dit eigenlijk wel mogelijk moeten zijn. zo niet dan zou je kunnen proberen om beide gpu's uit te sluiten voor unraid. dit is mogelijk met de VFIO optie. (zit bij: tools > sytem devices > en dan zowel de VGA als je audio aanvinken en onderaan opslaan en herstarten.
note, unraid en Docker containers kunnen dan geen gebruik meer maken van de GPU's, sowieso NOOIT een GPU voor zowel een VM als een docker container gebruiken! dit resulteert in een crahs wanneer je deze tegelijkertijd aanslingert..

in windows dien je overigens ook alle device drivers te installeren, deze staan allemaal op de virtio iso, deze kun ja allemaal installeren via de apparaatbeheer van windows...

[workermaster]

geenwindows schreef op donderdag 25 februari 2021 @ 09:47:
als je unraid boot in GIU Boot dan is het niet mogelijk om deze ook te gebruiken voor je VM. boot je met de 'default' boot instellingen dan zou dit eigenlijk wel mogelijk moeten zijn. zo niet dan zou je kunnen proberen om beide gpu's uit te sluiten voor unraid. dit is mogelijk met de VFIO optie. (zit bij: tools > sytem devices > en dan zowel de VGA als je audio aanvinken en onderaan opslaan en herstarten.
note, unraid en Docker containers kunnen dan geen gebruik meer maken van de GPU's, sowieso NOOIT een GPU voor zowel een VM als een docker container gebruiken! dit resulteert in een crahs wanneer je deze tegelijkertijd aanslingert..

in windows dien je overigens ook alle device drivers te installeren, deze staan allemaal op de virtio iso, deze kun ja allemaal installeren via de apparaatbeheer van windows...

Ik heb net nog even wat getest en heb nu de bovenset gpu werkend.
Alleen kan ik niet de audio van de gpu aan de vm koppelen. Dan start Windows niet.

@Thralas Goede suggestie. Ik ga daar morgen of zaterdag naar kijken. Mijn systeem is nu een parity check aan het doen.

[demonic]

stop is met isolating cores.

Pin gewoon de cores op je VM en laat het daarbij.

dmv. isolating cores forceer je om unraid te draaien op dezelfde cores als je vm's.

alles gewoon lekker standaard laten en niks mee doen.
En dus alleen je VM pinnen.

[workermaster]

demonic schreef op donderdag 25 februari 2021 @ 17:25:
stop is met isolating cores.

Pin gewoon de cores op je VM en laat het daarbij.

dmv. isolating cores forceer je om unraid te draaien op dezelfde cores als je vm's.

alles gewoon lekker standaard laten en niks mee doen.
En dus alleen je VM pinnen.

Ik dacht dat pinning juist bedoeld was om cores te isoleren zodat ze enkel voor een vm gebruikt kunnen worden.

Anyway ik ga het morgen testen.

[EnricovD]

workermaster schreef op donderdag 25 februari 2021 @ 17:26:
[...]

Ik dacht dat pinning juist bedoeld was om cores te isoleren zodat ze enkel voor een vm gebruikt kunnen worden.

Anyway ik ga het morgen testen.

Nee dit klopt niet helemaal...

Met pinning zet je ze vast, dus voor een bepaalde VM of ander proces. Bij isolation ga je ze afzonderen...

Wat ik dus aan het begin al zei... Doe alleen CPU pinning voor je VM’s en laat de rest met rust...

[workermaster]

EnricovD schreef op donderdag 25 februari 2021 @ 19:29:
[...]


Nee dit klopt niet helemaal...

Met pinning zet je ze vast, dus voor een bepaalde VM of ander proces. Bij isolation ga je ze afzonderen...

Wat ik dus aan het begin al zei... Doe alleen CPU pinning voor je VM’s en laat de rest met rust...

hmm als ik het zo terug lees heb ik het verkeerd getypt. Dus jij stelt voor dat ik ga testen door geen isolation te gebruiken en enkel de vm aan een aantal cores te hangen dmv pinning? Dan zal ik daar morgen naar kijken

[EnricovD]

workermaster schreef op donderdag 25 februari 2021 @ 19:36:
[...]


hmm als ik het zo terug lees heb ik het verkeerd getypt. Dus jij stelt voor dat ik ga testen door geen isolation te gebruiken en enkel de vm aan een aantal cores te hangen dmv pinning? Dan zal ik daar morgen naar kijken

Dat is precies wat ik voorstel... Daarnaast zat ik even terug te lezen, je hebt nu de eerste GPU werkend met de VM? Als dat zo is zou ik ook even de aanpassingen welke je eerder aan de VM hebt gedaan op GPU gebied ongedaan maken...

[workermaster]

EnricovD schreef op donderdag 25 februari 2021 @ 19:47:
[...]


Dat is precies wat ik voorstel... Daarnaast zat ik even terug te lezen, je hebt nu de eerste GPU werkend met de VM? Als dat zo is zou ik ook even de aanpassingen welke je eerder aan de VM hebt gedaan op GPU gebied ongedaan maken...

Bij mijn weet zijn er geen wijzigingen die teruggedraaid moeten worden. Of ik moet nu iets vergeten.

Ik heb namelijk alleen in Windows handmatig een driver aan de kaart gekoppeld. Verder niets.

[workermaster]

@demonic en @EnricovD Ik heb vandaag een aantal testen gedaan met jullie suggesties. Helaas heeft het niet geholpen.

Ik heb getest met het verwijderen van cpu isolation, pinning voor dockers en verschillende cores aan de vm te geven. Daarnaast ook combinaties van wel pinning voor de dockers en niet voor de vm, wel isolation en geen specifieke pinning. Helaas lijkt het allemaal niet uit te maken. Al had ik soms wel het idee dat als ik geen cores isoleer en dan aan de vm toewijs, deze ook door docker gebruikt worden. Dat gaf wel het gevolg dat de performance nog slechter leek. Al was dat maar een klein verschil.

Ik zie ook dat Unraid geisoleerde cores blijft gebruiken. Al is het dan maar een klein beetje. Meesta tussen de 1 en 10%.

@Thralas Zoals verzocht hierbij de xml van de vm:
<?xml version='1.0' encoding='UTF-8'?>
<domain type='kvm' id='1'>
<name>Windows 10</name>
<uuid>a03a505b-a337-7063-b780-baf3f6f1f2b0</uuid>
<metadata>
<vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/>
</metadata>
<memory unit='KiB'>16777216</memory>
<currentMemory unit='KiB'>16777216</currentMemory>
<memoryBacking>
<nosharepages/>
</memoryBacking>
<vcpu placement='static'>8</vcpu>
<cputune>
<vcpupin vcpu='0' cpuset='4'/>
<vcpupin vcpu='1' cpuset='12'/>
<vcpupin vcpu='2' cpuset='5'/>
<vcpupin vcpu='3' cpuset='13'/>
<vcpupin vcpu='4' cpuset='6'/>
<vcpupin vcpu='5' cpuset='14'/>
<vcpupin vcpu='6' cpuset='7'/>
<vcpupin vcpu='7' cpuset='15'/>
</cputune>
<resource>
<partition>/machine</partition>
</resource>
<os>
<type arch='x86_64' machine='pc-i440fx-5.1'>hvm</type>
<loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
<nvram>/etc/libvirt/qemu/nvram/a03a505b-a337-7063-b780-baf3f6f1f2b0_VARS-pure-efi.fd</nvram>
</os>
<features>
<acpi/>
<apic/>
</features>
<cpu mode='host-passthrough' check='none' migratable='on'>
<topology sockets='1' dies='1' cores='4' threads='2'/>
<cache mode='passthrough'/>
<feature policy='require' name='topoext'/>
</cpu>
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/local/sbin/qemu</emulator>
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writeback'/>
<source dev='/dev/sdf' index='3'/>
<backingStore/>
<target dev='hdc' bus='virtio'/>
<boot order='1'/>
<alias name='virtio-disk2'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writeback'/>
<source dev='/dev/sdc' index='2'/>
<backingStore/>
<target dev='hdd' bus='virtio'/>
<alias name='virtio-disk3'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/mnt/user/isos/virtio-win-0.1.190-1.iso' index='1'/>
<backingStore/>
<target dev='hdb' bus='ide'/>
<readonly/>
<alias name='ide0-0-1'/>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>
<controller type='pci' index='0' model='pci-root'>
<alias name='pci.0'/>
</controller>
<controller type='ide' index='0'>
<alias name='ide'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<controller type='virtio-serial' index='0'>
<alias name='virtio-serial0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</controller>
<controller type='usb' index='0' model='qemu-xhci' ports='15'>
<alias name='usb'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</controller>
<interface type='bridge'>
<mac address='52:54:00:f3:17:1b'/>
<source bridge='br0'/>
<target dev='vnet0'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/0'/>
<target type='isa-serial' port='0'>
<model name='isa-serial'/>
</target>
<alias name='serial0'/>
</serial>
<console type='pty' tty='/dev/pts/0'>
<source path='/dev/pts/0'/>
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
<channel type='unix'>
<source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-1-Windows 10/org.qemu.guest_agent.0'/>
<target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
<alias name='channel0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>
<input type='tablet' bus='usb'>
<alias name='input0'/>
<address type='usb' bus='0' port='1'/>
</input>
<input type='mouse' bus='ps2'>
<alias name='input1'/>
</input>
<input type='keyboard' bus='ps2'>
<alias name='input2'/>
</input>
<hostdev mode='subsystem' type='pci' managed='yes'>
<driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x08' slot='0x00' function='0x0'/>
</source>
<alias name='hostdev0'/>
<rom file='/mnt/user/Plex/MSI.GTX660Ti.2048.120828.rom'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x0b' slot='0x00' function='0x4'/>
</source>
<alias name='hostdev1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x0b' slot='0x00' function='0x3'/>
</source>
<alias name='hostdev2'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</hostdev>
<memballoon model='none'/>
</devices>
<seclabel type='dynamic' model='dac' relabel='yes'>
<label>+0:+100</label>
<imagelabel>+0:+100</imagelabel>
</seclabel>
</domain>

Ik heb mijn systeem nu weer draaien met cpu pinning en isolation voor de vm op de laatste 4 cores. Dockers hebben geen pinning.

EDIT: ik heb bij de installatie van Windows alleen VirtIo drivers moeten installeren voor de netwerkadapter (op het moederbord). Windows pakte de rest goed op. Kan het zijn dat er iets in mijn installatie op een Windows driver werkt terwijl het VirtIo moet zijn?

[Thralas]

workermaster schreef op vrijdag 26 februari 2021 @ 13:12:
EDIT: ik heb bij de installatie van Windows alleen VirtIo drivers moeten installeren voor de netwerkadapter (op het moederbord). Windows pakte de rest goed op. Kan het zijn dat er iets in mijn installatie op een Windows driver werkt terwijl het VirtIo moet zijn?

Nee.

De libvirt XML ziet er verder prima uit, behalve dat ik daar niet helemaal uithaal hoe je o.a. audio werkt (ook passthrough?).

Had je nog geprobeerd om virtuele hardware te verwijderen?

[workermaster]

Thralas schreef op zaterdag 27 februari 2021 @ 12:36:
[...]


Nee.

De libvirt XML ziet er verder prima uit, behalve dat ik daar niet helemaal uithaal hoe je o.a. audio werkt (ook passthrough?).

Had je nog geprobeerd om virtuele hardware te verwijderen?

Ik heb vandaag geprobeerd om geen audio door te zetten naar de vm. Helaas leek dat zelfs erger te zijn. Ik heb een Samsung 970 EVO besteld en ga daar (als die morgen binnen komt) opnieuw Windows op zetten.
Misschien dat een nieuwe installatie kan helpen.

[workermaster]

workermaster schreef op zondag 28 februari 2021 @ 21:40:
[...]


Ik heb vandaag geprobeerd om geen audio door te zetten naar de vm. Helaas leek dat zelfs erger te zijn. Ik heb een Samsung 970 EVO besteld en ga daar (als die morgen binnen komt) opnieuw Windows op zetten.
Misschien dat een nieuwe installatie kan helpen.

Oke dan.. Update.

Vanmiddag kreeg ik de 970 EVO binnen. Deze ingebouwd en daarna werkte mijn VM niet meer. Unraid kon ineens de USB controller op het moederbord niet meer doorzetten en een van de videokaarten was de hardware ID kwijt.

Na veel gerommel kreeg ik mijn VM werkend en heb ik de belangrijke bestanden eraf gehaald. Daarna de SSD die ik voor de VM gebruikte als cache ingesteld en een Windows installatie op de nvme gezet. Ook daar bijzonder veel moeite erin moeten stoppen want GPU passthrough werkte niet meer. Uiteindelijk de onderste GPU uit mijn systeem gehaald en na een aantal keer herstarten van de VM kreeg ik een werkende installatie. En het is nog vloeiend ook!

Ik lijk nu dus een werkende Windows VM te hebben die niet stotterd of laggy is. Ik moet nog wel mijn programma's installeren en heb nu nog een kale Windows (met wat drivers en Chrome).

Zodra mijn cache drive weer werkt, want ik ben nu alle data die erop stond aan het herstellen, ga ik proberen om mijn 2e GPU terug in te bouwen.

Ik weet dus niet wat het probleem was. Wel vervelend want zo kan ik niemand helpen die er in de toekomst ook tegenaan loopt.