Windows guest performance · Proxmox VE

“The Windows VM is slow” is one of the least informative sentences in virtualisation, and it arrives more often than any other performance report. Part XVII gave you a general method for it. This lesson is about the parts that are specific to Windows guests — where the defaults are wrong, where the documented advice contradicts what people assume, and why the number inside the guest and the number on the host so often disagree.

Start from an uncomfortable fact: the majority of Windows performance tickets in a healthy estate are not caused by anything Windows-specific. They are caused by host contention, storage that is saturated by a different guest, or a vCPU count that somebody increased in an attempt to fix the first two. Confirm the host is healthy before you touch the guest, using Part XVII. Everything below assumes you have.

CPU: the default is portable, not fast

cputype defaults to kvm64, which the administration guide describes as a model that “works on essentially all x86_64 host CPUs”. That is the whole design goal — it is a lowest-common-denominator model chosen so a VM can live migrate between a ten-year-old Xeon and a current EPYC without the guest noticing.

What it costs is every instruction set extension added since roughly 2007. For a Windows guest that means the AES instructions BitLocker and TLS want, the vectorised paths that compression, media handling and modern .NET code paths take, and the population-count and bit-manipulation instructions that show up in hot loops all over the place. None of this produces an error; it produces software silently taking a slower path.

The other end is host:

If you want an exact match, you can set the CPU type to host in which case the VM will have exactly the same CPU flags as your host system.

with the documented caveat:

If you want to do a live migration of VMs between different hosts, your VM might end up on a new system with a different CPU type or a different microcode version.

The Proxmox best-practice pages for Windows Server 2022 and 2025 both recommend host. For a homogeneous cluster that is straightforwardly right. For a mixed cluster the honest choice is a named model that every node supports — the oldest generation in the cluster — which gets you most of the instruction sets without making migration a gamble. Part IX covers the model selection; the Windows- specific point is only that kvm64 costs Windows more than it costs a typical Linux guest, because more of the Windows userland is compiled to take advantage of what it finds.

`ostype` is a performance setting

This is the third time Lesson 1’s ostype field appears, and here is why. The qm.conf reference describes it as:

Specify guest operating system. This is used to enable special optimization/features for specific operating systems.

Optimisations, not labels. The KVM hypervisor can present Windows-specific interfaces to a guest that recognises them, and Proxmox decides whether to do so from the guest type. A related option corroborates this: --cpu carries a hv-vendor-id sub-option, a custom Hyper-V identifier string — an option that would have no reason to exist unless Windows guests were being given a Hyper-V-compatible interface to talk to.

The practical instruction is unchanged and now has a third reason behind it: set ostype correctly. A Windows guest declared other runs with generic settings on a hypervisor that had better ones available.

vCPUs: more is frequently slower

The administration guide is relaxed about overcommit in aggregate:

It is perfectly safe if the overall number of cores of all your VMs is greater than the number of cores on the server […] However, Proxmox VE will prevent you from starting VMs with more virtual CPU cores than physically available.

That is a statement about the host. It is not permission to give a single guest more vCPUs than it can use, and on Windows the penalty for doing so is larger than intuition suggests.

The rules that hold up in practice:

Start at 2 or 4 vCPUs and increase only with evidence. A guest that is 90% idle on four vCPUs will be 95% idle on eight and slightly slower.
One socket unless you need NUMA. --sockets 1 --cores 8, not --sockets 8 --cores 1. Multiple virtual sockets imply a NUMA topology to the guest, and Windows will schedule as if the topology were real.
--numa 1 only for guests large enough to span host NUMA nodes, and then with a topology that matches the host. The option defaults to 0. A guest smaller than one host node gains nothing and inherits a scheduling constraint.
Windows Server licensing is per physical core on the host, not per vCPU — but many application licences are per vCPU. Check before you double a guest.

Under the hood

Why does an oversized Windows guest degrade more than an oversized Linux guest on the same host?

Both operating systems use spinlocks — short critical sections where a CPU busy- waits rather than sleeping, because the expected wait is shorter than the cost of a context switch. The assumption underneath a spinlock is that the CPU holding it is running and will release it within a few microseconds.

