Windows 11 on Proxmox Is Broken for Some Power Users, Cause Unclear

Few things are as frustrating as a problem that shows up after you've done everything "right."

You buy a flagship CPU and pair it with fast DDR5, bleeding-edge NVMe storage, a modern GPU and a clean Proxmox install. On paper this thing should scream. Linux VMs fly, benchmarks on the host look perfect, temperatures are fine, and boost clocks are there when you need them.

Then you boot into a fresh Windows 11 VM, open Task Manager, and everything feels… wrong.

Apps crawl and simple UI actions lag. Cinebench scores look like they came from a laptop released a decade ago. Windows insists your many-core monster CPU is running at a suspiciously neat 2.0GHz, and no amount of tuning seems to move that number.

For a growing number of power users this has become a pattern that one bad setting can't explain, and right now nobody fully agrees on what's actually broken.

The setup that should be impossible to mess up

The affected systems all look roughly the same: modern Intel CPUs with hybrid architectures, Proxmox as the hypervisor, Windows 11 as the guest, often with GPU passthrough, and often built as high-end workstations rather than homelab toys.

On the host side, everything behaves exactly as expected. CPU boost clocks hit 5GHz and beyond, disk throughput is absurdly fast, GPU passthrough works, network performance is fine, and Linux guests feel snappy.

Inside Windows 11, though, the experience collapses. Multi-threaded benchmarks land around 3,000 points when they should be closer to 30,000. Heavy apps take minutes to launch, File Explorer hesitates, and Task Manager shows almost no CPU usage while the system feels like it's wading through mud.

And yes, Windows always reports that a hypervisor is present. That part isn't surprising. What is surprising is how consistently bad the performance stays no matter what people change.

The 2.0GHz red herring

One of the first things everyone notices is the clock speed. Windows reports the CPU maxing out at roughly 1997MHz, which looks damning but is also misleading. Under KVM, Windows doesn't have reliable access to real-time frequency scaling, so it often shows the TSC base clock instead of actual boost behavior.

Normally that doesn't matter, because even if the number looks wrong, the performance is still there. Here it isn't. The low Cinebench scores and real-world sluggishness confirm the problem goes beyond a cosmetic readout. Something is actively preventing Windows from using the CPU the way it should.

E-cores, P-cores, and the pinning rabbit hole

The first major theory centers on Intel's hybrid core layout. Modern i9 chips mix performance cores and efficiency cores, and Linux doesn't always enumerate them in a clean, intuitive order. Pin the VM to the wrong logical CPUs and you might end up running a heavyweight Windows workload almost entirely on E-cores.

That explanation makes sense, and it's happened before. Tools like lscpu can lie by omission, while hwloc reveals a very different topology. Several users were convinced this had to be the issue.

Many of the affected systems had done their homework, though. They verified core mappings with lstopo, pinned only confirmed P-cores, and matched sockets, cores and threads correctly. Windows reported the expected topology, and performance still didn't budge. If this were just bad pinning, fixing the affinity would've solved it, and for a lot of people it didn't.

Hyper-V enlightenments: optimization or trap?

Another camp points to Hyper-V enlightenments. Windows expects certain paravirtualization hints when it's running under a hypervisor. They exist as performance shortcuts rather than for detection: they reduce VM exits, improve interrupt handling, and generally keep Windows from doing dumb, expensive things.

In desperation, many users tried disabling all Hyper-V flags, hiding KVM, and stripping the VM down to bare metal vibes in hopes of tricking Windows or GPU drivers. They may have kneecapped performance instead.

Several experienced Proxmox users argue that removing those enlightenments, especially combined with kvm=off, effectively forces Windows into a worst-case compatibility path. You still have a VM, just without the optimizations that make it usable.

That fits the symptoms. Some users, however, restored all recommended Hyper-V flags, removed kvm=off, and still saw no improvement. At that point the blame starts drifting away from configuration.

The Windows 11 24H2 suspicion

This is where things get uncomfortable. Multiple reports mention the same pattern: older Windows versions behave fine, Linux VMs behave fine, Windows 10 behaves fine, and Windows 11 23H2 behaves fine. Windows 11 24H2 does not.

Fresh installs of 24H2 feel broken out of the gate. Rolling back to older ISOs restores normal performance on the same Proxmox host, with the same VM configuration.

That strongly suggests a regression, either in Windows itself or in how QEMU presents certain CPU features to newer Windows builds. There's precedent for this kind of thing. Microsoft has been steadily tightening virtualization security, adding layers like VBS, HVCI and deeper scheduler changes. Most of the time hypervisors adapt without anyone noticing. Sometimes they don't, and right now this might be one of those times.

"It's Proxmox." "No, it's QEMU." "No, it's Windows."

Ask ten people what's broken and you'll get three confident answers. Some argue Proxmox hasn't caught up with recent Windows changes yet. Others insist Proxmox is just a wrapper and the issue lives squarely in QEMU. A third group points the finger at Microsoft for pushing assumptions that don't hold outside Hyper-V.

What makes this messier is that each explanation sounds plausible, and none of them fully explains why identical configurations behave so differently across Windows builds.

The lack of a clear smoking gun is why this issue feels so maddening. There's no kernel panic, no obvious error, and no single toggle that fixes it for everyone, just slow Windows, low CPU usage and a lot of wasted weekends.

The "CPU type" debate that won't die

One workaround keeps coming up: don't use cpu: host. Some users claim that switching to a generic x86-64 v2 or v3 CPU model, and reinstalling Windows from scratch afterward, magically fixes everything. The theory is that exposing too many modern CPU features causes Windows to enable behaviors that perform badly under KVM.

The problem is that plenty of people tried exactly that and saw no change at all. It might work for some setups and clearly doesn't for others, which makes it feel more like a dice roll than a solution.

Why this hurts more than a typical bug

These machines are workstation-class boxes used for CAD, rendering, development and creative work, far from a niche lab setup. The whole point of Proxmox here is consolidation, with one powerful box doing everything. When Windows inside that box suddenly performs like it's running on a ten-year-old CPU, the entire value proposition falls apart. And because Linux guests are fine, it's hard to justify tearing down the host just to make Windows happy.

Where things stand right now

As of today, there's no universally accepted fix. The most reliable mitigation seems to be avoiding Windows 11 24H2 entirely, sticking to older builds, or falling back to Windows 10. That's not great, it isn't future-proof, and it doesn't help people who already reinstalled multiple times chasing ghosts.

What's missing is coordination: a confirmed bug report and a reproducible test case that Proxmox, QEMU or Microsoft can't ignore. Until that happens, the issue lives in the worst possible space, real and painful and just ambiguous enough that everyone thinks it's someone else's fault.

What to take from this

If you're running Windows 11 on Proxmox today and everything feels fine, that's great. Truly.

If you're planning a new high-end build, though, this is one of those moments where being an early adopter backfires. Hybrid CPUs, fast-moving Windows releases and complex virtualization stacks don't always play nicely together, even when each piece works perfectly on its own.

"Windows 11 on Proxmox" isn't broken for everyone right now, but for some power users it absolutely is. Until the community or the vendors pin down why, the safest workaround might be the least satisfying one of all: don't upgrade.