Choose the virtual CPU policy before relying on KVM live migration between hosts. A guest must not suddenly lose processor features it was using. CPU compatibility involves hardware, microcode, QEMU and the configured model, not merely the number of virtual cores.
IN THIS ARTICLE
Information to have ready
Inventory all candidate hosts and their supported domain capabilities. Identify architecture, processor vendor/generation, microcode and virtualization software versions. Back up the guest definition and define the migration destinations that must remain supported.
01 Choose a compatible CPU mode for KVM migration
- Inspect the guest CPU mode in its domain definition and compare host domain capabilities. Use the management platform's supported CPU controls when it owns the VM.
- Understand the tradeoff: host-passthrough closely exposes the host and requires very closely matching hosts for safe migration; host-model chooses an approximated supported host model; a deliberate custom baseline can target a compatible fleet.
- Determine a common model using supported libvirt capability/baseline tooling and the actual destination set. Do not select a model solely because its name sounds older or more compatible.
- Apply the planned CPU policy during the required guest shutdown window. CPU changes may require a cold restart and can affect guest licensing or software feature selection.
- Test migration of a representative disposable guest in both directions. Include a subsequent cold boot on each destination, since the CPU exposed after a new start can differ from an already-migrated running instance.
Is host-model always safe across all servers?
No. The chosen model still depends on source capabilities and destination support. Test the actual hosts and guest definition rather than treating the mode name as a universal compatibility guarantee.
Confirm the expected result
Confirm the guest sees the expected features and applications start correctly on every supported host. Validate migration prechecks and retain the tested fleet/software combination in the change record. Reassess compatibility after host firmware or hypervisor updates.
Troubleshoot unexpected results
If migration rejects the CPU, identify the missing feature and stop before forcing it. A migratable setting is not proof that different hosts are interchangeable. Do not remove features from a running production guest or assume the destination will emulate every missing capability.