Virtualisation breaks that assumption. A vCPU is a thread on the host, and the host scheduler can preempt it at any instant — including while it holds a spinlock. Every other vCPU that wants that lock then spins, burning its whole timeslice, achieving nothing, and looking like 100% CPU usage from inside the guest. This is lock-holder preemption, and its cost rises with the number of vCPUs contending, not with the amount of work being done.

Windows leans on spinlocks harder than Linux does in the kernel paths a typical server workload exercises, which is why the effect shows up earlier there. It is also why the mitigation is the counterintuitive one: reduce the vCPU count. Fewer vCPUs means fewer threads to schedule, less chance of preempting a lock holder, and less spinning when it happens.

The hypervisor has a partial answer — paravirtualised spinlock support, which lets a guest tell the host “this vCPU is spinning, run someone else” instead of burning the timeslice — and it is one of the Windows-specific interfaces the guest type selects. It reduces the cost; it does not remove the reason to size guests honestly.

The observable signature is distinctive and worth recognising: high CPU inside the guest, moderate CPU on the host, and no corresponding work being done. If Task Manager shows 80% across eight vCPUs while the application is serving its usual request rate, you are probably looking at spin, not load, and adding vCPUs will make it worse.

Storage: controller, cache, and one honest tradeoff

The controller is settled: virtio-scsi-single, from Lesson 1, with the system disk on scsi0. “Single” gives each disk its own controller, which is what makes iothread=1 meaningful — a dedicated I/O thread per disk rather than contention on one.

Cache mode is where the documentation and the wiki appear to disagree, and it is worth resolving rather than picking one.

The administration guide describes the default:

No cache (default) […] the guest system will be notified that a write is complete when each block reaches the physical storage write queue

and calls it “a good balance between safety and speed”. The Windows best-practice wiki pages recommend Write back “for optimal performance”.

Both are correct, for different questions:

Mode	Write is acknowledged when	Use when
`none` (default)	it reaches the storage write queue, bypassing the host page cache	You want the documented balance and predictable behaviour under host failure
`writeback`	it reaches the host page cache	Throughput matters more than the window of exposure, and the storage is not already caching
`writethrough`	it is on stable storage, with reads cached on the host	Read-heavy guests where write latency is not the constraint
`directsync`	it is on stable storage, no host caching either way	Databases with their own durability requirements, or clustered storage
`unsafe`	immediately, ignoring guest flushes	Never on anything you would miss. Template builds and throwaway test guests only

What writeback actually exposes you to

writeback acknowledges a write once it is in the host page cache — memory on the hypervisor — rather than once storage has it.

Guest flush operations are still honoured, so an application that writes and then calls flush, as any database or transactional log writer does, is durable at the point the flush returns. What is exposed is everything written but not yet flushed at the moment the host stops: a host kernel panic, a host power loss, a hard reset. A guest crash does not lose it, because the host is still running and will write it out.

So the question to ask is not “is writeback safe” but “what is on this disk that is written without being flushed, and how much do I care about losing the last few seconds of it”. For a file server, a print server, a jump host, an application server whose state lives in a database elsewhere: very little, and the throughput is worth having. For a database server, a domain controller, or anything holding a transaction log: use the default, and let the application make its own durability decisions.

And one thing that is not a mitigation: a battery-backed or flash-backed cache on the storage controller protects the controller’s cache, not the host page cache. It does not make writeback safe against a host that loses power.

The remaining disk options are less contentious. discard=on lets the guest’s TRIM reach thin-provisioned storage, which matters on ZFS, LVM-thin and Ceph; ssd=1 presents the disk as non-rotational so Windows enables TRIM and disables the defragmentation schedule it would otherwise apply to a “spinning” disk; iothread=1 gives the disk its own thread. The aio sub-option accepts io_uring, native or threads, and Part IX covers when to move off the default.

The balloon driver: a documented tradeoff

Everything else in this lesson is a straightforward win. This one is not, and the administration guide says so without hedging:

For Windows OSes, the balloon driver needs to be added manually and can incur a slowdown of the guest, so we don’t recommend using it on critical systems.

Take that at face value. It is an unusual thing for a vendor to write about its own feature, and the reason is real: reclaiming memory from a Windows guest means the balloon driver allocates pages the guest then cannot use, and Windows responds to memory pressure by trimming working sets and paging — inside the guest, to a virtual disk, on shared storage.

The distinction that resolves this in practice is the one from Lesson 2:

