Slow Windows VMs in Proxmox? The CPU Type Setting May Be the Fix

For anyone running a homelab or managing virtual machines on Proxmox, slow Windows VM performance is one of those nagging problems that feels like it shouldn't exist, and yet it does. You've done everything right. Resources are allocated, disks are fine, and there are no weird logs, but your VM drags like it's stuck in molasses. Sound familiar?

There's a fix, and it's hiding in plain sight in the CPU type setting.

The problem nobody warned you about

A Proxmox user recently shared a story that struck a chord with a lot of folks. They'd been living with abysmal performance on their Windows VM for a while, the kind where just opening the Start menu feels like a minor act of bravery. They'd double-checked everything, from disk settings and drivers to registry tweaks, and nothing worked.

Then, almost by accident, they changed the CPU type from "Host" to a specific emulated model (AES-V2 in their case), and performance went 15x faster. That's a night-and-day difference from flipping a single virtual switch.

Wait, isn't "Host" the best option?

That's what we've all been told: "Use 'Host' for maximum performance." Normally that advice holds water, especially for Linux VMs or in clustered environments where live migration is in play. When it comes to Windows VMs, not so fast.

The core issue lies with how Windows handles CPU vulnerabilities. When you pass the full host CPU feature set to the VM (which is what "Host" does), Windows assumes it's running on a real, physical processor, one that might not be patched against certain side-channel vulnerabilities like Spectre or Meltdown.

So Windows overcompensates. It piles on software-based mitigations, which are resource-heavy and, as multiple users pointed out, absolutely tank CPU and disk performance. Even if your hardware is technically patched, Windows isn't convinced, and it acts like it needs to babysit the CPU every step of the way.

One Proxmox user explained it bluntly: "It causes mitigations which absolutely demolish CPU time and also nuke storage mediums. You can easily have a disk be constantly busy while doing nothing." Yeah, it's that bad.

Emulation to the rescue

Switching the CPU type to something like AES-V2, AES-V3, or AES-V4 filters out problematic CPU flags, specifically md_clear and flush_l1d, among others. These flags are often tied to the performance hits.

By choosing an emulated CPU model, you're giving the guest OS a "cleaner" CPU profile that doesn't raise red flags for Windows' paranoid security layer. The unnecessary mitigations go away, and responsiveness jumps dramatically.

One user with an AMD Ryzen 5 PRO 4650G saw performance skyrocket after switching away from "Host." Another with a 5800H-powered mini PC saw better results across the board using x86-64-v2-AES.

But what about compatibility?

Good question. Emulated CPU types help with compatibility and migration as well as performance. For example, if you're running a Proxmox cluster with different CPUs across nodes, choosing something like AES-V2 makes live migrations more reliable, because all VMs see the same CPU features regardless of the physical hardware underneath.

There are caveats, though. If you pick a CPU type that your hardware doesn't fully support, you will run into stability issues. One commenter warned that choosing Epyc V4 on a non-Ryzen 7000 host caused crashes when the guest tried to execute unsupported instructions.

So while newer is sometimes better, you need to choose a CPU model that makes sense for your host hardware.

Should you do this?

If you're running Windows VMs on Proxmox and seeing sluggish performance, especially on Intel chips, this might be the tweak that saves your sanity. If you're running Linux, you're probably fine with "Host."

Here's a quick checklist:

• VM is Windows-based
• Performance is inexplicably bad (CPU spikes, disk usage, UI lag)
• You're using "Host" as the CPU type
• Host CPU is Intel (but even AMD systems aren't immune)

Try changing the CPU type to AES-V2 or x86-64-v2-AES and see what happens. Chances are it'll feel like you just unshackled your VM from a ball and chain.

Why isn't this in the wiki?

That's the frustrating part. Despite being a real issue that's been affecting users since early 2025 (if not earlier), this isn't mentioned in the official Proxmox documentation. Instead, it lives in scattered forum threads, obscure blog posts, and now, here.

One user summed it up: "Stuff like this should be in the best practice/wiki, not just in random forum threads… Not mentioning this anywhere sucks."

And they're right. Proxmox is a powerful platform with a passionate community, but sometimes you're left feeling like you have to earn your stripes the hard way.

Final thoughts

If your Windows VM is dragging its feet and you've already tried all the usual suspects, don't overlook the CPU type. "Host" might be the default wisdom, but as this growing body of user experience shows, it's not always the best option.

Proxmox gives you the tools to tweak and tune just about everything, but sometimes the best solutions are buried under a pile of assumptions. In this case, it took a random setting tweak to uncover a performance breakthrough. Hopefully this helps more people skip the pain and get straight to the fix, because no one should have to suffer through a 5-minute boot time just to check a few emails.