Win10 VM Best Practices - Sluggish Desktop GUI Experience

[bigbangus]

Is there a latest guide to Windows 10 VM best practices?

 

I currently have a Win10VM that exhibits some sluggish behavior. It's not very specific but it's noticeable enough to bother me. I'm questioning all my settings. Things that are slow include:

-browsing through files in windows explorer (all local)

-clicking across tabs in Chrome

-scrolling though a PDF in Chrome

-general desktop GUI sluggishness

 

However global metric on CPU/GPU don't seem horrible from within the VM:

• Win10 CPU utilization at rest: 2-3%
• Win10 Cinebench CPU Score: 7732 (Ryzen 9 3900X - 6C/12T)
• Win10 Time Spy GPU Score: 11864 (RTX 2080 Ti)

 

In general, the VM seemed to be a lot more responsive in 6.9.2 FWIW, but now in 6.10-rc4 it definitely seems worse.

 

See attached Win10.xml, Win10 log and diagnostics.

 

Any help is appreciated.

 

 

 

 

 

 

Win10.xml Win10log.txt unraidnas-diagnostics-20220330-1124.zip

[bigbangus]

Also FWIW here is my CDM test run on the Win10 VM:

[JonathanM]

Try reducing the resource allocation to the bare minimum and slowly add resources until performance quits improving, then back off a step.

 

For example, set CPU to a single thread, and RAM to 4GB. See how it acts. Increase to 2 threads (single core). Repeat.

 

Most people starve the host for resources, and the host is emulating the motherboard, so it's like putting a bunch of RAM and CPU on a super slow motherboard. The more resources you can leave for the host, the better your I/O throughput should be.

[bigbangus]

20 hours ago, JonathanM said:

Try reducing the resource allocation to the bare minimum and slowly add resources until performance quits improving, then back off a step.

 

For example, set CPU to a single thread, and RAM to 4GB. See how it acts. Increase to 2 threads (single core). Repeat.

 

Most people starve the host for resources, and the host is emulating the motherboard, so it's like putting a bunch of RAM and CPU on a super slow motherboard. The more resources you can leave for the host, the better your I/O throughput should be.

 

I tried this with no success. The performance seems consistently bad from 1 CPU 4GB ram through several steps towards 12 thread / 16GB as was my original VM.

 

However your comment did strike a chord, because I ran "WhySoSlow" and the report said: "The highest measured SM BIOS interrupt or other stall was 213 microseconds. This is considered poor behavior. Your system may have difficulty handling multimedia in real-time and may be subject to unexpected stutters and unresponsive behavior"

[ghost82]

38 minutes ago, bigbangus said:

"The highest measured SM BIOS interrupt or other stall was 213 microseconds. This is considered poor behavior. Your system may have difficulty handling multimedia in real-time and may be subject to unexpected stutters and unresponsive behavior"

Check with any latency monitoring software.

Use msi utility, to switch from irq to msi if you have irq conflicts:

https://forums.unraid.net/topic/76035-help-struggling-with-nvidia-audio-passthrough/?do=findComment&comment=1076592

 

Edited March 31, 2022 by ghost82

[bigbangus]

I just created a new Win 10 VM from scratch with the same xml template settings as my original and all the issues seem to have gone away!

 

Updated metrics:

• Win10 Cinebench CPU Score: 8538 (was 7732)
• Crystal Disk Mark 2-3x better in most metrics.

 

Maybe I'll discover what hurt my performance as I step through making my VM current to my needs or maybe the lesson learned is to just make new VMs as new versions of Unraid are released with new libvert and qemu versions.

 

Man I feel like I got out of a Lada and into a Ferrari. It's night and day different.

[ghost82]

6 minutes ago, bigbangus said:

I just created a new Win 10 VM from scratch with the same xml template settings as my original and all the issues seem to have gone away!

maybe you changed the machine type version?

Same xml settings but new qemu versions with different machine versions could change the irq of the devices.

[bigbangus]

9 minutes ago, ghost82 said:

maybe you changed the machine type version?

Same xml settings but new qemu versions with different machine versions could change the irq of the devices.

 

Same machine type and versions, but different <nvram> if that means anything.

[ghost82]

Then I don't know  but happy it's solved now.

Sometimes I got weird issues with the ovmf vars file which I was never able to track down and only replacing it with a new one fixed the issues, but never had performance issues related to the vars file.

By replacing the vars file you basically resetted the cmos.

That file stores nvram variables, it's sometimes recommended to reset it as a general fix, especially on macintosh, who knows what happened...take your solution as a black box and be happy 

 

Edited March 31, 2022 by ghost82

[bigbangus]

3 hours ago, ghost82 said:

That file stores nvram variables, it's sometimes recommended to reset it as a general fix, especially on macintosh, who knows what happened...take your solution as a black box and be happy 

 

 

Well I've bombed out the old VM now, but are you saying I could have deleted the old nvram file and let it rebuild it as a potential fix in the future?

[ghost82]

2 minutes ago, bigbangus said:

but are you saying I could have deleted the old nvram file and let it rebuild it as a potential fix in the future?

One of the things to try when you have issues with a vm is create a new vm with the same settings, pointing at the old vdisk(s); this basically restores the ovmf vars file with a clean one; so yes, restoring vars file with a fresh one is a thing to try.

 

BTW: there's lada and lada...

 

[bigbangus]

10 hours ago, ghost82 said:

One of the things to try when you have issues with a vm is create a new vm with the same settings, pointing at the old vdisk(s); this basically restores the ovmf vars file with a clean one; so yes, restoring vars file with a fresh one is a thing to try.

 

BTW: there's lada and lada...

 

 

Haha yes love this! Not quite a sleeper, but carries the badge well. :)

 

Good to know. I'll try this fix next time I have VM issues. Thank you for the insight.