The balloon driver enables reclaim. This is the part with the performance cost, and it only has a cost when the host actually reclaims.
The balloon service enables reporting. This has no performance cost at all, and it is what makes the Proxmox memory figure match Task Manager.

So the useful configuration for a critical Windows guest is: install both, and set a floor that prevents reclaim. The balloon option is documented as the “amount of target RAM for the VM in MiB”, and the driver is enabled by default unless explicitly disabled with zero. Setting balloon equal to memory gives you accurate reporting with no room for the host to take anything back.

Configuration changeaccurate memory reporting without reclaim— Sets the balloon target equal to the assigned memory, so the device reports statistics but the host never reclaims from this guest.

VMID=9100
qm set "$VMID" --memory 16384 --balloon 16384
qm config "$VMID" | grep -E '^(memory|balloon):'

For non-critical guests — test machines, seldom-used application servers, a desktop estate — a lower floor is a legitimate way to increase density, and the slowdown the guide warns about is a slowdown on a machine nobody is waiting for. Decide per guest, not per estate, and write the decision down.

Measuring, from both ends

A performance claim needs two measurements that agree. Guest-side numbers alone are unreliable under contention for the reason in the Under the Hood box: a guest cannot see time it did not get.

From the host, per-VM resource use over time:

Read-only / Safehourly CPU, memory and disk figures for one guest

# pvesh get /nodes/pve1/qemu/9100/rrddata --timeframe hour --output-format json | head -20

[
 {
    "cpu" : 0.184,
    "disk" : 0,
    "diskread" : 45056,
    "diskwrite" : 2686976,
    "maxcpu" : 4,
    "maxdisk" : 68719476736,
    "maxmem" : 17179869184,
    "mem" : 5837107200,
    "netin" : 88192,
    "netout" : 141312,
    "time" : 1786000000
 }
]

Illustrative output

Two things to read: cpu is a fraction of the guest’s total vCPU capacity, so 0.184 on maxcpu: 4 is roughly three quarters of one core; and mem is only meaningful if the balloon service is installed — otherwise it is close to maxmem for the reasons in Lesson 2.

From the guest, the counters that answer the question the ticket is really asking. Processor time tells you almost nothing on its own; queue lengths and latency tell you where the wait is:

Read-only / Safethe four counters worth sampling first— Read-only. Sixty one-second samples; run it while the guest is slow, not afterwards.

Get-Counter -Counter @(
  '\Processor(_Total)\% Processor Time',
  '\System\Processor Queue Length',
  '\PhysicalDisk(_Total)\Avg. Disk sec/Read',
  '\PhysicalDisk(_Total)\Avg. Disk sec/Write',
  '\Memory\Available MBytes',
  '\Memory\Pages/sec'
) -SampleInterval 1 -MaxSamples 60 |
Export-Counter -Path C:\perf\baseline.blg -Force

The guest says the disk is slow. The host says the disk is fine.

Avg. Disk sec/Read inside the guest shows 40 ms. On the host, the same period shows the underlying device answering in 2 ms and nowhere near saturated. The storage team says storage is fine. They are right. The Windows administrator says the disk is slow. They are also right.

The first diagnosis — “one of you is measuring wrong” — is the wrong one. Both measurements are accurate about different things. Guest-observed latency is host-observed latency plus every delay between the guest issuing the request and the host acting on it, and that gap has several possible occupants:

The vCPU was not running. If the guest’s vCPU is descheduled between issuing the I/O and processing its completion, the guest attributes the whole interval to the disk. This is the commonest cause and it is a CPU contention problem wearing a storage costume.
A single I/O thread behind several disks. Without iothread=1 on a virtio-scsi-single controller, disks queue behind each other on the host side, invisibly to both measurements.
Another guest owns the queue. The device is fast on average and the queue in front of it is not. Part XVII covers noisy neighbours.
Ballooning under memory pressure. The guest is paging to the same virtual disk it is trying to read from, so it is competing with itself.

The way to tell them apart is to check host CPU pressure first, before touching anything storage-shaped. If the host is oversubscribed, fix that and re-measure; the storage number will usually have fixed itself. Adding vCPUs at this point — the instinct, because the guest looks CPU-busy — makes both numbers worse.

What happens if I enable ballooning on a SQL Server guest?

