使用 rust-vmm 构建未来的虚拟化栈

rust-vmm 促进了 Rust 虚拟机监视器之间核心虚拟化组件的共享。

一年多以前，我们开始开发 Firecracker，这是一个运行在 KVM（基于内核的虚拟机）之上的虚拟机监视器 (VMM)。我们希望创建一个轻量级的 VMM，它能在几分之一秒内启动虚拟机 (VM)，内存占用低，从而实现高密度的云环境。

我们最初是通过 fork Chrome OS VMM (CrosVM) 来开发 Firecracker 的，但由于我们针对不同的客户用例，因此不久之后就分道扬镳了。CrosVM 在 ChromeOS 中提供 Linux 应用程序隔离，而 Firecracker 用于大规模运行多租户工作负载。尽管我们现在走的是不同的道路，但我们仍然拥有共同的虚拟化组件，例如 KVM 输入/输出控制 (ioctl) 的封装器、最小内核加载器，以及 Virtio 设备模型的使用。

考虑到这一点，我们开始考虑共享通用代码的最佳方法。拥有共享代码库可以提高两个项目的安全性和质量标准。目前，修复安全漏洞需要重复工作，包括将更改从一个项目移植到另一个项目，以及通过不同的审查流程来合并更改。在开源 Firecracker 之后，我们收到了添加功能的请求，包括 GPU 支持和启动 bzImage 文件。一些请求与 Firecracker 的目标不一致，但却是有效的用例，只是尚未找到合适的实现位置。

rust-vmm 项目

rust-vmm 项目于 2018 年 12 月诞生，当时 Amazon、Google、Intel 和 Red Hat 的员工开始讨论共享虚拟化软件包的最佳方式。沿途有更多的贡献者加入了这一倡议。我们仍处于这段旅程的开始阶段，目前只有一个组件发布到 Crates.io（Rust 的软件包注册表），还有其他几个组件（例如 Virtio 设备、Linux 内核加载器和 KVM ioctl 封装器）正在开发中。随着两个用 Rust 编写的 VMM 处于积极开发中，并且人们对构建其他专用 VMM 的兴趣日益浓厚，rust-vmm 应运而生，成为共享核心虚拟化组件的主机。

rust-vmm 的目标是使社区能够创建自定义 VMM，这些 VMM 仅导入其用例所需的构建块。我们决定将 rust-vmm 组织为一个多存储库项目，其中每个存储库对应于一个独立的虚拟化组件。每个单独的构建块都发布在 Crates.io 上。

使用 rust-vmm 创建自定义 VMM

下面讨论的组件目前正在开发中。

图表中右侧的每个框都是一个 GitHub 存储库，对应于一个包，在 Rust 中称为 crate。一个 crate 的功能可以进一步分解为模块，例如 virtio-devices。让我们来看看这些组件及其一些潜在的用例。

KVM 接口： 在 KVM 之上创建我们的 VMM 需要一个可以从 Rust 调用 KVM 功能的接口。 kvm-bindings crate 表示 Rust 外部函数接口 (FFI) 到 KVM 内核头文件。因为头文件仅包含结构和定义，所以我们还在 KVM ioctl (kvm-ioctls) 上提供了封装器，我们使用它们来打开 dev/kvm、创建 VM、创建 vCPU 等。
Virtio 设备和速率限制： Virtio 具有前端-后端架构。目前在 rust-vmm 中，前端在 virtio-devices crate 中实现，后端位于 vhost 包中。 Vhost 支持用户空间和内核空间驱动程序，但用户也可以将 virtio-devices 插入到他们的自定义后端。 virtio-bindings 是使用 Virtio Linux 头文件生成的 Virtio 设备的绑定。 virtio-devices crate 中的所有设备都使用条件编译独立地导出为模块。某些设备（例如 block、net 和 vsock）支持 I/O 每秒和带宽方面的速率限制。这可以通过使用 rate-limiter crate 中提供的功能来实现。
kernel-loader 负责将 ELF 内核映像的内容加载到客户机内存中。

例如，假设我们要构建一个自定义 VMM，允许用户创建和配置运行在 KVM 之上的单个 VM。作为配置的一部分，用户将能够指定内核映像文件、根文件系统、vCPU 数量和内存大小。可以使用 kvm-ioctls crate 实现 VM 资源的创建和配置。内核映像可以使用 kernel-loader 加载到客户机内存中，并且可以使用 virtio-devices 块模块来实现指定根文件系统。我们的 VMM 所需的最后一件事是编写 VMM Glue，该代码负责将 rust-vmm 组件与 VMM 用户界面 集成，从而允许用户创建和管理 VM。