与 qemu 之类的东西相比，firecracker microvm 为何显得“微型”？

Question

来自https://firecracker-microvm.github.io/：

\n

\n

Firecracker 是 QEMU 的替代品，专为安全高效地运行无服务器功能和容器而构建，仅此而已。Firecracker 是用 Rust 编写的，为客户操作系统提供了所需的最小设备模型，同时排除了非必要的功能（仅提供 5 个模拟设备：virtio-net、virtio-block、virtio-vsock、串行控制台和最小键盘）控制器仅用于停止 microVM）。这与简化的内核加载过程一起实现了 < 125 ms 的启动时间和 < 5 MiB 的内存占用。Firecracker 进程还提供 RESTful 控制 API，处理 microVM 的资源速率限制，并提供 microVM 元数据服务以实现主机和来宾之间的配置数据共享。

\n

\n

那么导致 qemu 变慢的主要原因是什么\xe2\x80\x94（主要是设备模拟）？

\n

而 125ms + 5MB 的启动时间与……形成对比的是什么呢？

\n

Answer 1

是的，firecracker 比 QEMU 启动更快、更轻，数字随使用的内核和给定的选项（驱动程序、设备）而变化（从小到 10 倍）。\n这里有一篇较旧的论文：https: //dreadl0ck.net /papers/Firebench.pdf \xe2\x80\x93 发现 firecracker 速度更快，但并不令人印象深刻：

\n

\n

在我们的实验中，连续实验中 Firecracker microVM 的平均内核启动时间为 800 毫秒，并发场景中为 1000 毫秒。QEMU 启动 Linux 内核的速度比平均速度慢 18%。[\xe2\x80\xa6] 需要注意的是\n网络堆栈设置需要额外的时间，\n在不初始化网络堆栈的情况下，机器能够\n在 150ms-200ms 内启动。Firecracker 启动时间缩短的原因是 Firecracker 仅模拟五种设备：virtio-net、virtio-block、virtio-vsock、串行控制台和仅用于停止 microVM 的最小键盘控制器。

\n

\n

但我会从另一个角度评估这一点：firecracker 故意最小化，以减少配置错误的可能性，重要的是最小化攻击面（它通常用于运行不受信任的工作负载）。此外，ReST-API 的完全控制使其易于编排。

\n