微软 OpenVMM 开源项目详解：Rust 编写的跨平台 VMM

2024 年底，微软正式开源了 OpenVMM 项目。下面我们就来梳理它开源以来的发展轨迹，并拆解微软打造该项目的核心动机。

什么是 OpenVMM？

从架构分层来看，一个完整的虚拟化平台通常包含 3 大核心组件：

1. Hypervisor：直接和底层硬件交互的特权软件，为虚拟机运行提供基础的底层执行原语。
2. VMM 虚拟机管理器：调用 Hypervisor 接口，负责提供虚拟机的运行能力并管理其生命周期。
3. 宿主机操作系统：承载 VMM 运行，并为系统提供网络与存储访问能力。

OpenVMM 就是一款采用 Rust 编写的开源、跨平台 VMM。该项目采用了 MIT 许可证，代码托管在 GitHub 的 microsoft/openvmm 仓库。它既可以作为传统的 VMM 跑在宿主机操作系统上，还被集成到了 OpenHCL 的 paravisor（一种运行在客户机内部的执行环境）中。

OpenVMM 的成长轨迹

自开源以来，OpenVMM 的开发者社区不断壮大，目前已经有近 100 名活跃贡献者，产生了超过 200 个 Fork。得益于 Intel 和 Arm 等行业伙伴的持续贡献，项目在以下关键领域完成了多轮迭代，成熟度也有极大提升。

跨平台虚拟化

• 新增了针对 AArch64 架构的virt_mshv支持，并修复了virt_kvm的底层正确性问题。

设备模型与设备模拟

• 新增了一系列硬件模拟特性，包括面向 AArch64 虚拟机的 SMMUv3 模拟、CXL 模拟、PCIe NUMA 与 ACS 配置暴露。既支持现代的VFIO cdev + iommufd设备分配接口，也向下兼容传统的group/container + Type1v2路径，还实现了完整的netvsp VLAN 支持。

测试基础设施、CI 与构建发布工程

• 基于社区反馈，大幅优化了petri测试框架：新增了物理 NVMe 测试管道、CXL 测试覆盖和透明大页（transparent-huge-page）支持，并引入更详细的「停机原因」报告，调试门槛显著降低。
• 完善了 CI 与构建流程，新增了对 Azure Linux 的原生构建支持。

机密计算

• 得益于 Intel 的贡献，实现了 Azure Intel TDX 机密虚拟机 GA 级别的paravisor支持。在此基础上，开发团队集中攻坚性能优化，把机密虚拟机（CVM）在 CPU、内存密集型负载下的性能损耗从 3% 降到了 1%。
• 与 Arm 合作的 Arm CCA Realm 全新机密架构支持，正在稳步推进，目前已经完成了 OpenHCL 与 TMK 测试基础设施对 Arm CCA 的初步适配。
• 与 AMD 展开合作，持续优化 SEV-SNP 机密虚拟机的paravisor性能与调试体验，新增了虚拟 NMI 支持，并为 SEV-SNP 启用了openhcl_boot串口日志功能。
• 持续扩展paravisor的证明与密封能力，比如新增了结合硬件密封策略的无状态机密虚拟机模式。

除了底层技术迭代，OpenVMM 在更广泛的生态系统中，也展现出了很强的集成潜力。社区贡献者已经在探索，在相关项目中复用 OpenVMM 的代码和组件——比如，WSL 团队正在评估把它作为 WSL 虚拟机的 VMM 后端选项。这些迭代不只是为了完善代码库，更切实地面向了下游的实际业务场景。

为什么要做 OpenVMM

当初决定做 OpenVMM，微软就是冲着这 3 大特性来的：跨平台、分布式的灵活架构，以及面向现代需求的安全设计。

跨平台

业界一直缺一款能在 Windows 和 Linux 之间，能同时横跨多种 Hypervisor、体验保持一致的 VMM。提供广泛的跨平台支持，不只是 OpenVMM 的核心设计原则，也是当初推动项目立项的直接原因。

目前，OpenVMM 已经支持 Linux、Windows 和 macOS 这 3 大主流宿主机操作系统，兼容 MSHV、WHP、KVM 和hypervisor.framework多款虚拟化后端，并原生支持 x64 和 AArch64 双架构。