Take a guest with 64 GiB assigned and a balloon floor of 16 GiB, running SQL Server with default settings, on a host that comes under memory pressure.

SQL Server takes all the memory it is allowed and does not give it back readily. Its buffer pool grows to fill available memory by design, because cached pages are the entire performance story for a database.

The host asks for memory back. The balloon driver inflates, allocating pages inside the guest that Windows can no longer use.

Windows resolves the resulting pressure the way it always does: it trims working sets and pages to disk. The pages it trims are, disproportionately, the buffer pool — the cached database pages that were the reason the database was fast.

The result is a database reading from disk what it had in memory a minute ago, over a virtual disk, on shared storage, while the host congratulates itself on reclaiming 48 GiB. Query times go up by an order of magnitude. Nothing errors. The Proxmox summary shows healthy memory availability on the host.

Two guardrails:

Set balloon equal to memory for database guests, so the device is present for reporting and the floor prevents reclaim — the configuration in the command block above.
Cap the database’s own memory inside the guest so it leaves headroom for the operating system regardless. A database configured to take everything is a problem on physical hardware too; virtualisation only makes it visible sooner.

The general form of this, which applies well beyond SQL Server: ballooning is safe for guests whose memory use is elastic and dangerous for guests that treat memory as a cache they own. Databases, in-memory caches, search indexes and JVMs with a large fixed heap are all in the second category.

Windows guest performance baseline

Set these deliberately on every Windows guest, and record the ones that deviate.

Setting	Value	Reason
`cpu`	`host` on a homogeneous cluster; oldest common model otherwise	`kvm64` costs Windows instruction sets it would use
`sockets` / `cores`	`1` socket, cores as needed	Multiple sockets imply a NUMA topology Windows will honour
vCPU count	2 or 4 to start; raise only on evidence	Lock-holder preemption punishes oversizing
`numa`	`0` unless the guest spans host NUMA nodes	Default, and correct for most guests
`scsihw`	`virtio-scsi-single`	Per-disk controller, so `iothread` means something
`iothread`	`1` on every disk	Dedicated host thread per disk
`ssd`	`1`	TRIM enabled, defragmentation schedule disabled
`discard`	`on`	Space returned to thin-provisioned storage
`cache`	default `none`; `writeback` only with the tradeoff understood	See the table above
`balloon`	equal to `memory` on critical guests	Reporting without reclaim
Balloon service	installed everywhere	Costs nothing, and without it your memory data is fiction

Before you change anything in response to a complaint: confirm host CPU pressure and host storage latency first. Most Windows guest performance tickets are answered on the host.

Key takeaways

kvm64 is the portable default and costs a Windows guest every instruction set added since the mid-2000s. Use host on a homogeneous cluster, or the oldest common named model on a mixed one.
ostype is documented as enabling special optimisations for specific operating systems. It is a performance setting, not a label.
More vCPUs is often slower. Lock-holder preemption scales with the number of contending vCPUs, and its signature is high guest CPU with no extra work done.
Cache mode is a real decision with a real exposure. writeback acknowledges writes into the host page cache; guest flushes are still honoured, so the loss window is unflushed data at the moment the host dies.
Proxmox does not recommend the Windows balloon driver on critical systems. Install the balloon service everywhere for reporting, and set balloon equal to memory on guests where reclaim would hurt.
Guest-observed latency includes time the vCPU was not running. Check the host before you believe a guest-side storage number.

Knowledge check

Why this matters

Windows guest performance work has a specific failure pattern: the person reporting the problem can see inside the guest, the person who can fix it can see the host, and the two of them are looking at numbers that disagree for good reasons neither can see from where they stand. That is how a CPU contention problem gets escalated to a storage team, and how a storage team correctly proves it is not their problem without anyone getting closer to a fix.

The settings in this lesson are worth getting right because they are cheap and permanent — a CPU model, a controller, an I/O thread, a balloon floor, chosen once at build time. But the habit is worth more than the settings. Measure both sides. Insist that the two agree before believing either. When they disagree, treat the disagreement as the finding rather than as an argument to win, and work out what lives in the gap.

Do that consistently and the majority of “the Windows VM is slow” tickets stop being about Windows at all — which is the correct conclusion, and the one that is hardest to reach from inside the guest.