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

D

DAE51D

New Member
Oct 9, 2024
10
1
3
Seattle, WA
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 settle down into the 50% range.

1734301535212.png

But you might be saying, "Well you started with one CPU type and changed it so..." And I'd say, "Fair point".

So then I created a fresh VM of Win 11 24H2 (from ISO) with "host" to start from the jump.
Same thing. UNBEARABLY slow.
I then toggled this new one to the x86-64-v2-AES and immediate speed improvement.

The only thing that maybe makes some sense to me would be that I have installed all those qemu "virt" drivers and maybe there's some magic/optimizations there?
https://pve.proxmox.com/wiki/Qemu-guest-agent


And just for S&G I RE-INSTALLED the latest qemu drivers (you know, in case there was a bug or this repaired some-mismatch conflict in the CPU now or IDK), rebooted, and still unbearably slow.
https://fedorapeople.org/groups/vir...ownloads/archive-virtio/virtio-win-0.1.266-1/
1734302858000.png

And one more sanity test, I powered down. Set back to "x86-64-v2-AES" and it's zippy fast again. ?!?!?
 
Last edited:
Hello DAE51D! This sounds really weird. Just to be sure, did you read the best practices on installing Windows on Proxmox VE? These are the best practices for Windows 11. Make sure to install the correct drivers for Windows 11.

Otherwise, did you configure anything special in the CPU advanced settings? I heard about some issues if Enable NUMA is enabled.

Is there any process that consumes 100% CPU? You could try to show us a list of all processes sorted by CPU usage.


EDIT: I created a page for Windows 11, so now I'm linking to the correct wiki page for Windows 11.
 
Last edited:
  • Like
Reactions: Kingneutron
Hey guys, sorry for jumping in like this instead of creating a new post. I just wanted to let you know that I experienced the exact same thing.
I was messing around with gpu passthrough and followed a guide where I had to select "host" as the CPU type. The same evening I had a long power outage, followed by a problem with my ISP and I was unable to finish everything. Fast forward 4 days and I couldn't remember what I was doing. I just noticed that my Windows VM's performance is inacceptable. Speedtests where only showing wonky 250-350Mbit/s down instead of ~1080Mbit/s I normally get (2.5Gbit/s router/switch). My CPU-Z Benchmark was showing 3200 points instead of ~4600 points etc. After much troubleshooting I found this comment under a reddit post saying that changing from "host" to "x86-64-v2-AES" makes a big difference and yeah, they were right. Although some things are not up the the recommended settings linked in the post above, the VM is now really snappy again. Basically bare metal speeds.

Here's a small clip I made showing my settings and the issue: https://s.miepz.de/QORA6/POTuFoQo33.mp4/raw
(please remove the link if that's not allowed and I'll try to upload it directly)

I'm not planning on passing my GPU through anymore or changing any settings at all because, never touch a running system. And for what I'm doing with this server, the performance is good enough. I just wanted to step in saying that they're not the only person with this problem.
In case it matters, here are my specs:

Minis Forum UN1290
Intel Core i9 12900HK
32 GB RAM
1TB NVMe PCIe Gen4 SSD (KINGSTON OM8PGP41024Q-A0)
2.5Gbit/s LAN

PVE 8.3.4
Windows Server 2025 with all updates (as of 03.03.2025)

Btw the same thing was happening on my Minis Forum NAB9 with nearly identical specs, just a 1TB SATA drive instead of NVMe.

Best Regards
derMiepz
 
We have experienced the same issue with "host" CPU type. I'd have to look back at my upgrade dates, but I think coincides with one of the 8.2.X upgrades (and possibly 24H2). Windows 11 Pro VMs were becoming unusable in cases until the CPU type was changed to "x86-64-v2-AES". It certainly seems like there is an issue here and I'd be happy to spin up test VMs to help troubleshoot.
 
  • Like
Reactions: Johannes S
DAE51D said:
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.

View attachment 79185

[...]
View attachment 79189

And one more sanity test, I powered down. Set back to "x86-64-v2-AES" and it's zippy fast again. ?!?!?
Click to expand...
First pic x86-64-v2-AES : Windows detects VM (Virtual machine = Yes) so no nested Hyper-V running (required for VBS )
Second pic "host" : Windows doesn't detect VM ( Virtualisation = Enabled ) suggest Hyper-V or WSL enabled within Windows guest and/or optionnal args used ( hidden=off or kvm=off )

Windows 24H2 use/active Hyper-V and so, nested Hyper-V, for its Virtualization-based Security (VBS).
Check VBS state from msinfo32.exe , at the bottom of the first page.

Nested Hyper-V is slow , even slow on olders CPUs , even more with mitigations enabled.
 
Last edited:
  • Like
Reactions: Johannes S
related findings :
K

Thread 'The Reasons for poor performance of Windows when the CPU type is host'

Hey guys, I did some experiments recently and I think I finally found out why Windows performs poorly when the CPU type is host. You can check the complete experiment process and conclusion in my blog (Chinese, use google translate!)

In short, the experiment finally found that the reason was that the two flags md_clear and flush_l1d caused performance problems. They would activate the CPU vulnerability mitigation measures of Windows, which would cause a significant increase in memory read latency, thus causing Windows to freeze.

The two flags md_clear and flush_l1d are not passed...
  • Like
 
  • Like
Reactions: logics and Johannes S
You must log in or register to reply here.
Top Bottom