1
2

qm set 102 --cpu x86-64-v2-AES    # or x86-64-v3 if every host is Haswell / EPYC or newer
qm stop 102 && qm start 102       # a reboot from inside Windows does NOT apply the change

Symptoms

Windows 10, 11, or Server with cpu: host: slow boot, stuttering desktop, multi-second freezes, anything that touches memory is bad. The same VM with x86-64-v2-AES responds normally. A Linux VM with host on the same node notices nothing.

Why it happens

host passes the VM every flag of the physical CPU, including two that exist for Intel vulnerability mitigations:

Inside a VM those operations are extremely expensive. The measurements from the original Proxmox forum thread: on a Xeon E5-2667 v2 the RAM read latency goes from ~100 ns to ~2000 ns; on an i9-13900K, from 30 to 90 ns. Windows, which touches kernel memory all the time, crawls.

The generic types (x86-64-v2-AES, x86-64-v3, IvyBridge-IBRS, …) do not expose those two flags, so Windows neither sees the vulnerability nor turns on the mitigation.

Which type to pick

Pick the highest one that every node in the cluster supports:

1

grep -o -w -E 'avx2|avx512f' /proc/cpuinfo | sort -u   # avx2 → v3 ok; avx512f → v4 ok

That is the Proxmox staff recommendation in that same thread: use the x86-64-v* matching the hardware instead of blindly turning security flags off.

If you insist on host

There are cases where host is needed: nested virtualization (Hyper-V, WSL2 inside the VM, an ESXi lab), because the x86-64-v* types do not expose vmx/svm. You can drop md_clear with the flags option:

1

qm set 102 --cpu host,flags=-md-clear

But flush_l1d is not in the list of flags Proxmox lets you touch, so you keep half of the problem. And hiding mitigations from the guest is a security decision: reasonable on a single-owner node, not on one with tenants you do not control.

Checking from inside Windows

Microsoft’s official module shows which mitigations the guest has active:

1
2

Install-Module SpeculationControl -Scope CurrentUser
Get-SpeculationControlSettings

With host, MDSWindowsSupportEnabled and L1TFWindowsSupportEnabled come out True; with x86-64-v2-AES, False. It is the quick way to confirm the change applied.

Traps

• The change needs stop/start. The CPU type is fixed when the QEMU process launches; a reboot from inside the guest does not touch it.
• It is an Intel thing. md_clear and flush_l1d do not exist on AMD; with host on EPYC/Ryzen you will not see this drop (though host still blocks migration across different CPUs).
• It applies to new VMs too. Templates created with host inherit the problem; change it in the template.
• Windows stays safe against what matters inside a VM with either type: the mitigations that count (Spectre v2, etc.) remain active; what goes away is the double mitigation of vulnerabilities the host already mitigates.

References: Proxmox forum thread and the CPU section of the admin guide.