Because both VBS and WSL2 rely heavily on nested virtualization (requiring the host CPU type), they add a massive layer of overhead. If you search the forums, there is no universal fix. And I guess there is none, as it depends on the underlying hardware. In my enterprise setup, I have 3rd generation Xeon processors with two sockets.

One of the potential fixes I found is to use cpu: host and hv-passthrough. The performance instantly feels like bare metal. But there’s a massive catch: hv-passthrough completely breaks live migration. If you try to migrate a VM with hv-passthrough enabled, QEMU will block it outright.

The reason hv-passthrough breaks migration is that it asks the host kernel for every possible Hyper-V feature and passes it to the guest. This includes highly volatile timing states like hv-frequencies and hv-reenlightenment.

What is the alternative if VBS and/or WSL2 are required? Manually adding all the features to the args: field in the VM config file.

We can ask QEMU what it's actually doing—instead of guessing which flags we need—by interrogating it directly via the QEMU Machine Protocol (QMP) socket. While the VM is running with hv-passthrough, you can connect to its UNIX socket from the Proxmox host shell:

socat - UNIX-CONNECT:/var/run/qemu-server/<VM_ID>.qmp

After sending a quick JSON handshake: { "execute": "qmp_capabilities" }

and

{ "execute": "query-cpu-model-expansion", "arguments": { "type": "full", "model": { "name": "host", "props": { "hv-passthrough": true } } } }

to ask what features are being passed to the guest, QEMU spits back a massive JSON wall of text showing the true/false state of every single hardware flag. By pulling out the hv-* flags that return true, we get our exact, explicit hardware baseline.

So, we take that explicit list, remove the volatile clock flags (hv-frequencies and hv-reenlightenment), and paste it into our config. Migration works! But... performance degrades again.

Based on the research I did into this specific topic, my understanding is: without hv-frequencies, Windows loses the ability to sync with the hardware's Time Stamp Counter (TSC). Because VBS and WSL2 demand perfect timing, the lack of physical frequency data forces them back onto a slow, software-emulated timer.

Luckily, the story does not end here. With a bit of help from AI, I found a way to overcome this limitation by hardcoding the TSC. I needed to tell Windows the exact physical speed of our silicon, but mark it as "invariant" so QEMU knows the clock won't drift between cluster nodes.

• +invtsc (Invariant TSC): This tells Windows 11, "The physical CPU clock will never fluctuate or desync, so you can safely use it for high-performance VBS."

• tsc-frequency=2900000000: By hardcoding this exact number, QEMU knows that the source and destination nodes will have the exact same clock expectation, allowing it to authorize the live migration.

args: -cpu host,+vmx,+kvm_pv_eoi,+kvm_pv_unhalt,hv-relaxed,hv-vapic,hv-time,hv-synic,hv-stimer,hv-vpindex,hv-ipi,hv-runtime,hv-reset,hv-crash,hv-spinlocks=0xfff,hv-tlbflush,hv-tlbflush-ext,hv-tlbflush-direct,hv-stimer-direct,hv-apicv,hv-avic,hv-evmcs,hv-xmm-input,hv-emsr-bitmap,host-cache-info=on,l3-cache=on,+invtsc,tsc-frequency=2900000000

This allowed me to regain the performance I had when using the host CPU type and hv-passthrough.

While I was testing all those features, I noticed that my lab setup did not behave the same way. To get the performance back in my lab—where I have a quite recent desktop CPU (Intel Core Ultra 9 285K)—I did not have to specify the clock speed and invtsc.

This simplifies the setup because, as of Proxmox release 9.2.4 (or 5), it is possible to define a custom CPU type with hv-flags. By doing so, I can have VBS and WSL2 enabled in my lab setup with a custom CPU type defined. In my enterprise setup, the custom args: still need to be defined due to the custom clock frequency.

This workaround does not solve the issue of significantly higher idle CPU usage with Win 11 24H2+.