CPU虚拟化支持需同时满足BIOS开启、/proc/cpuinfo含vmx或svm标志、kvm模块加载及/dev/kvm存在；仅lscpu显示VT-x不保证KVM可用，须用kvm-ok完整验证。
检查CPU是否开启虚拟化支持（vmx 或 svm）
Linux下不能只看CPU型号就断定支持虚拟化，必须确认BIOS中已启用，且内核能识别到对应标志位。最直接的方式是查 /proc/cpuinfo 中的 flags 字段。
-
vmx表示 Intel CPU 的 VT-x 支持（需 BIOS 开启 “Intel Virtualization Technology”） -
svm表示 AMD CPU 的 AMD-V 支持（需 BIOS 开启 “SVM Mode” 或 “AMD-V”） - 如果
grep -E "vmx|svm" /proc/cpuinfo无输出，不代表硬件不支持——更可能是 BIOS 里被禁用了 - 注意：某些低功耗 Intel CPU（如部分 J 系列）或老款 Atom 可能压根不支持
vmx，即使 BIOS 开启也查不到
为什么 lscpu 显示 “Virtualization: VT-x” 却跑不了 KVM？
lscpu 的输出只是解析 /proc/cpuinfo，它告诉你“CPU 有这个能力”，但不保证当前可用。常见断点在中间层：
- BIOS 设置未保存或重启后失效（尤其某些 OEM 主板，恢复默认会关掉虚拟化）
- 宿主机运行在 VMware/VirtualBox 等嵌套虚拟环境中，而外层未开启 “Nested VT-x/AMD-V”
- 内核模块没加载：
lsmod | grep kvm应看到kvm_intel或kvm_amd；若没有，尝试modprobe kvm_intel（Intel）或modprobe kvm_amd（AMD） - Secure Boot 有时会阻止
kvm_intel模块加载（报Operation not permitted），可临时禁用测试
快速验证 KVM 是否真正可用（不只是参数存在）
光有 vmx 或 svm 不等于 KVM 就能工作。用最小闭环验证：
- 运行
sudo kvm-ok（需安装cpu-checker包），它会检查标志位 + 模块 + 设备节点（/dev/kvm）三者是否齐备 - 手动检查设备节点：
ls -l /dev/kvm，缺失说明内核模块没加载成功或权限不足 - 如果使用非 root 用户跑 QEMU，还需把用户加入
kvm组：sudo usermod -aG kvm $USER，然后重新登录 - 某些云服务器（如 AWS EC2 t2/t3 实例）虽然 CPU 支持
vmx，但 Hypervisor 层已截获该指令，/dev/kvm不可用 —— 这是平台限制，不是配置问题
遇到 cat /proc/cpuinfo | grep flags 输出过长怎么办？
flags 字段通常包含几十个特性，肉眼扫容易漏。别硬看，用精准匹配：
- 只查 Intel：
grep -m1 flags /proc/cpuinfo | grep -o vmx（有输出即命中） - 只查 AMD：
grep -m1 flags /proc/cpuinfo | grep -o svm - 想同时看所有虚拟化相关标志：
grep -m1 flags /proc/cpuinfo | grep -o -E "(vmx|svm|lm|hypervisor)"（lm是 long mode，64 位必需；hypervisor表示当前已在虚拟机中） - 注意：
grep -m1防止多核重复输出干扰判断，因为每个逻辑 CPU 都有一段flags
真正卡住的地方往往不是“有没有 vmx/svm”，而是 BIOS 设置、模块加载顺序、设备节点权限、或运行环境本身不允许多层虚拟化——这些比查参数难定位得多。
