Why does live migration fail between nodes with different CPUs?

A running VM is told which CPU features it can use when it boots. If you live-migrate it to a node whose CPU lacks one of those features, the guest is suddenly missing an instruction it was promised, and the QEMU process stops to avoid corruption. Migration between identical CPUs is fine; the trouble starts the moment the target is different or older.

What is the safest CPU type for a mixed Proxmox cluster?

The newest CPU model that every node in the cluster can support. Proxmox ships x86-64-v2, v3, and v4 baseline models for exactly this; you pick the highest level all your hardware meets. That gives modern instructions for performance while keeping the VM migratable everywhere, unlike host (fast but pinned) or ancient kvm64 (migratable but slow).

What is new about custom CPU models in Proxmox VE 9.2?

Proxmox VE 9.2 adds a web interface to create, edit, and remove custom CPU models under Datacenter, and a flag selector that shows which CPU flags are supported across all of your cluster nodes at once. That cross-node visibility turns building a safe common CPU from guesswork into a deliberate choice you can see.

What is the difference between host, kvm64, and x86-64-v3?

host passes your physical CPU straight through for maximum performance, but a VM using it can only migrate to identical hardware. kvm64 is a tiny, ancient baseline that migrates anywhere but leaves modern performance on the table. x86-64-v2/v3/v4 are standardized modern baselines that let you choose how new a feature set to require while staying migratable across matching nodes.

Do I need to reboot a VM to change its CPU type?

Yes. The CPU type a guest sees is decided at boot, so changing it takes effect only after the VM is fully powered off and started again, not on a reboot from inside the guest. Plan a short stop for any VM you re-type, and change new VMs' CPU type before you build fleets on top of them.

Proxmox VE 9.2 Custom CPU Models for Live Migration

On this page

The three-way tradeoff you’re actually making
Find your common denominator with the 9.2 flag selector
The mental model, in one ladder
That’s the flagship run

Here’s a failure that feels like a betrayal the first time it happens. You’ve got a healthy cluster, live migration works beautifully, and you’ve set your VMs to CPU type host because — why wouldn’t you? — you want full performance. Then you add one new node with a different processor, migrate a VM onto it, and the VM dies mid-flight. Not a warning. The QEMU process just stops, because the guest was promised CPU features the new node doesn’t have.

I run four nodes that happen to be identical today (all AMD Ryzen 5 PRO 2400G), so mine migrate fine — but “identical forever” is not a plan, it’s a countdown. The day you add a newer Ryzen, an Intel box, or a bargain mini-PC, host turns into a trap. Proxmox VE 9.2 gives this a proper fix: a GUI to build custom CPU models, and — the genuinely new bit — a flag selector that shows you what every node in the cluster supports at once, so you can pick a safe common CPU on purpose instead of by trial and error.

First: make these values your own

The CPU models named here (like x86-64-v3) depend on your hardware — pick the level your own nodes actually support, which the 9.2 flag selector shows you. Any custom model name is yours to choose. If a value looks specific to one machine, it’s a placeholder to change, not a literal to copy.

The three-way tradeoff you’re actually making

Every VM’s CPU type is a choice among three bad-if-you-pick-wrong options:

host — passes your physical CPU straight through. Fastest possible, and completely fine until you try to migrate to a different or older chip, at which point it’s a brick wall. Great for a single node; a liability the moment your cluster isn’t uniform.
kvm64 / qemu64 — a tiny, ancient baseline that runs and migrates literally anywhere, at the cost of leaving a decade of CPU performance (AVX, AES acceleration, and more) switched off.
x86-64-v2 / v3 / v4 — the sane middle. These are standardized microarchitecture levels, agreed in 2020 by AMD, Intel, Red Hat, and SUSE, that bundle progressively more modern instructions. You pick the highest level every node in your cluster supports, and get modern performance while staying migratable. (Proxmox even defaults new VMs to x86-64-v2-AES for this reason.)

The whole game is finding your cluster’s newest common denominator. That used to be guesswork. In 9.2 it’s a screen you can read.

Find your common denominator with the 9.2 flag selector

1Open the custom CPU model editor2 min

Go to Datacenter → Custom CPU Models and add one. The 9.2 dialog embeds a flag editor grid with free-text search over flag names, an accelerator (kvm/tcg) selector, and — the star of the show — a per-node multi-select that shows which flags are supported across the nodes you choose. That cross-node view is exactly what you need: it makes the flags not shared by every node visible, so you don’t promise a guest something a node can’t deliver.

2Sanity-check from the shell too3 min

You can corroborate the GUI from a node. A quick read-only check tells you which microarchitecture level a node meets — handy when deciding between v2, v3, and v4:

Which x86-64 level does this node support? (read-only)


/lib64/ld-linux-x86-64.so.2 --help | grep 'x86-64-v'
# real output on my node:
#   x86-64-v2 (supported, searched)
#   x86-64-v3 (supported, searched)     <- v3 is the ceiling; no v4 line

# and the raw flags:
grep -m1 flags /proc/cpuinfo

On my cluster every node is an AMD Ryzen 5 PRO 2400G, which supports up through x86-64-v3 (it has AVX2) but not v4 — so v3 is the ceiling I’d standardize on if I added a non-identical node.

3Apply it to a VM and migrate5 min

Either set the VM’s CPU type directly to the common baseline (e.g. x86-64-v3), or reference your custom model as custom-<name> in the VM’s CPU setting. Then do the thing this was all for: live-migrate the VM between two unlike nodes and watch it succeed where a host-typed VM would have stopped.

Changing CPU type needs a real power cycle

The CPU a guest sees is fixed at boot, so re-typing a running VM only takes effect after a full stop and start — not a reboot from inside the guest. Set the type before you build fleets on top of a VM, and budget a brief stop for anything you re-type after the fact.

The mental model, in one ladder

That’s the flagship run

Five builds, each one a genuine gap when I went looking: a load-balanced local-AI endpoint, a read-only way to let an AI see your homelab, self-healing routed networking, object-storage backups you own, and now cross-CPU live migration. If you build only one, build the one that removes a fear you actually have — that’s what a homelab is for.

Related posts:

PBS 4.2 Backups to Self-Hosted MinIO — the previous flagship.
Load-Balance a Multi-Node Ollama Cluster With Olla — where the flagship run began.
Proxmox VE 9.2 SDN Fabrics — the other big 9.2 feature in this set.
Create Your First Proxmox VM — where the CPU type is chosen.
Build a 4-Node Proxmox Cluster on HP EliteDesk Mini PCs — the kind of cluster that grows mixed over time.
Proxmox VM vs LXC: When to Use Each — the workloads you’re migrating.
Build a Read-Only Homelab MCP Server — ask an AI whether your migration actually balanced the cluster.

Comments

Comments are powered by GitHub Discussions — sign in with a GitHub account to join the conversation.