[SOLVED] Win Server 2k25 - QEMU Disk ultra slow

beisser said:
depending on your actual processor you should set it to x86-64-v3 or x86-64-v4.
it exposes more processorflags/features to the OS.

im usually running them with v3, as my processors dont support AVX512.

the xeon gold 5118 supports AVX-512, so you could go with v4.
dont forget to set the +aes flag.
Click to expand...
Thank you for the additional information. I am running it with v4 now and it doubled the rates again. Now I have finally reached the hardware limits and learned on the way. Thank You!
 
  • Like
Reactions: _gabriel and beisser
Just for the context: with @benyamin, we're in a hunt for virtio 0.1.285+ and/or WS2025-related bugs. We're collecting any relevant inputs, to be eventually able to report new issues on the virtio-win github. And for this, we need as exact data as possible.

To this case - this is anything but normal that the CPU settings/change is a "solver". This is either quite serious KVM/QEMU bug, or a virtio bug.

Please, if anyone is competent to contribute, share your findings (and as deep as possible). Thank you.

You can't simply accept that such workarounds are the "solution".
You must always continue to search for the root cause.

And please, always report your virtio version.
 
Last edited:
RoCE-geek said:
WS2025-related bugs
Click to expand...
This thread may be of interest: https://forum.proxmox.com/threads/h...sage-on-idle-with-windows-server-2025.163564/

and also
D

Thread 'CPU type `host` is significantly SLOWER than `x86-64-v2-AES`'

I am shocked to discover what seems absolutely counter-intuitive to me, but maybe someone can explain me?

I have a stock Win11 24H2 and I initially set it up with x86-64-v2-AES and it was zipping along as one would expect.

1734300836343.png

Then I realized there is a 'host' CPU type and since I have a 128 GB 72 Core Dual Xeon (Lenovo Thinkstation P710) Proxmox server, I figured I'd just allocate directly as "native" HAS to be better/faster than emulated (anything) right? Wrong.

What I didn't expect is that the VM is barely usable!? The CPUs ALL peg at 100% and eventually...
  • Like
 
  • Like
Reactions: RoCE-geek
SteveITS said:
This thread may be of interest: https://forum.proxmox.com/threads/h...sage-on-idle-with-windows-server-2025.163564/

and also
D

Thread 'CPU type `host` is significantly SLOWER than `x86-64-v2-AES`'

I am shocked to discover what seems absolutely counter-intuitive to me, but maybe someone can explain me?

I have a stock Win11 24H2 and I initially set it up with x86-64-v2-AES and it was zipping along as one would expect.

1734300836343.png

Then I realized there is a 'host' CPU type and since I have a 128 GB 72 Core Dual Xeon (Lenovo Thinkstation P710) Proxmox server, I figured I'd just allocate directly as "native" HAS to be better/faster than emulated (anything) right? Wrong.

What I didn't expect is that the VM is barely usable!? The CPUs ALL peg at 100% and eventually...
  • Like
Click to expand...
OK, it seems the major voice is that when running with native (aka "host") CPU settings, Windows VM is unaware it's running as a VM, and then it fire up nested virtualization / VBS (Virtualization-based Security).

And this, with some added (and active) guest-side security mitigations, is presented as the main problem/cause here.

Last but not least, it seems that this bad behavior is bound just to the Intel CPUs (?)

And there're at least two symptoms:
- higher, but not topped idle CPU load (seems not resolved by the CPU type changes for Win11/WS2025)
- completely saturated CPUs since the VM start (seems to be fixed by the CPU change)

For the first case, there're reports like this: Just encountered the same issue after upgrading a Win 10 Pro VM to Win 11 Pro. VBS off and followed all advices from this thread. Still having idle percentage 2 to 3 times higher than before the upgrade. Inside the VM, there is virtually no CPU usage, except I am seeing more time spent with interrupts that it used to.

Another mentioned problem is the different HPET behavior on newer Windows version.

But at the moment, I cannot see a clear path to virtio as a root cause.
 
Last edited:
Yeah, I think this is likely a nested virtualisation / VBS based problem.

Running with a host CPU, you can check if VBS is enabled via msinfo32. It's at the bottom of the System Summary.

To disable VBS (having understood the ramifications):

  1. Turn off Tamper Protection (Windows Security: Virus & Threat Protection) if enabled
  2. Turn off Memory Isolation (Windows Security: Core Isolation) if enabled
  3. Ensure the REG_DWORD EnableVirtualizationBasedSecurity has a value of 0x0 (located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard)
  4. Ensure the Virtual Machine Platform (Windows Feature) is "Turned Off"
  5. Reboot
  6. Verify VBS is disabled via msinfo32
  7. Turn on Tamper Protection
 
You must log in or register to reply here.
Top Bottom