外观
CPU 类型、自定义 CPU 模型与嵌套虚拟化
创建第一个虚拟机里建议单机环境直接用 host。这篇把 CPU Type 这个选项完整展开:内置类型怎么选、集群环境为什么不能都用 host、自定义 CPU 模型解决什么问题,以及怎么开嵌套虚拟化。
为什么需要弄清楚这个选项
CPU Type 决定了 QEMU 告诉客户机自己有哪些指令集特性。选得越接近宿主机真实 CPU,性能越好;但客户机因此"认定"了这些特性存在,迁移到不具备这些特性的节点会直接迁移失败或者到了新节点无法启动。这是一个性能和可迁移性之间的权衡,单机环境和集群环境的正确答案不一样。
开始之前
- 已读创建第一个虚拟机的 CPU 一节。
- 如果是集群环境,先确认每个节点的 CPU 型号(
lscpu或节点 → Summary),型号差异越大,能共用的 CPU Type 就越保守。
内置 CPU 类型怎么选
默认值:kvm64 与 x86-64-v2-AES
后端默认是 kvm64(等价 x86-64-v1),几乎任何 x86_64 宿主机都能跑,但性能保守。Web UI 新建虚拟机时的默认值是 x86-64-v2-AES,需要 Intel Westmere 或 AMD 第四代 Opteron 以上的 CPU。
QEMU 虚拟等级
| 类型 | 最低要求(Intel / AMD) | 相对上一级新增 |
|---|---|---|
kvm64(x86-64-v1) | Pentium 4 / Phenom | 基线 |
x86-64-v2 | Nehalem / Opteron_G3 | cx16、popcnt、sse4.1/4.2 等 |
x86-64-v2-AES | Westmere / Opteron_G4 | +aes |
x86-64-v3 | Haswell / EPYC | avx、avx2、fma 等 |
x86-64-v4 | Skylake-X / EPYC Genoa | avx512 系列 |
host:性能最好,但绑死硬件
host 把宿主机 CPU 的全部指令集原样透传给客户机。
什么时候用 host
单机环境,或者集群里所有节点 CPU 型号完全一致(含微码版本),直接用 host,没有理由不用。
集群里 CPU 型号不同时不要都用 host
用 host 的虚拟机只能迁移到指令集至少一样多的节点上。混用不同代 CPU 的集群里,用 host 的虚拟机实际上被焊死在了某几个节点,官方文档原话是"如果客户机被传递的 CPU 标志缺失,QEMU 进程会直接停止"。
混合 Intel / AMD 的集群,两者之间的在线迁移不保证能成功,即使都选了通用类型。
集群环境的选择原则
- 全 Intel 或全 AMD 的集群:选集群里最老那代 CPU 对应的类型(参考上面的表)。
- Intel / AMD 混合的集群:选双方都满足的最低 QEMU 虚拟等级,通常是
x86-64-v2或更低。 - 不确定就先用默认的
x86-64-v2-AES,出现迁移报「缺少 CPU 标志」的错误再往下调。
自定义 CPU 模型(PVE 9.2 起有图形界面)
自定义 CPU 模型解决的问题:内置类型是固定组合,但你可能想要「基本盘用某个通用类型,只额外加一两个标志」——比如集群大多数节点是 Haswell,但都支持 AES,你想要 x86-64-v3 的性能又要保留 aes。
8.x 也能用,只是要手改配置文件
自定义 CPU 模型本身不是新功能,配置文件是 /etc/pve/virtual-guest/cpu-models.conf。PVE 9.2 新增的是图形界面:数据中心 → Custom CPU Models,之前只能手写这个文件。
用 Web UI 创建
数据中心 → Custom CPU Models → Add:
| 字段 | 说明 |
|---|---|
| Name | 模型名,虚拟机里引用时要写成 custom-<name> |
| Base Model | 从哪个内置类型开始 |
| Flags | 逐条勾选启用(+flag)或禁用(-flag),界面会标出集群里哪些节点支持这个标志 |
创建后在虚拟机的 CPU Type 里选 custom-<name> 即可使用。
权限
自定义 CPU 模型走独立的 ACL 路径 /mapping/cpu/<name>:
| 权限 | 作用 |
|---|---|
Mapping.Audit | 能看到这个模型 |
Mapping.Modify | 能创建、修改、删除 |
Mapping.Use | 能在创建/修改/克隆虚拟机时选用它 |
多用户环境下,普通用户默认不一定有 Mapping.Use,遇到"选不到自定义模型"先检查这个。
嵌套虚拟化
嵌套虚拟化指的是在虚拟机里面再跑一层虚拟化(比如虚拟机里装 KVM 或者跑某些需要虚拟化扩展的软件)。
用 host 类型时通常已经打开
用 host 类型时,虚拟机能不能用嵌套虚拟化,取决于宿主机内核参数:
sh
# 在宿主机 shell 执行,确认嵌套虚拟化内核参数状态
cat /sys/module/kvm_intel/parameters/nested # Intel
cat /sys/module/kvm_amd/parameters/nested # AMD输出 Y 或 1 表示已开启。没开可以在 /etc/modprobe.d/ 里加对应参数并重新加载模块,这属于宿主机内核调优,改动前确认这台机器没有对内核参数有特殊要求的其他负载。
自定义 CPU 模型的细粒度控制(PVE 9.1 起)
自定义 CPU 模型的 Flags 里有一个特殊的 nested-virt 简写,专门控制嵌套虚拟化(对应 Intel 的 vmx 或 AMD 的 svm),不需要再单独拼 +vmx / +svm。这让你可以做一个"基本盘 + 开启嵌套虚拟化"的自定义模型,而不必用 host 把整颗 CPU 都透传出去。
检查结果
- 客户机内部确认拿到了预期的标志:
sh
# 在虚拟机内部执行(Linux)
lscpu | grep Flags- 迁移前先在测试虚拟机上跑一次迁移,确认目标节点不报「CPU 标志缺失」。
- 需要嵌套虚拟化的场景,进客户机确认虚拟化扩展可见:
sh
# 在虚拟机内部执行
grep -E 'vmx|svm' /proc/cpuinfo能看到对应标志,说明这层虚拟化标志已经透传进来了;能不能真正跑起来内层虚拟机还要看内层软件本身的要求。
常见问题
迁移报错「the CPU flags passed to the guest are missing」。 目标节点的 CPU 不具备源节点透传的某个标志,通常是用了 host 或标志要求过高的自定义模型。降级到集群里通用的类型。
Windows 用 host 或 max 类型时启动失败(尤其新款 Intel CPU)。 官方文档提到可以在 cpu 选项的 flags 里加 level=30 绕开 Hyper-V 相关的启动问题。
选不到刚建的自定义 CPU 模型。 检查当前用户在 /mapping/cpu/<name> 路径下有没有 Mapping.Use 权限。
要不要为了安全把 Spectre/Meltdown 缓解标志关掉换性能。 不建议。pcid、spec-ctrl、ssbd(Intel)和 ibpb、virt-ssbd、amd-ssbd(AMD)这类标志是安全缓解措施,关掉换来的性能提升通常不值得承担的风险,这类判断以官方文档和你的威胁模型为准,不在这里给统一结论。