分布式与灵活架构

OpenVMM 本质上就是一组模块化的 VMM 组件库。开发者可以按需抽取组件，像搭积木一样，针对特定业务场景构建深度定制的 VMM。

它既可以作为传统 VMM 跑在宿主机上，也支持把运行时功能打散，分布到多个不同的执行环境里——比如跑在客户机内部的paravisor环境中。要在这种特殊环境中运行，VMM 就必须满足非常独特的线程模型要求，这也是当初启动 OpenVMM 项目的直接动因之一。

OpenVMM 能在多套环境里无缝运行，靠的是模块化设计和内部的「消息传递」。每个组件都能在新场景下独立复用，不会像传统 VMM 那样僵化的全局耦合。

这种灵活性也体现在工作负载兼容上，它既能适配现代云原生负载，也能很好地承载传统应用：

• 在启动模式上，支持 UEFI、BIOS 和 Linux Direct Boot；
• 在设备层，全面覆盖了直通设备、半虚拟化设备（Virtio 与 VMBus），以及丰富的模拟设备，涵盖了：vTPM、NVMe、串口 UART，以及包括i440BX + PIIX4芯片组、IDE 硬盘/光驱、软驱、PCI、VGA 显卡在内的传统 x86 外设。）

为了适配 Microsoft Azure 生态，OpenVMM 还完整支持 Microsoft Hypervisor ABI 和所有 Hyper-V 模拟、半虚拟化设备。依托模块化设计，开发者在面对全新业务时，可以按需只选用 Hyper-V 客户机接口的一个子集，也可以完全替换成自定义接口。

现代安全设计

构建现代化、高标准的安全防线是 OpenVMM 的一大核心目标。

• 首先，项目尽可能把设备模拟、指令补全、半虚拟化设备和内存管理这类虚拟化功能，从「内核态」剥离出来，转到了「用户态」执行。这样既可以借助「硬件内存保护」和「高级漏洞缓解」技术来提升安全性，代码维护、故障排查也会简单很多，出了安全漏洞也能快速热修复。
• 其次，OpenVMM 引入了强隔离的进程沙箱机制，无关的 VMM 功能可以跑在各自独立的进程里：
  • 在 Windows 平台上，沙箱由最低特权应用容器（LPAC）进行隔离；
  • Linux 平台目前依托内核命名空间，后续也会接入 SELinux 支持。
• 最后，语言选型上也直接面向安全。OpenVMM 全面采用了 Rust 语言编写，从语言层面减少了编程失误导致虚拟机逃逸的可能。在「安全 Rust」的约束下，开发者不用再额外花精力处理「类型安全」和「内存管理」问题，像悬垂指针、释放后使用这类未定义行为——也就是 1992 年业界戏称的「鼻孔恶魔」，从根源上就已经被避免掉了。

顺嘴一提，OpenVMM 团队从项目早期就深度参了与 Rust 的开源演进，推动了编译器和核心库的迭代。在 Rust 异步工作组评估稳定版 trait 异步函数功能时，OpenVMM 就是五个核心评估案例之一（参考 2023 年官方博客《Stabilizing async in traits》）。

除了语言本身的安全特性，OpenVMM 也受益于 Rust 成熟的安全生态：社区有大量开源安全审查工具，顶尖 Rust 安全专家也会高频开展代码审计和威胁建模。

聊完 OpenVMM 的立项初衷和开源以来的社区进展，最后说下微软在虚拟化开源道路上的整体思路：核心就是给客户提供多样化的 VMM 选择，把选型权交回到用户手中。

• 让用户既可以根据自身工作负载，选到最合适的底层方案。也把已经在 Azure、本地部署、客户端场景广泛落地的 Microsoft Hypervisor 的高性能、强隔离能力，开放给各类操作系统和不同虚拟化拓扑下的第三方 VMM 使用。
• 为此，微软还在持续投入 Cloud-hypervisor 和 Hyperlight，来支撑 Azure 的核心负载。兼容生态也保持开放，QEMU 等各类 VMM 都能和 Microsoft Hypervisor 协同运行，在 Azure 上承载更多样的 Linux 业务场景。