企业官网建设流程全解析

• 虚拟化
• 开发工具
• 云原生

Multipass 在 Windows 上默认使用 Hyper-V 驱动（仅限 Windows Pro/Enterprise/Education 版本）来编排 Ubuntu 实例。当 Windows 以客户机形式运行在 Linux 宿主机上的 QEMU/libvirt 环境里时，QEMU 默认不会向该客户机暴露 Hyper-V 所需的虚拟化特性，导致 Multipass 无法正常工作。本文基于仓库中的 dev-docs/running-multipass-on-a-windows-libvirt-qemu-guest.md，完整梳理"宿主 KVM 嵌套虚拟化 → QEMU/libvirt 特性透传 → 客户机启用 Hyper-V"三层配置链路，并结合 Multipass QEMU 后端源码印证底层原理，帮助你在虚拟化嵌套场景下把 Multipass 跑起来。

注意：原始文档写于 2020 年，部分细节可能随 QEMU、内核与 Windows 版本演进而过时，请在当前环境下验证。

背景：为什么 QEMU 客户机里的 Hyper-V 不可用

在 Linux 宿主机上通过 QEMU/libvirt 运行 Windows 客户机时，客户机默认不会暴露 Windows 启用 Hyper-V 所需的特性。而 Multipass 的 Windows 原生后端正是基于 Hyper-V 的（对应源码目录 src/platform/backends/hyperv_api），因此要让 Multipass 在这台 Windows 客户机里正常工作，必须先满足 Hyper-V 的运行前提。

要让 Hyper-V 在 Windows Pro / Enterprise / Education（Home 版本不支持）客户机中启用，需要同时满足三个条件：

1. 宿主必须开启嵌套虚拟化（nested virtualization）；
2. 宿主必须把相关 CPU 特性暴露给客户机；
3. 客户机内必须启用虚拟化功能。

三者缺一不可，下面逐一展开。

宿主配置：为 KVM 开启嵌套虚拟化

Intel 处理器从 Haswell 系列开始支持嵌套虚拟化，部分 AMD 处理器同样支持。第一步是在 KVM 层面开启嵌套。

Intel：kvm-intel 模块参数

嵌套能力通过kvm-intel内核模块启用，需要打开nested与ept（Extended Page Tables，扩展页表）两个选项。这两个选项默认已启用；若未启用，可在引导时通过配置文件强制开启。创建/etc/modprobe.d/kvm-nested.conf并写入：

options kvm-intel nested=1 options kvm-intel ept=1

原始文档还建议一并开启enable_shadow_vmcs与enable_apicv。这两个选项并非必需，但可能对某些场景很重要；由于作者当时的 Broadwell 处理器不支持它们，未经实测，建议在较新硬件上验证。

AMD：kvm-amd 模块参数

AMD 平台的操作流程与 Intel 类似，使用kvm-amd模块，同样有nested选项。与 Intelept对应的 AMD 术语是npt（Nested Page Tables，嵌套页表，又称 Rapid Virtualization Indexing / RVI）。与 Intelenable_apicv对应的是avic选项。而enable_shadow_vmcs在 AMD 上不存在对应项——因为 VMCS shadowing 本质上就是嵌套虚拟化的别名。

原始文档明确注明：关于 AMD 的所有内容均未经作者实测（作者手头没有 AMD 机器），包括kvm-amd模块参数、QEMU 选项以及这些配置能否让客户机里的 Hyper-V 正常工作，都需要在 AMD 硬件上验证。

配置写入后，可用如下方式确认嵌套虚拟化是否生效（命令需在宿主机上以 root 权限执行）：

cat /sys/module/kvm_intel/parameters/nested

输出为Y（或1）表示已开启。

QEMU 配置：向客户机暴露虚拟化特性

在 KVM 层面开启嵌套之后，还需要让 QEMU 把虚拟化特性透传给客户机：

• 在Intel上，必须向客户机暴露vmx特性（表示 CPU 支持 VT-x）；
• 在AMD上，必须暴露svm特性；
• 部分带xsaves的 Intel/AMD 处理器还需要禁用xsaves特性，以规避 Launchpad 上的 QEMU bug #1864536（是否受该 bug 影响可通过virsh capabilities检查）。

配置可通过两条路径完成：libvirt 域 XML，或 QEMU 命令行。

通过 libvirt：修改域 XML 的<cpu>段

在虚拟机 XML 的<cpu>段中加入两行特性声明即可。Intel 示例如下：

<cpu mode="host-model" check="partial"> <feature policy="require" name="vmx"/> <feature policy="disable" name="xsaves"/> </cpu>

其中policy="require"表示该特性必须存在（缺失则拒绝启动），policy="disable"表示强制关闭该特性。AMD 侧改为暴露svm：

