报错“the CPU is incompatible with host CPU”本质是XML中声明的require特性（如spec-ctrl、ssbd）在宿主机CPU flags或cpuid中缺失；需用lscpu、/proc/cpuinfo比对flags，qemu-system-x86_64 -cpu help查支持标识，并通过删减逐项验证定位。
报错 the CPU is incompatible with host CPU 怎么定位具体缺哪个功能
这个错误不是泛泛说“CPU不兼容”，而是 libvirt/QEMU 在启动目标虚拟机时，比对了源虚拟机 XML 中声明的 CPU 特性与当前宿主机实际支持的特性列表，发现某项被要求启用的功能（如 spec-ctrl、ssbd、avx512f）在目标 CPU 的 /sys/devices/system/cpu/cpu0/online 或 cpuid 输出里根本不存在。
排查步骤：
- 在目标宿主机上运行：
lscpu | grep -E "(Flags|CPU family|Model name)"，确认基础架构（x86_64 / aarch64）和型号是否匹配 - 对比源/目标的
cat /proc/cpuinfo | head -20，重点关注flags行，逐项比对（比如源有spec_ctrl，目标没有，就直接对应报错里的关键词） - 用
qemu-system-x86_64 -cpu help查看当前 QEMU 支持哪些 CPU 特性标识（feature flag），有些老版本 QEMU 不识别新 CPU 的 flag 名，也会假报不兼容
virsh migrate 失败后，怎么快速验证 XML 中的 CPU 配置是否适配目标机
别直接重试迁移，先做本地启动验证。把目标宿主机上的虚拟机 XML 拷贝一份，手动删掉 policy="disable" 或干脆去掉整个 virsh define vm.xml && virsh start vm-name。
如果能成功启动，说明问题确实在 CPU feature 约束上；再逐步加回 require 的 feature，每次加一个并测试，就能锁定是哪一个导致失败。注意：某些 feature（如 hypervisor）在非嵌套虚拟化环境里必须禁用，否则必然报错。
为什么 match='exact' 模式迁移总失败，而 match='minimum' 可以
match='exact' 要求目标 CPU 必须提供源 CPU 所有已启用的特性，包括那些可能只是“被 BIOS 启用但 Guest OS 实际没用到”的冗余 flag；而 match='minimum' 只校验最低运行需求（比如基本 SSE、NX、PAE），宽松得多。
真实场景中，建议优先用 match='custom' + 显式白名单：
- 用
virsh edit vm-name修改 CPU 配置，把 - 或更稳妥地：
Skylake-Server Haswell、Westmere），避免依赖具体物理 CPU 的扩展集 - 不要依赖
host-model—— 它会自动推导出源 CPU 最大能力，迁移到弱 CPU 上大概率炸
跨厂商迁移（Intel ↔ AMD）或国产 CPU（Hygon/Kunpeng）时最常忽略的点
指令集只是表层，真正卡住的是微架构行为差异。比如 Intel 的 spec-ctrl 和 AMD 的 stibp 虽然解决同类漏洞，但 flag 名不同、QEMU 解析逻辑也不同；Kunpeng（ARM64）上某些 ACPI 表大小限制、PCIe 设备模拟路径与 x86 完全不通用。
关键动作：
- 迁移前统一用
virsh dumpxml vm-name | grep -A5 "导出两台宿主机上各自生效的 CPU 配置，人工比对 - 禁用所有与安全缓解强相关的 feature（
spec-ctrl、ssbd、stibp），除非业务明确要求开启 - 确认目标宿主机内核已加载对应模块（
kvm_amd或kvm_intel），且/dev/kvm可读写 —— 有些国产系统默认不加载kvm_amd即使 CPU 是 Hygon
复杂点不在命令会不会敲，而在你得知道哪一行 XML 对应哪一条 CPUID 指令返回值。一旦看到报错里带具体 feature 名，立刻去查 cpuid -l 0x80000001 或 grep -i spec_ctrl /proc/cpuinfo，而不是改完 XML 就重试。
