Testing CPU types to improve Windows VM performance

Testing CPU types in Proxmox

I spent a long run of tests changing CPU types on Windows guests in Proxmox. The aim was simple: see whether a different CPU model changed disk I/O. I kept everything repeatable, measured before and after, and wrote down every config change that mattered.

Changing CPU types in Proxmox

Proxmox gives each VM several CPU models to choose from. The common ones are host, qemu64, kvm64 and a range of vendor-specific models. Host passes through the host CPU feature set. The emulated models present a more stable, generic CPU interface to the guest.

How I changed CPU type:

Power off the VM.
In the Proxmox GUI go to Hardware → CPU → Edit → choose the CPU model. Or use qm set <vmid> -cpu <model>.
Boot the VM and check CPUID flags with tools such as CPU-Z or msinfo32.

I tested both ends of the range: host-passthrough and a generic emulated model. I left the other variables alone. I used a snapshot or a disposable VM image for each change, never production.

Measuring I/O performance

Use repeatable tests and run them more than once. For Windows guests I used:

CrystalDiskMark for quick, comparable sequential and random I/O runs.
DiskSpd for more configurable, realistic load patterns.
Windows Performance Monitor counters for latency and queue depth.

My measurement routine was:

Reboot the guest after each CPU change.
Run a warm-up pass so caches settle.
Run three test passes and take the median.
Record raw numbers, IOPS, MB/s, and 95th percentile latency.

Log the full setup: VM config, such as CPU model, cores and sockets; disk type, such as virtio-scsi or IDE; storage backend, such as ZFS, LVM or local SSD; driver versions; OS build; and the test tool parameters. A Reddit post that caught my eye claimed a large I/O jump after a CPU model change; treat that sort of claim as a lead, not a fact, and reproduce it in your own setup before trusting it. https://reddit.com/r/Proxmox/comments/1ohb2v9/increaseddriveperformance15timesbychanging/

Security features and their impact

Changing the CPU model changes the CPUID the guest sees. That can change which mitigations the guest thinks are available, and that can affect performance for some workloads. QEMU documents the difference between system emulation and host passthrough, and how the hypervisor presents CPU features; it is worth reading for background. https://en.wikipedia.org/wiki/QEMU

I would not disable mitigations blindly. I checked the CPUID flags after each change, compared kernel or OS messages for mitigation-related behaviour, and tested workloads that stress the relevant paths, such as small random writes and fsync-heavy work.

Configuration discipline

Keep the change narrow. Change the CPU model only. Do not change the disk format, SCSI controller, caching mode or virtio driver at the same time. A few useful rules:

Use virtio-scsi and current virtio drivers on Windows. Old drivers hide the benefit.
Match the number of vCPUs to host topology where you can. Avoid overcommit if possible.
Use host-passthrough if you need exact CPU features and do not plan to live migrate.
Use emulated models if you want portability between hosts and easier live migration.
Take snapshots before testing destructive changes.

Record the full environment: Proxmox version, QEMU args, storage backend, and firmware type, whether SeaBIOS or OVMF.

Documenting the changes

I kept a simple wiki page for each VM I tested. It held:

Baseline numbers and test parameters.
The exact qm set or GUI selections I changed.
The final config that gave the best result, plus the trade-off I accepted.

I used a CSV for raw numbers and a short Markdown note for config decisions. That saved time when I needed to revert or repeat a setup.

What changed in practice

Reported results and my own notes

A forum report claimed a 15x increase after switching CPU model. Anecdotes like that are useful as starting points. In my lab I saw anything from almost no change to large gains, depending on workload and driver stack. Heavy metadata work and fsync-bound apps showed the biggest changes.

When you test, separate latency from throughput. Some changes cut latency without lifting sustained MB/s. Log both.

Short case notes

I will keep two short examples from my notes, anonymised:

Case A: Windows 2019 guest on local NVMe, virtio-scsi. Switching from host to a conservative emulated model reduced small random write latency by 30% and improved 4k IOPS by 40%. The guest had old virtio drivers; updating those gave most of the gain, and the CPU model change added a measurable delta.
Case B: Windows 10 dev VM on a ZFS-backed pool. There was no meaningful change between host and emulated CPU for sequential throughput. The bottleneck was ZFS sync settings and disk writeback, not CPU CPUID differences.

Those results show the same thing in different clothes: storage backend, guest drivers and workload all matter.

Long-term trade-offs

Think past the immediate gain. Host-passthrough can break live migration if the hosts differ. Emulated models improve portability but may change which mitigations the guest recognises. Keep a note if you accept a CPU model that changes security-visible flags.

Patch management matters too. Vendor OS updates or microcode fixes can change performance. Retest the workloads that matter after major updates.

Different hypervisors

Different hypervisors expose CPU features in different ways. If you move guests between KVM/QEMU and something else, expect variation. That makes baseline testing on the target hypervisor the only sensible approach. Do not assume results from one platform carry over.

How I would test it again

Define the workload and the metric you care about.
Baseline the current config.
Change the CPU model only, reboot, then retest.
Run driver updates as a separate test.
Keep a log of the exact commands and output.

Write the hypothesis down first. For example: “I expect random write latency to fall when switching to emulated-cpu-X because mitigation Y will not be exposed.” Then test it and see whether the numbers back it up.

The useful bit is simple: CPU type is a cheap, reversible variable that can shift Windows VM performance, but the result depends on the whole stack. Test, measure, write it down, and keep the portability and security trade-offs in view.