<feature policy="require" name="svm"/> <feature policy="disable" name="xsaves"/>

通过 QEMU 命令行

若直接使用命令行启动 QEMU，则在-cpu选项中追加特性标记：

• Intel：必须包含+vmx并追加-xsaves；
• AMD：必须包含+svm，且若处理器支持xsaves同样需要传入-xsaves。

即形如：

-cpu host,+vmx,-xsaves

（AMD 则为-cpu host,+svm,-xsaves。）

这一思路与 Multipass 自身的 QEMU 后端实现相呼应：在 src/platform/backends/qemu/linux/qemu_platform_linux.cpp 中，Multipass 启动实例时固定追加--enable-kvm与-cpu host，即以host模式把宿主 CPU 特性整体透传给 Ubuntu 实例；本文场景则是反过来——把vmx/svm等特性手工暴露给 Windows 客户机，让客户机里的 Hyper-V（进而让 Multipass）得以运行。更完整的 QEMU 启动参数（磁盘、内存、网卡、cloud-init 等）可见 src/platform/backends/qemu/qemu_vm_process_spec.cpp。

客户机配置：在 Windows 中启用 Hyper-V

宿主与 QEMU 层面的配置完成后，还需要在 Windows 客户机内部启用 Hyper-V 功能。启用方法即微软官方文档中描述的通用流程（控制面板 → 启用或关闭 Windows 功能 → 勾选 Hyper-V，或通过 PowerShell 的Enable-WindowsOptionalFeature命令完成），本文不再赘述。启用后重启客户机，Multipass 便可在其中正常调用 Hyper-V 后端。

性能优化思路：手动暴露更多处理器特性

原始文档记录了一个已知现象：开启嵌套后客户机会变慢。原因是部分处理器特性不会被自动暴露，但可以手工透传，例如 SSE 寄存器、AVIC/APICV 等。文档给出的排查方法如下：

1. 分别在宿主机与一个 Linux 客户机内执行：

   cat /proc/cpuinfo | grep flags | grep uniq

2. 对比两份flags列表，找出客户机缺失的特性；

3. 评估手工暴露这些缺失特性后，客户机性能是否有可测的提升。

这套"对比 flags → 手动透传 → 复测"的方法论，同样适用于本文的 Hyper-V 场景：若 Windows 客户机内 Hyper-V 已可运行但性能不理想，可以比照 Intel 的+vmx/-xsaves方式，把缺失且安全的特性逐项加入 libvirt XML 的<feature>列表或-cpu选项，观察对客户机性能的影响。

与 Multipass 生态的关联

理解本文场景有助于更完整地认识 Multipass 的驱动架构：

• Windows 上的默认驱动是 Hyper-V（仅 Windows Pro），Home 版本则使用 VirtualBox。Multipass 一次只运行一个驱动，可通过local.driver设置切换，详见 docs/explanation/driver.md。
• 在 Linux 宿主机上，Multipass 自 1.16 版本起仅提供 QEMU 驱动，其 KVM 加速与-cpu host透传逻辑由 src/platform/backends/qemu/linux/qemu_platform_linux.cpp 承载；Windows 侧的 Hyper-V 后端实现则集中在 src/platform/backends/hyperv_api。
• 因此，本文的完整链路是：Linux 宿主机（Multipass 用 QEMU/KVM 跑 Windows 客户机）→ Windows 客户机（Multipass 用 Hyper-V 跑 Ubuntu 实例）。这是一种"虚拟化套娃"场景，只有把嵌套虚拟化每一层都配置正确，两层 Multipass 才能各自正常工作。

参考资源

原始文档还附有一批可进一步阅读的材料（均为外部资料，此处仅列出主题供按名检索）：

• x86 虚拟化的维基百科条目（X86_virtualization）；
• libvirt 域 XML 格式说明（libvirtformatdomain文档）；
• QEMU 的 Hyper-V enlightenments 文档（qemu/docs/hyperv.txt）——enlightenments 是面向 Windows 客户机优化性能的一组特性，与之相关的社区讨论通常能改善 Windows 客户机在 KVM 中的运行效率；
• 一篇 serverfault 上关于嵌套虚拟化的问答，提出了一个可工作的解决方案。

综合来看，在 Linux 宿主机上让 Multipass 运行于 Windows libvirt/QEMU 客户机内，本质上是打通"宿主 KVM 嵌套 → QEMU 特性透传 → 客户机 Hyper-V 启用"三层配置。按本文顺序依次核对kvm-intel/kvm-amd模块参数、libvirt<cpu>特性声明（或命令行-cpu选项）与 Windows 功能开关，即可完成部署；若追求更好的客户机性能，可进一步沿用"对比 CPU flags、手动透传特性"的优化路径。

• 虚拟化
• 开发工具
• 云原生