Proxmox VM CPU Type: Fixing the kvm64 Default

For most Proxmox virtual machines, you should choose the host CPU type instead of the default kvm64, because it passes your physical CPU’s features to the VM, giving significantly better performance and compatibility. The kvm64 default is a safe, generic baseline that works on any host, but it lacks modern instruction sets like SSE4.2 and AVX, which many current operating systems and applications expect. This article explains the trade-offs, how to choose the right type, and when sticking with kvm64 might actually be the safer option.

What Is the kvm64 CPU Type?

When you create a VM in Proxmox, the CPU type defaults to kvm64. This is a virtual CPU model that emulates a 64-bit AMD processor from around 2005. It was chosen as the default because it is the most compatible: any x86-64 host can run it, and it works with all guest operating systems that support 64-bit. However, it only exposes a minimal set of CPU flags, meaning the guest OS cannot use newer instructions even if your physical CPU supports them.

The table below shows the practical difference: kvm64 lacks SSE4.2, AVX, and AES-NI, while host passes through everything your CPU has.

kvm64: baseline x86-64, no SSE4.2, no AVX, no AES-NI
qemu64: similar to kvm64, but with a few extra flags; still old
host: passes through all CPU features of the physical host
Other named models: e.g., Skylake-Client, EPYC, which emulate specific processor generations

Why Does the Default Hurt Performance?

Modern software is compiled with optimizations that assume certain CPU features are available. For example, many Linux distributions now require SSE4.2 for their prebuilt packages. If your VM uses kvm64, the guest kernel may fall back to slower generic code paths. In practice, you might see:

Slower cryptography (no AES-NI means software AES)
Reduced media encoding/decoding performance (no AVX)
Incompatibility with some modern guest OSes (e.g., Windows 11 requires SSE4.2 and other features)
Higher CPU usage for the same workload

For a database server or a video transcoding VM, the difference can be 20-50% in throughput. For a simple web server, it might be negligible. But why leave performance on the table?

How to Choose the Right CPU Type

In the Proxmox web interface, go to your VM’s Hardware tab, select Processors, and click Edit. Under Type, you can select from a dropdown. The most common choices are:

host – Best performance, but the VM will only run on hosts with the same or newer CPU features. If you migrate the VM to a host with an older CPU, it may fail to start.
kvm64 – Maximum compatibility, lowest performance. Good for VMs that must run on any cluster node, regardless of CPU generation.
Specific models (e.g., EPYC, Skylake-Client) – These offer a middle ground: they expose a fixed set of features, so the VM can migrate between hosts that support at least that feature set, but you lose features your CPU might have.

For a single-host setup or a cluster where all nodes have identical CPUs, host is almost always the best choice. For a heterogeneous cluster, you need to decide between compatibility and performance.

Live Migration and CPU Compatibility

One of the main reasons Proxmox defaults to kvm64 is to allow live migration between hosts with different CPUs. If you use host, the VM’s CPU definition includes all the features of the source host. If you try to migrate to a host with an older CPU, the target host may not support those features, and the migration will fail.

To enable live migration while still getting better performance than kvm64, you can use a named model that represents the oldest CPU in your cluster. For example, if you have a mix of Intel Haswell and newer, choose Haswell-noTSX or similar. This gives you a fixed feature set that all hosts support, but still includes modern instructions like AVX2.

Another option is to enable NUMA and CPU hotplug if your workload needs them, but those are separate settings.

Common Problems and Misconceptions

Problem: Windows VM won’t boot after changing CPU type. Windows is very sensitive to CPU changes. If you switch from kvm64 to host on an existing Windows VM, it may blue-screen. The fix is to change the CPU type before installing Windows, or to back up the VM first and be prepared to restore if it fails.

Misconception: “host” is unsafe. Some users worry that passing through all CPU features could cause instability. In practice, it is safe for most workloads. The only risk is migration incompatibility, not security. The guest sees the same CPU features as the host, which is fine.

Misconception: “kvm64” is required for compatibility. While it is the most compatible, most modern OSes will run fine with a named model like Skylake-Client or even host. Only very old or exotic guest OSes might have issues.

Performance Comparison and Benchmarks

To illustrate the impact, consider a simple CPU benchmark like openssl speed or 7zip benchmark. On a modern Intel Xeon, a VM with host will show nearly native performance. With kvm64, you might see a 30-50% drop in AES encryption throughput because AES-NI is not available. Similarly, video encoding with x264 will be slower without AVX2.

Here’s a rough idea of what changes:

kvm64: No SSE4.2, no AVX, no AES-NI, no POPCNT
host: Everything your CPU has, e.g., AVX-512 on server CPUs, or at least AVX2 on modern desktops
Named models: Varies; e.g., EPYC includes SSE4.2, AVX2, but not AVX-512

For most workloads, the difference is noticeable but not critical. For compute-intensive tasks, it can be the difference between a VM that feels sluggish and one that runs at native speed.

How to Change the CPU Type Safely

If you want to switch an existing VM from kvm64 to host, follow these steps:

Back up the VM (or at least the VM configuration and disk).
Shut down the VM.
Go to Hardware > Processors > Edit.
Change the Type to host.
Start the VM. If it fails, restore the backup and try a named model instead.

For Linux guests, you can verify the CPU flags with grep flags /proc/cpuinfo inside the VM. You should see the same flags as the host if you used host.

Frequently Asked Questions

Does changing CPU type affect VM performance?

Yes, significantly for some workloads. Using host instead of kvm64 can improve performance by 20-50% for CPU-intensive tasks like encryption, video encoding, and scientific computing. For light workloads, the difference is minimal.

Can I migrate a VM with CPU type “host” to another host?

Only if the target host has the same or newer CPU features. If the target CPU is older, migration will fail. To allow migration between different CPUs, use a named model that represents the oldest CPU in your cluster.

Is it safe to use “host” for production VMs?

Yes, it is safe in terms of stability. The guest sees the same CPU features as the host, which is fine. The only risk is migration incompatibility, so plan accordingly.

Why does Proxmox default to kvm64?

For maximum compatibility. It allows VMs to run on any x86-64 host and to migrate between hosts with different CPUs. It is a conservative choice that prioritizes compatibility over performance.

What is the best CPU type for a Windows VM?

For Windows 10/11, use host if the VM will not migrate to a different CPU. If you need migration, choose a named model that supports all required features (e.g., Skylake-Client for most modern Intel). Windows 11 requires SSE4.2, so kvm64 will not work.

Does the CPU type affect live migration?

Yes. kvm64 allows migration to any host. host only allows migration to hosts with the same or newer CPU. Named models allow migration to hosts that support at least that feature set.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →