How to Choose the Right CPU Type for a VM in Proxmox VE (host vs kvm64 vs x86-64-v2-AES)

Introduction

Create a new VM in Proxmox VE and you'll hit a dropdown labeled Type on the Processors screen, sitting quietly next to Sockets and Cores. Most people click past it, leave whatever's selected by default, and move on to picking an ISO. That's fine for a lot of homelabs. But if you've ever tried to live-migrate a VM to another node and had it fail with a cryptic error, or installed Windows and watched it demand reactivation after a routine host update, the CPU Type setting is very likely the reason why.

This one dropdown decides which CPU instruction set your virtual machine believes it's running on. Get it wrong and you either leave real performance on the table, or you paint yourself into a corner where the VM can't move to different hardware without a reboot. Get it right and you never think about it again.

What You Will Learn

• What the CPU Type field actually controls inside a VM
• The difference between host, kvm64, and the x86-64-vN family of virtual CPU types
• Why Proxmox ships two different defaults depending on whether you use the GUI or the API
• How to check and change the CPU type on an existing VM, from the GUI and the shell
• Why live migration and Windows guests care so much about this setting
• Common errors and how to work through them

What Is This Feature?

Every physical CPU exposes a set of "flags" — think of them as a list of tricks the chip knows how to do. AES-NI for fast encryption, AVX2 for vectorized math, and dozens of smaller ones most software never touches directly but that compilers and libraries quietly rely on. When Proxmox boots a VM, QEMU has to decide which of the host's real flags to pass through to the guest, and which ones to hide or emulate.

That decision is the CPU Type. It's not about how many cores or how much RAM the VM gets — that's a separate setting entirely. CPU Type controls the instruction set the guest operating system sees when it asks the virtual chip "what can you do?"

Proxmox gives you three broad categories to pick from:

Category	Example	What it means
Named physical model	Skylake-Client, EPYC, Icelake-Server	Emulates a specific real CPU generation's flag set, regardless of what the host actually is
Virtual QEMU type	kvm64, x86-64-v2-AES, x86-64-v3	A generic baseline compatible with a wide range of real CPUs, chosen by minimum supported hardware generation
host	host	Passes through every flag your physical host CPU has, with nothing hidden

The x86-64-vN family is worth knowing by name because you'll see it constantly in Proxmox 8.x and 9.x. It's a standardized tiering system, not a Proxmox invention:

• kvm64 (informally x86-64-v1) — works on essentially anything, Intel Pentium 4 or AMD Phenom and newer
• x86-64-v2 — needs Intel Nehalem or AMD Opteron_G3 or newer
• x86-64-v2-AES — same as v2 plus the AES-NI flag, needs Intel Westmere or AMD Opteron_G4 or newer
• x86-64-v3 — needs Intel Haswell or AMD EPYC or newer, adds AVX2 and other newer math instructions
• x86-64-v4 — needs Intel Skylake-Server or AMD EPYC Genoa or newer, adds AVX-512

Each tier is a strict superset of the one below it. A VM set to x86-64-v3 will refuse to start on a host CPU too old to provide those flags — QEMU won't fake instructions that don't exist in silicon.

Why Would You Use It?

There are really two competing goals here, and the whole setting exists because you usually can't max out both at once.

Performance wants host. Setting the type to host tells QEMU "don't hide anything, give the guest every flag you've got." For CPU-heavy workloads — video transcoding, compilation, anything doing bulk math — this can matter. A guest running kvm64 can't use AVX2 even if the physical chip supports it, because kvm64 doesn't advertise that flag exists.

Portability wants the opposite. A VM configured as host is tied to that exact CPU's flag set. Try to live-migrate it to a node with an older or simply different processor and QEMU can refuse outright, or in the worse case the migration succeeds but the guest OS crashes the moment it hits an instruction the new host can't actually execute. This is why Proxmox's own documentation is blunt about it: live migration between Intel and AMD hosts has no guarantee of working, full stop, regardless of type.

There's a third wrinkle specific to Windows. Recent Windows 11 VMs with virtualization-based security enabled have known boot problems when the CPU type is host or max on certain Intel hosts, because two security-related flags — cet-ibt and cet-ss — end up in a state Windows doesn't handle well during boot. Proxmox actually disables those two flags by default on Windows 11 machine types for exactly this reason. If you still hit boot failures, the documented workaround is setting level=30 on the CPU config, which papers over a related Hyper-V enlightenment issue.

So the honest answer to "which should I use" is: it depends on whether this VM will ever need to move. A single-node homelab with no migration plans? Just use host and get the performance. A cluster where VMs bounce between nodes for maintenance or HA? Pick the lowest virtual CPU tier your oldest node supports, and keep it consistent across every node.

Prerequisites

• A Proxmox VE host on 8.x or 9.x — the CPU type mechanics are the same on both
• At least one existing VM, or plans to create one
• Root shell access, or a user with VM.Config.HWType permission if you're not using the root account
• If you're planning to use host type in a cluster, know the CPU model of every node you might migrate to

Step-by-Step Tutorial

Check what your host CPU actually supports

Before picking a type, it helps to know what you're working with. From the Proxmox host shell:

lscpu | grep "Model name"
cat /proc/cpuinfo | grep flags | head -1

lscpu gives you the chip's name and generation. The flags line is a wall of text, but you can grep it for anything specific — grep -o avx2 /proc/cpuinfo | head -1 will tell you whether AVX2 is present at all, for instance.

Setting the CPU type on a new VM

In the VM creation wizard, the Processors step has a Type dropdown. The GUI's own default here is x86-64-v2-AES, not kvm64 — worth knowing, since the backend's own internal default if you skip the field entirely (say, scripting VM creation via the API) is actually the older kvm64. The two defaults are different depending on how you create the VM, which trips people up more than it should.

Changing the type on an existing VM — GUI

1. Select the VM in the left-hand tree.
2. Go to Hardware.
3. Click Processors, then Edit.
4. Open the Type dropdown and pick your new value.
5. Click OK.

This writes the change to the VM's config file immediately, but like most hardware changes, it only takes effect the next time the VM's QEMU process actually starts. A guest-side reboot isn't enough — shut the VM down fully, then start it again.

Changing the type from the shell

Find the VM ID first if you don't already know it:

qm list

Then set the type:

qm set 101 --cpu host

Or for a specific virtual tier:

qm set 101 --cpu x86-64-v2-AES

Confirm it saved correctly:

qm config 101 | grep cpu

Stop and start the VM for it to actually apply:

qm stop 101
qm start 101

Verifying the guest actually sees the new flags

Once the VM is back up, log into the guest and check. On Linux:

cat /proc/cpuinfo | grep flags | head -1
lscpu | grep Model

On Windows, open PowerShell and run Get-CimInstance Win32_Processor | Select-Object Name, or just check Task Manager's Performance tab — it usually shows the emulated model name directly.

Setting a consistent type across a cluster

If you run more than one node and want VMs to migrate freely, pick one virtual type — usually the highest v-tier your oldest node's CPU supports — and apply it to every VM you intend to move. There's no cluster-wide default setting for this in Proxmox; it's tracked per VM, so consistency here is a manual discipline, not something the platform enforces for you.

Commands Explained

Command	What it does
qm list	Lists every VM on the host with its ID and current status
qm set <vmid> --cpu <type>	Sets the CPU type for a VM, written to its config file immediately
qm config <vmid>	Prints the VM's full configuration, useful for confirming what's actually saved
qm stop <vmid> / qm start <vmid>	Fully restarts the QEMU process so hardware changes like CPU type take effect
lscpu	Shows the CPU's model name, architecture, and topology on whichever machine you run it — host or guest

Common Errors

"kvm: Host doesn't support requested features" or the VM simply refuses to start — you picked a virtual type (say, x86-64-v3) that needs flags your physical CPU doesn't have. Drop down a tier, or check lscpu against the compatibility table above.

Live migration fails with a CPU-related error — the destination node's CPU can't provide every flag the VM's current type demands. This is the classic symptom of using host type in a cluster with mismatched hardware. Switch the VM to a virtual type both nodes can satisfy.

Windows 11 VM hangs or blue-screens on boot after switching to host or max — almost certainly the cet-ibt/cet-ss issue on recent Intel hosts. Try setting level=30 alongside the CPU type, or fall back to a named model like Skylake-Client instead of host.

Windows demands reactivation after a host change — Windows licensing partly keys off perceived hardware identity, and a CPU type change is a big enough shift that it can trigger this. It's usually a one-time nuisance, not a sign anything's actually broken.

Troubleshooting

Start by confirming what's actually configured versus what the guest reports:

qm config 101 | grep cpu

If that matches what you expect but the guest's behavior doesn't, the VM almost certainly hasn't been fully restarted since the change — a soft reboot from inside the guest OS doesn't relaunch the QEMU process, so the old flag set is still what's running.

If you're chasing a migration failure specifically, check the task log on the source node for the exact error, then compare lscpu output between source and destination hosts. Nine times out of ten the mismatch is obvious once you put the two side by side — an AVX2 flag present on one and missing on the other, for example.

For Windows boot issues after a CPU type change, check the VM's machine type too (Hardware > Machine). Older Windows guests created on an early machine-type version sometimes carry over defaults that don't play well with newer CPU emulation — updating the machine type alongside the CPU type occasionally clears up problems that look like a CPU issue but aren't.

Best Practices

• Single-node homelab, no migration plans? Use host and take the performance.
• Multi-node cluster with VMs that migrate? Standardize on one virtual type across every VM that needs to move, based on your oldest node's CPU.
• Never mix Intel and AMD hosts in a cluster and expect host-typed VMs to migrate between them — it's not officially guaranteed to work, and in practice it usually doesn't.
• Check qm config after any CPU type change instead of trusting the GUI form alone — it takes two seconds and rules out a whole category of "why isn't this working" later.
• For Windows guests on new Intel hardware, don't assume host is safe by default — test a boot before committing a production VM to it.

Frequently Asked Questions

Does changing CPU type affect my VM's disk or data?

No. This only changes what QEMU tells the guest about the virtual chip. Your disks, snapshots, and data are untouched.

Which type should I pick if I'm not sure?

x86-64-v2-AES, the GUI's own default, is a reasonable middle ground for most modern hardware from the last decade or so. Move up to host only once you've confirmed you don't need to migrate that VM.

Can I change the type on a running VM without downtime?

You can save the change while it's running, but it won't apply until the VM is stopped and started again. CPU type isn't a hotplug-capable setting.

What does "max" do, and is it different from "host"?

max exposes every flag QEMU itself knows how to emulate, which can occasionally include flags the physical host doesn't actually have, depending on QEMU version. host is generally the safer, more predictable choice for passthrough performance.

Do LXC containers have this same setting?

No. LXC containers share the host kernel directly rather than emulating a CPU, so there's no equivalent Type field — a container always sees the real host CPU's flags.

Conclusion

The CPU Type dropdown looks like a minor detail next to Sockets and Cores, but it's really a tradeoff between raw performance and the freedom to move a VM later without drama. Pick host when a VM is staying put and you want every flag the silicon offers. Pick a matched virtual tier — and keep it consistent across your cluster's nodes — when migration matters more than squeezing out the last bit of throughput. Either way, qm config will always tell you exactly what's currently applied, so when something doesn't add up, that's the first place to look.