It’s a long story when it comes to run Windows VMs in Proxmox and luckily the things became pretty well in the recent years. However, from time to time people start complaining about performance issues that are mostly only visible on Windows systems and this has mostly three major reasons:

• Missing Drivers / Guest Tools
• Wrong configuration / usage (e.g., still using VMDK disk files, controllers, devices)
• Wrong CPU Type

As said, within the recent years the situation got much better but we also had to deal with some insane hardware vulnerabilities like Spectre and Meltdown for CPUs. Spectre and Meltdown are two significant security vulnerabilities that affect modern processors, particularly those from Intel, AMD, and ARM. Discovered in 2017 and publicly disclosed in early 2018, these vulnerabilities exploit critical flaws in speculative execution, a performance optimization technique used by CPUs.

And this is also partly a reason why Windows virtual machines (VMs) running on Proxmox Virtual Environment (PVE) may experience sluggish performance when using the native host CPU. Basically, this issue often stems from the CPU flags passed by Proxmox.

Understanding the Problem

The Reddit user Kobayashi Bairuo wrote a great summary with some more detailed testing in his blog post about this situation. Since this is only available in Chinese, let me sum up the things.

The primary reason for poor Windows performance on Proxmox/KVM is that PVE may pass inappropriate CPU flags to the guest. These flags can trigger additional CPU vulnerability mitigation measures or invoke alternative data paths within Windows, resulting in significant performance degradation.

A common misconception is that the slowdown is primarily caused by Windows 10’s Hyper-V virtualization startup or Virtualization-Based Security (VBS). While disabling Hyper-V using bcdedit /set hypervisorlaunchtype off may sometimes help, it doesn’t address the root issue.

The Impact of CPU Flags

Certain CPU flags, particularly md_clear and flush_l1d, are designed to mitigate CPU vulnerabilities like Meltdown and Spectre. While these flags enhance security, they can severely impact performance. Proxmox may pass these flags when using the native host CPU type (host).

This can lead to increased latency and reduced responsiveness in Windows VMs.

Optimizing CPU Performance

To maximize CPU capacity and improve Windows performance, consider the following options:

1. Customize CPU Flags: Instead of using the host CPU directly, define a custom CPU type in Proxmox. Problematic flags can be filtered out, and only necessary ones enabled.
2. Disable md_clear: While md_clear cannot be disabled using the args parameter, it can be directly disabled within the CPU parameters. This can significantly reduce latency.
3. Choose the Closest CPU Type: Select the CPU type that closely matches the actual hardware and manually enable beneficial flags without introducing problematic ones.

A Word of Caution

Disabling md_clear and flush_l1d removes important protections against side-channel attacks like Meltdown. While this may enhance performance, it also increases the risk of security vulnerabilities.

These adjustments are generally not recommended for production environments. They are better suited for test setups, gaming applications, or other non-critical use cases where performance is prioritized over security.

Conclusion

The performance degradation seen in Windows VMs on Proxmox is often due to the CPU flags applied rather than the virtualization process itself and do not have any impacts on Linux guests. By carefully customizing CPU settings, significant performance improvements can be achieved without completely compromising security. Evaluating specific workload needs will help determine the most suitable configuration for a smoother Windows experience on Proxmox. In most cases with “modern” CPUs, you should be good to go with the type x86_64-v3 or fallback to x86_64-v2-AES. If you’re already on a very new CPU, you can also stick to x86_64-v4 which enables the AVX512 instruction set. To test which works for you, you can simply create a new blank VM and test the given CPU types – unsupported types will be rejected when powering on the virtual machine.