Technical Guide · Servers and Virtualization
VM CPU Compatibility: A Shared Feature Set for Live Migration
The vCPU model determines instructions visible to the guest. Migration may fail if an exposed feature such as AVX is absent on the destination. Matching vendor or core count does not…
Technical review:
Architecture and operating model
The vCPU model determines instructions visible to the guest. Migration may fail if an exposed feature such as AVX is absent on the destination. Matching vendor or core count does not prove compatibility.
Host-passthrough exposes features close to the source CPU and constrains migration across heterogeneous hosts. Test shared models alongside BIOS/microcode, QEMU and libvirt versions. Disabling features can change performance or security capabilities.
Do not assume editing VM XML changes the running CPU model. A guest restart and platform-supported transition may be required. Pilot bidirectional migration and rollback across all hosts.
- 1Host features
- 2Shared CPU model
- 3Guest features
- 4Destination compatibility test
Design parameters
- Baseline model
- Find a common feature set across supported hosts without unnecessarily restricting new hardware.
- Version matrix
- Record CPU, firmware, microcode, hypervisor and guest versions in one matrix.
- Workload measurement
- Measure shared-model impact on cryptographic and vectorized applications.
Worked example
If two of three hosts support AVX2 and one does not, do not migrate an AVX2-exposing VM to the third. Use separate pools or a shared model. A workload changing from 8 to 10 seconds has a 25% time increase; reflect this in capacity planning.
Example commands: replace lab values and confirm permissions and software versions before use.
virsh capabilities
virsh domcapabilities
virsh dumpxml lab-vm
# Compare host CPU descriptions with the commands supported by your libvirt release.Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| CPU incompatible | Guest exposes an unsupported destination feature. | Compare domain XML and both capability reports. |
| Application slower after migration | Model, NUMA or microcode differences. | Compare latency/CPU counters on the same data and load. |
Acceptance checks
- Retain capability reports for every host.
- Test migration in both directions.
- Inspect guest-visible instructions.
- Plan any required restart.
- Compare workload performance.
- Verify the rollback pool.
Related concepts
NUMA locality
On NUMA systems a processor may access nearby and remote-node memory at different costs. VM vCPU and memory sizes must be assessed against physical node capacity and hypervisor placement. More vCPUs do not always improve performance: reduced locality and scheduling waits can make it worse. Record physical topology, topology exposed to the guest and the workload’s memory behaviour together. Compare changes under the same load, using application latency and remote-memory effects rather than CPU percentage alone.
Resource contention
Contention occurs when workloads sharing CPU, memory, storage or a link make each other wait. Apparent spare total capacity can hide a hot core or single-queue bottleneck. Correlate backup jobs, antivirus scans, index maintenance and user traffic on a common timeline. Confirm the bottleneck before adding resources. Run a workload alone and with its usual competitors to separate shared-resource effects, and report peak-hour latency alongside average utilization.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Failover and failback
Failover moves service to another component; failback returns it to the preferred location. Their risks and sequencing may differ. DNS updates, routing, sessions, replication lag and application dependencies determine user interruption. Define failover triggers, false-alarm behaviour and approval for returning service. Simply shutting down a VM does not test every failure type. Measure network, storage and management-plane failures separately.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.