Be careful with the newest virtio drivers (0.1.285), they seem to have some issues, maybe use older (0.1.271) ones for now.
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!
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.
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:
This thread may be of interest: https://forum.proxmox.com/threads/h...sage-on-idle-with-windows-server-2025.163564/
and also
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.
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...
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.
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...
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).This thread may be of interest: https://forum.proxmox.com/threads/h...sage-on-idle-with-windows-server-2025.163564/
and also
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.
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...
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
To disable VBS (having understood the ramifications):
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):
- Turn off Tamper Protection (Windows Security: Virus & Threat Protection) if enabled
- Turn off Memory Isolation (Windows Security: Core Isolation) if enabled
- Ensure the REG_DWORD
EnableVirtualizationBasedSecurityhas a value of0x0(located atHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard) - Ensure the Virtual Machine Platform (Windows Feature) is "Turned Off"
- Reboot
- Verify VBS is disabled via
msinfo32 - Turn on Tamper Protection
If memory integrity / HVCI is getting enabled, performance is going to be very bad with the current state-of-the-state. See my KVM Forum presentation on the topic: https://www.youtube.com/watch?v=MooRtyPkxXc
If anyone on the kernel developer side is interested in collaborating on Intel MBEC (and/or AMD GMET), I'm always open to working together.
If anyone on the kernel developer side is interested in collaborating on Intel MBEC (and/or AMD GMET), I'm always open to working together.
@JonKohler
That was a very informative KFM Forum presentation. Thanks for all the RTFM you did on that one, especially the fine print.
Can you comment on where the resolutions are at today? Still making their way into upstream KVM / QEMU I take it...?
That was a very informative KFM Forum presentation. Thanks for all the RTFM you did on that one, especially the fine print.
Can you comment on where the resolutions are at today? Still making their way into upstream KVM / QEMU I take it...?
Thanks for the feedback. I meant what I said in the video RE "1000 and 1 context switches this year". It is at just about the tippy top of my to-do list at this point, and we're actively working on it. The qemu side is easy, the KVM side is more nuanced