2014年1月12日
第11卷，第11期

  PDF

Unikernels：虚拟库操作系统的崛起

如果虚拟机应用中的所有软件层都使用同一种安全、高级语言框架编译，会怎么样？

Anil Madhavapeddy 和 David J. Scott

云计算一直是在大型数据中心向多个（甚至竞争）租户出租计算资源的先驱业务。云的基本使能技术是操作系统虚拟化，例如 Xen¹ 或 VMWare，它允许客户在共享的物理机器集群上多路复用 VM（虚拟机）。每个 VM 都表现为一个自包含的计算机，启动标准的操作系统内核并运行未修改的应用程序，就像它在物理机器上执行一样。

早期云计算增长的关键驱动力是服务器整合。现有的应用程序通常安装在单独利用率不足的物理主机上，而虚拟化使得将它们打包到更少的主机上成为可能，而无需任何修改或代码重新编译。VM 也可以通过软件 API 而不是物理操作来管理。

它们可以集中备份并在不同的物理主机之间迁移，而不会中断服务。今天，亚马逊和 Rackspace 等商业提供商维护着庞大的数据中心，托管着数百万个 VM。这些云提供商减轻了客户管理数据中心的负担，并实现了规模经济，从而降低了成本。

虽然操作系统虚拟化无疑是有用的，但它为已经高度分层的软件堆栈添加了又一层，现在包括：对旧物理协议的支持（例如，20世纪80年代开发的磁盘标准，如 IDE）；不相关的优化（例如，SSD 驱动器上的磁盘电梯算法）；向后兼容的接口（例如，POSIX）；用户空间进程和线程（除了 hypervisor 上的 VM）；以及托管代码运行时（例如，OCaml、.NET 或 Java）。所有这些层都位于应用程序代码之下。我们真的注定每隔几年就添加新的间接层和抽象层吗？让未来的程序员成为虚拟考古学家，当他们挖掘数百层软件模拟来调试即使是最简单的应用程序时？^5,18

编译器解决方案

这个问题在剑桥大学受到了很多思考，包括计算机实验室（Xen hypervisor 于 2003 年起源于此）和 Xen 项目（现在通过亚马逊和 Rackspace 等公司为公共云提供支持的 hypervisor 的托管者）。解决方案——被称为 MirageOS——的思想根植于几十年前就已存在的概念，但直到云计算资源变得更加广泛可用之后，才有可能大规模部署。

MirageOS 的目标是重构整个VM——包括所有内核和用户空间代码——使其成为更模块化、灵活、安全和可重用的组件，风格类似于库操作系统。如果一个应用中的所有软件层都可以使用相同的高级语言框架编译，而不是在每次启动时动态组装它们，会有什么好处？首先，一些关于应用、库操作系统和类型安全编程语言的背景信息。

向单用途应用的转变

今天在云上运行的典型 VM 包含一个完整的操作系统镜像：一个内核（如 Linux 或 Windows）托管一个在用户空间中运行的主要应用程序（例如，MySQL 或 Apache），以及并发运行的辅助服务（例如，syslog 或 NTP）。每个 VM 中的通用软件在每次 VM 启动时通过从存储读取配置文件来初始化。

尽管包含许多灵活的软件层，但大多数已部署的 VM 最终都执行单一功能，例如充当数据库或 Web 服务器。向单用途 VM 的转变反映了按需部署新虚拟计算机变得多么容易。即使在十年前，部署单个（物理）机器实例也需要更多的时间和金钱，因此单台机器需要运行多个最终用户应用程序，因此需要仔细配置以隔离各个服务和用户。

构成 VM 的软件层尚未赶上这一趋势，这代表着优化的真正机会——不仅在性能方面通过使应用适应其任务，而且在安全性方面通过消除冗余功能并减少公共云上运行的服务的攻击面。然而，由于现有操作系统的结构，静态地执行此操作是一个挑战。

当前操作系统的局限性

现代 hypervisor 提供了可以动态扩展的资源抽象——既可以通过添加内存和内核垂直扩展，也可以通过生成更多 VM 水平扩展。许多应用程序和操作系统无法充分利用此功能，因为它们是在现代 hypervisor 出现之前设计的（并且物理类似物（如内存热插拔）在商品硬件中从未普及）。通常，为了使服务通过在负载增加时生成新的 VM 来弹性响应，会在 VM 中运行的传统应用程序中添加外部应用程序级负载均衡器。然而，传统系统并未针对大小或启动时间进行优化（例如，Windows 可能会在启动时应用许多补丁），因此负载均衡器必须通过保持空闲 VM 来处理负载峰值，从而浪费资源和金钱。

为什么不能简单地修复操作系统中的这些问题？现代操作系统旨在保持坚定的通用性，以解决广大受众的问题。例如，Linux 在极其多样化的平台上运行，从低功耗移动设备到为庞大数据中心供电的高端服务器。仅仅为了帮助一类用户提高应用程序性能而损害这种灵活性是不可接受的。

另一方面，由于 hypervisor 可以在较低级别执行此操作，因此专用服务器应用不再需要 OS 充当资源多路复用器。这种方法的一个明显问题是，大多数现有代码都假定存在大型但相当钙化的接口，例如 POSIX 或 Win32 API。另一个潜在问题是，传统操作系统提供诸如 TCP/IP 堆栈用于通信和文件系统接口用于存储持久性数据之类的服务：在我们美好的新世界中，这些服务将从何而来？

MirageOS架构——被称为 unikernels——在图 1 中概述。Unikernels 是专门的 OS 内核，使用高级语言编写，并充当单独的软件组件。一个完整的应用程序（或应用）由一组协同工作的 unikernels 组成，作为一个分布式系统。MirageOS 基于 OCaml (https://ocaml.org.cn) 语言，并发出在 Xen hypervisor 上运行的 unikernels。为了解释其工作原理，让我们看一下 20 世纪 90 年代的一个激进的操作系统架构，它显然超前于时代。

库操作系统

这不是人们第一次提出关于操作系统的存在性问题。一些研究小组提出了操作系统基于称为库操作系统（或 libOS）的架构的设计。第一个这样的系统是 20 世纪 90 年代后期的 Exokernel⁶ 和 Nemesis¹⁰。在 libOS 中，保护边界被推到最低的硬件层，从而产生：（1）一组实现机制的库，例如驱动硬件或进行网络协议所需的机制；以及（2）一组在应用程序层强制执行访问控制和隔离的策略。

与更传统的设计相比，libOS 架构具有几个优点。对于性能——和尤其是可预测的性能——是要求的应用程序，libOS 通过允许应用程序直接访问硬件资源而获胜，而无需进行重复的特权转换以在用户空间和内核空间之间移动数据。libOS 没有中央网络服务，高优先级高优先级网络数据包（例如来自视频会议呼叫的数据包）和低优先级数据包（例如来自后台文件下载的数据包）被迫混合和干扰。相反，libOS 应用程序具有完全独立的队列，数据包仅在到达网络设备时才混合在一起。

libOS 架构有两个很大的缺点。首先，并行运行多个具有强大资源隔离的应用程序是很棘手的（尽管 Nemesis 在最小化交互式应用程序之间的串扰方面做得非常出色）。其次，必须重写设备驱动程序以适应新模型。商品 PC 硬件的快速发展世界意味着，无论有多少研究生被安排编写驱动程序，任何研究 libOS 原型都注定在短短几年内变得过时。这种方法仅在实时操作系统空间（例如，VxWorks）中有效，那里的硬件支持范围更窄。

幸运的是，OS 虚拟化克服了商品硬件上的这些缺点。现代 hypervisor 为 VM 提供 CPU 时间和强大的隔离虚拟设备，用于网络、块存储、USB 和 PCI 桥接。作为 VM 运行的 libOS 只需要实现这些虚拟硬件设备的驱动程序，并且可以依赖 hypervisor 来驱动真正的物理硬件。libOS 应用程序之间的隔离可以通过低成本实现，只需使用 hypervisor 为每个不同的应用程序生成一个新的 VM，使每个 VM 可以自由地专门用于其特定目的。hypervisor 层施加了一个更简单、更少细粒度的策略，而不是传统的操作系统，因为它只是提供了一个低级接口，由虚拟 CPU 和内存页组成，而不是在传统操作系统中发现的进程和面向文件的架构。

尽管 OS 虚拟化使得 libOS 成为可能，而无需一支设备驱动程序编写大军，但仍然需要协议库来替换传统操作系统的服务。现代内核都用 C 语言编写，C 语言擅长低级设备驱动程序等程序，但缺乏更高级别语言的抽象工具，并且需要仔细手动跟踪内存缓冲区等资源。因此，许多应用程序都包含内存处理错误，这些错误通常表现为严重的安全漏洞。其他系统研究人员在将 Windows 和 Linux 都移植到 libOS 模型方面做得非常出色，¹⁶ 但对我们来说，这为探索一种向后兼容的但更自然集成的高级语言模型提供了完美的借口。

图 2 显示了 MirageOS 中的逻辑工作流程。来自源代码（本地和全局库）和配置文件的精确依赖关系跟踪使已部署内核二进制文件的完整出处可以记录在不可变数据存储中，足以按需精确地重新编译它。

更强大的编程抽象

高级语言在通用应用程序开发中稳步发展，并越来越多地用于通过编排框架（例如，Puppet 和 Chef）将组件粘合在一起。不幸的是，所有这些逻辑通常分散在软件组件中，并使用多种语言编写。因此，仅通过分析源代码很难静态地推理整个系统的行为。

MirageOS 旨在统一这些不同的接口——包括内核和应用程序用户空间——到一个单一的高级语言框架中。现代编程语言的一些优点包括

• 静态类型检查。 编译器可以将程序变量和函数分类为类型，并拒绝将一种类型的变量当作另一种类型操作的代码。静态类型检查在编译时而不是运行时捕获这些错误，并为系统程序员提供了一种灵活的方式来相互保护程序的不同部分，而无需完全依赖虚拟内存分页等硬件机制。类型检查最明显的好处是避免了内存错误，例如缓冲区或整数溢出，这些错误在 CERT（计算机紧急响应小组）漏洞数据库中仍然很普遍。更高级的用途是能力风格的访问控制，¹⁹ 只要代码都在同一种语言运行时中运行，就可以在 ML 等静态类型系统中完全强制执行。

• 自动内存管理。 运行时系统减轻了程序员分配和释放内存的负担，同时仍然允许手动管理缓冲区（例如，用于高效的 I/O）。现代垃圾收集器还旨在通过增量和分代收集来最大限度地减少应用程序中断，从而允许它们用于高性能系统构建。^7,11

• 模块。 当代码库增长时，模块将其划分为具有定义明确的接口的逻辑组件，将它们粘合在一起。模块有助于软件开发扩展，因为内部实现细节可以被抽象化，并且可以限制单个源代码更改的范围。一些模块系统，例如 OCaml 和 Standard ML 中发现的模块系统，在编译时静态解析，并且基本上没有运行时成本。目标是利用这些模块系统来构建整个系统，跨越传统的内核和用户空间边界在一个程序中。

• 元编程。 如果在编译时部分了解系统的运行时配置，那么编译器可以比通常情况下更多地优化程序。在不了解运行时配置的情况下，编译器的手脚被束缚，因为输出程序必须保持完全通用，以防万一。这里的目标是在编译时统一配置和代码，并在部署到公共云之前消除浪费。

总之，这些功能大大简化了大规模系统的构建：托管内存消除了许多资源泄漏，类型推断导致更简洁的源代码，静态类型检查验证代码在编译时而不是执行时匹配某些抽象标准，模块系统允许在完整的 OS 和应用程序堆栈所需规模上操作此代码。

Ocaml 中的功能原型

我们于 2008 年开始构建 MirageOS 原型，目的是了解我们可以在多大程度上统一库操作系统和云服务部署背后的编程模型。第一个设计决策是采用函数式编程背后的原则来构建原型。函数式编程强调支持使跟踪程序中可变性更容易的抽象，之前的研究表明，这不必以性能为代价。¹¹

挑战是确定正确的模块化抽象，以支持在单个可管理结构中表达整个操作系统和应用程序软件堆栈。MirageOS 已经发展成为一套成熟的近 100 个开源库，这些库实现了广泛的功能，并且开始集成到 Citrix XenServer 等商业产品中。¹⁷

图 2 说明了 MirageOS 的设计。它赋予编译器比传统的云部署周期更广泛的源代码依赖关系视图

• 输入应用程序的所有源代码依赖项都被显式跟踪，包括实现内核功能所需的所有库。MirageOS 包括一个构建系统，该系统在内部使用 SAT 求解器（使用 OPAM 包管理器，以及来自 Mancoosi 项目的求解器）来搜索来自已发布的在线包集中兼容的模块实现。由于 OCaml 的静态类型检查，接口中的任何不匹配都会在编译时捕获。

• 然后，编译器可以输出完整的独立内核，而不仅仅是 Unix 可执行文件。这些 unikernels 是单用途 libOS VM，它们仅执行其应用程序源代码和配置文件中定义的任务，并且它们依赖 hypervisor 来提供资源多路复用和隔离。甚至必须设置虚拟内存页表并初始化语言运行时的引导加载程序也被编写为一个简单的库。每个应用程序都链接到它需要的特定库集，并且可以以特定于应用程序的方式将它们粘合在一起。

• 专门的 unikernels 部署在公共云上。与传统的虚拟化等效物相比，它们具有明显更小的攻击面，并且在启动时间、二进制大小和运行时性能方面更资源高效。

为什么选择 OCAML？

OCaml 是 MirageOS 的唯一基础语言，原因有几个关键原因。它是一种成熟的系统编程语言，具有灵活的编程模型，在一个面向对象风格的编程模型中支持函数式、命令式和ML 启发的类型系统。它还具有可移植的单线程运行时，这使其非常适合移植到受限环境，例如简陋的 Xen VM。编译器非常强调静态类型检查，并且生成的二进制文件是快速的本机代码，运行时类型信息最少。主要类型推断允许安全地省略类型注释，并且模块系统是通用编程语言中最强大的模块系统之一，在允许灵活和安全的代码重用和重构方面。最后，在大规模工业界¹⁴ 和 Xen 本身¹⁷ 中都有一些 OCaml 的使用示例，并且在开始 MirageOS 这个大型多年项目之前，积极的结果令人鼓舞。

模块化操作系统库

OCaml 支持模块签名的定义（数据类型数据类型和函数声明的集合），这些签名抽象了模块结构的实现（具体数据类型和函数的定义）。模块可以参数化签名，创建函子，函子定义跨其他数据类型的操作。（有关 OCaml 模块、函子和对象的更多信息，请参阅 O'Reilly 出版的 Real World OCaml，网址为 https://realworldocaml.org。）我们将 OCaml 模块系统应用于将通常是单片的 OS 内核功能分解为离散单元。这使程序员能够构建可以在编写时逐步专门化的代码，从熟悉的 Unix 环境中的进程开始，最终在 Xen 上运行的专用云 unikernel 结束。

考虑一个简单的例子。图 3 显示了静态 Web 服务器的部分模块图。库是抽象操作系统功能的模块图，而 OPAM 包管理器解决了目标架构上的约束。应用程序MyHomePage依赖于HTTP签名，该签名由Cohttp库提供。刚开始的开发人员希望使用Unix 风格的开发环境以交互方式探索他们的代码。Cohttp库需要 TCP 实现来满足其模块签名，这可以由UnixSocket库提供。

当程序员对他们的 HTTP 逻辑感到满意时，他们可以重新编译以切换为使用 OCaml TCP/IP 堆栈，如图 3 中的MirTCP所示。这仍然需要 Unix 内核，但仅作为将以太网帧传递到Web 服务器进程的外壳（现在将 OCaml TCP/IP 堆栈作为应用程序的一部分）。最后一个编译策略完全放弃了对 Unix 的依赖，并重新编译MirNet模块以直接链接到 Xen 网络驱动程序，该驱动程序反过来拉入它在 Xen 上启动所需的所有依赖项。这种渐进式重新编译是 MirageOS 可用性的关键，因为我们可以从久经考验的Linux 或 FreeBSD 功能逐步发展，但最终仍然得到可以部署在公共云上的专用 unikernels。这种模块化的操作系统结构导致了许多其他后端以类似于 Xen 的方式实现。MirageOS 现在具有实验性后端，这些后端在 NS3 中实现模拟器（用于大规模功能测试），FreeBSD 内核模块后端，甚至通过使用js_of_ocaml编译器来实现 JavaScript 目标。这种模块化的一个自然结果是，更容易编写可移植代码，这些代码精确定义了它需要从目标平台获得什么，这在现代操作系统上越来越困难，因为缺乏现代等效于 POSIX 的东西（这导致 Linux、FreeBSD、Mac OS X 和 Windows 在高性能服务方面具有许多不兼容的 API）。

配置和状态

MirageOS 中的库以尽可能函数式的风格设计：它们是可重入的，具有显式状态句柄，这些句柄又是可序列化的，因此可以显式地重建它们。应用程序由一组库加上一些配置代码组成，所有这些都链接在一起。配置被构造为一棵树，大致类似于文件系统，子目录由每个库解析以初始化它们自己的值（让人想起 Plan 9 操作系统）。所有这些都通过 元编程——一个OCaml 程序生成更多的 OCaml 代码，这些代码被编译直到达到期望的目标。

元编程也扩展到存储。如果应用程序使用少量文件（通常需要块设备和文件系统的所有包袱），MirageOS 可以将其转换为满足文件系统模块签名的静态 OCaml 模块，从而使其无需外部存储依赖项。整个 MirageOS 主页 (http://openmirage.org) 都是以这种方式提供的。

元编程的一个（故意的）后果是，大型功能块可能会完全从输出二进制文件中丢失。这使得最专业的目标的动态重新配置成为不可能，并且配置更改需要重新链接 unikernel。表 1 显示了 MirageOS Web 服务器中涉及的活动（即后配置）代码行数，这让人感觉到此类重新编译中涉及的少量代码。

链接 Xen Unikernel

在传统的 OS 中，应用程序源代码首先通过本机代码编译器编译为目标文件，然后交给链接器，链接器生成可执行二进制文件。编译后，动态链接器将可执行文件和任何共享库加载到进程中，该进程具有自己的地址空间。然后，进程可以通过系统调用与外部世界通信，系统调用由

操作系统内核

调解。在内核中，诸如网络堆栈或虚拟内存系统之类的各种子系统处理系统调用并与硬件交互。在 MirageOS 中，OCaml 编译器接收整个内核的代码源代码，并将其链接到一个 本机代码独立的目标文件。它与提供启动支持和垃圾收集器的最小运行时链接。没有抢占式线程，内核通过轮询 Xen 设备的 I/O 循环是事件驱动的

。

Xen unikernel 编译的性能优势来自于运行内核具有单个虚拟地址空间的事实，该虚拟地址空间旨在仅运行 OCaml 运行时。图 4 显示了 MirageOS Xen unikernel 目标的虚拟地址空间。由于所有配置信息都显式地成为编译的一部分，因此不再需要通常的动态链接支持，该支持需要在 VM 启动后添加可执行映射。¹³

优势考虑传统应用程序的生命周期。首先，源代码被编译为二进制文件。稍后，二进制文件被加载到内存中，并创建一个 OS 进程来执行它。运行进程要做的第一件事是读取其配置文件，并使其自身专门适应它所处的环境。许多不同的应用程序将运行完全相同的二进制文件，从相同的二进制包中获得，但具有不同的配置文件。这些配置文件实际上是额外的程序代码，只是它们通常使用临时的

语言编写，并在运行时解释而不是编译。

部署和管理配置是在管理大型云托管服务部署中的相当大的开销。使用 unikernel 编译，编译（代码）和解释（配置）之间的传统拆分是不必要的。应用程序配置是代码——可能是嵌入式 领域特定语言——并且

编译器可以分析和优化整个 unikernel。考虑传统应用程序的生命周期。首先，源代码被编译为二进制文件。稍后，二进制文件被加载到内存中，并创建一个 OS 进程来执行它。运行进程要做的第一件事是读取其配置文件，并使其自身专门适应它所处的环境。许多不同的应用程序将运行完全相同的二进制文件，从相同的二进制包中获得，但具有不同的配置文件。这些配置文件实际上是额外的程序代码，只是它们通常使用在 MirageOS 中，不是将数据库、Web 服务器等视为必须通过配置文件连接的独立应用程序，而是将它们视为单个应用程序中的库，允许应用程序开发人员使用简单的库调用来配置它们以获取动态参数，或使用元编程工具来获取静态参数。这具有有用的效果，即使配置决策显式化和可编程化为宿主语言，而不是操作许多文本文件，从而受益于静态分析

工具和编译器的类型检查器。结果是大大减少了配置复杂的多服务应用程序 VM 所需的工作量。

unikernel 的一个缺点是，由于需要调度更多 VM 并增加 churn（因为每次重新配置都需要重新部署 VM），它给云编排层带来了负担。流行的编排实现近年来发展得相当有机，并且由许多分布式组件组成，这些组件不仅难以管理，而且延迟和资源消耗也相对较高。MirageOS 的首批生产用途之一是通过将 XenServer¹⁷ 中的 OCaml 代码朝着结构化的 unikernel 世界观发展来修复云管理堆栈。这会将单片管理层转变为更敏捷的互通信 VM 集，这些 VM 可以独立调度和重启。MirageOS 使构建这些

单用途（http://openmirage.org/blog/xenstore-stub-domain）。当它们与 Xen 驱动程序域³ 结合使用时，可以显著提高MirageOS 的首批生产用途之一是通过将 XenServer¹⁷ 中的 OCaml 代码朝着结构化的 unikernel 世界观发展来修复堆栈的安全性与稳健性。

资源效率和定制

云环境是一种所有资源使用情况都会被计量和租用的环境。与此同时，多租户服务会受到负载变化的影响，这鼓励快速扩展部署——向上扩展以满足当前需求，向下扩展以避免浪费资金。在 MirageOS 中，特定构建中未使用的功能不会被包含，并且全系统优化技术可用于在编译时而不是部署时消除浪费。在最专业的模式下，所有配置文件都进行静态评估，从而实现广泛的死代码消除，但代价是必须重新编译才能重新配置服务。

小型 unikernel 二进制文件（在许多情况下约为数百 KB 量级）使得跨互联网远程数据中心的部署更加顺畅。启动时间也轻松地少于一秒，使得在响应传入网络数据包时启动 unikernel 成为可能。

图 5 比较了 MirageOS 和 Linux/Apache 发行版中服务的启动时间。一个精简版Linux 内核和 MirageOS 的启动时间相似，但一旦 Linux 必须初始化用户空间应用程序，效率低下就会显现出来。MirageOS unikernel 一旦启动即可准备好服务流量。

MLton²⁰ 编译器率先使用了 WPO（全程序优化），其中应用程序及其所有库一起进行优化。在 libOS 世界中，一个完整的程序实际上就是一个完整的操作系统：这项技术现在可以从应用层代码一直优化到低级设备驱动程序。传统系统避开 WPO 而倾向于动态链接，有时与 JIT（即时）编译相结合，在 JIT 编译中，程序会被动态分析，并即时生成优化的代码。全程序、 编译时优化更适合关注资源效率和减少攻击面的云应用程序。其他研究详细阐述了安全性优势。¹³

一个有趣的最新趋势是转向操作系统 容器，其中每个容器都由相同的操作系统内核管理，但具有隔离的文件系统、网络和进程组。容器创建速度很快，因为无需启动新的内核，并且它们与现有的内核接口完全兼容。然而，这些收益是以降低安全性和隔离性为代价的；unikernel 仅通过一个易于理解和审计的小型 API 共享最小的虚拟机监控程序服务。Unikernel 表明，将语言运行时分层到虚拟机监控程序上是轻量级容器的可行替代方案。

可移植性的新前沿

图 3 中所示的 MirageOS 库的结构明确编码了库从其执行环境所需的内容。虽然这传统上意味着一个类 Posix内核和用户空间，但现在可以将 OCaml 编译成更外来的环境，包括 FreeBSD 内核模块、在浏览器中运行的 JavaScript，或者（如 Scala 语言所做的那样）直接以 JVM（Java 虚拟机）为目标。对于 OCaml 类型系统中无法抽象的执行属性，仍然需要一些注意。

例如，浮点数字通常在作为内核模块运行时被禁止；因此，如果浮点代码在为该硬件目标编译时被使用，则修改后的编译器会发出类型错误。

其他第三方OCaml 代码通常表现出类似的结构，使得在 MirageOS 下工作变得更加容易。例如，Arakoon (http://arakoon.org) 是一个分布式键值存储，它实现了一个高效的多 Paxos共识算法。在 MirageOS 下编译它的源代码补丁只触及了两个文件，并且仅限于添加一个新的模块定义，该定义将 Arakoon后端存储映射到 Xen 块驱动程序接口。

野外的 Unikernel

MirageOS 当然不是过去几年中出现的唯一 unikernel，尽管它可能是探索全新设计空间方面最极端的。表 2 显示了构建 unikernel 的其他一些系统。HalVM⁸ 在理念上最接近 MirageOS，但它基于著名的纯粹和惰性的 Haskell 语言，而不是严格求值的 OCaml。

在频谱的另一端，OSv² 和 rump kernels⁹ 为现有应用程序提供了一个兼容层，并弱化了指导 MirageOS 的编程模型改进和类型安全。Drawbridge 项目¹⁶ 将 Windows 转换为 libOS，据报道每个应用程序仅有16-MB开销，但它暴露了比 Xen（例如线程和 I/O 流）更多的更高级别接口，以获得这种效率。

最终，公共云应该像今天支持 Linux 和 Windows 一样，将所有这些新兴项目作为一流公民来支持。Xen 项目旨在支持一个勇敢的尘埃云新世界：微小的一次性虚拟机，它们在虚拟机监控程序上运行，密度远高于目前可能的密度，并且自扩展其资源需求，通过不断调用云结构来实现。MirageOS 背后的 libOS 原则意味着它不限于在虚拟机监控程序上运行平台——许多库可以编译到多尺度环境¹²，范围从 ARM 智能手机到裸机内核模块。为了理解这种灵活性的含义，我们一直在探索用例，范围从管理个人数据⁴ 和促进匿名通信¹⁵，到构建软件定义 数据中心基础设施。

致谢

MirageOS 的努力是巨大的，如果没有多个来源的智力和财政支持，就不可能实现。Richard Mortier、Thomas Gazagnaire、Jonatham Ludlam、Haris Rotsos、Balraj Singh 和 Vincent Bernardoff 的核心团队辛勤工作，帮助我们构建全新OCaml 代码，并得到了 Jon Crowcroft、Steven Hand、Ian Leslie、Derek McAuley、Yaron Minsky、Andrew Moore、Simon Moore、Alan Mycroft、Peter G. Neumann 和 Robert N. M. Watson 的持续支持和反馈。更广泛的 OCaml 社区贡献了数千个 OPAM 包，极大地提高了 MirageOS 的实用性，OCamlPro 的 Pierre Chambart 和 Fabrice Le Fessant 集成了加速 MirageOS/Xen 的 OCaml 编译器优化。Raphael Proust 和 Gabor Pali 在暑期实习期间贡献了 JavaScript 和 kFreeBSD 目标。David Chisnall、Tim Deegan、Marius Eriksen、Nate Foster、Arjun Guha、Tim Harris、Alex Ho、Jon Howell、Stephen Kell、Timothy G. Griffin、Tom Kelly、Ewan Mellor、Prashanth Mundkur、Derek G. Murray、Fernando Ramos、Malte Schwarzkopf、Peter Sewell、David Sheets、Ripduman Sohan、Leo White 和 Jeremy Yallop 对这项工作的多次迭代提供了反馈。我们受益于 Citrix Systems、Jane Street、Lexifi 以及当然还有 INRIA Galium 小组 Xavier Leroy 领导的 OCaml 开发团队的大量开源代码贡献。Linux 基金会也接受了 MirageOS 作为 Xen 孵化器项目，这要感谢 Lars Kurth 和 Amir Chaudhry 的努力。

这项工作主要由 Horizon Digital Economy Research、RCUK 资助 EP/G065802/1 支持。一部分由 DARPA（国防高级研究计划局）和 AFRL（空军研究实验室）根据合同FA8750-11-C-0249 赞助。本报告中包含的观点、意见和/或发现是作者的观点，不应被解释为代表 DARPA 或国防部的官方观点或政策，无论是明示的还是暗示的。

MirageOS 可在 http://openmirage.org 免费获得。我们欢迎反馈、补丁以及使用它的不可思议的特技。

参考文献

1. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., Warfield, A. 2003. Xen and the art of virtualization. In Proceedings of the 19th Symposium on Operating Systems Principles 164-177.

2. Cloudius Systems. OSv; https://github.com/cloudius-systems/osv。

3. Colp, P., Nanavati, M., Zhu, J., Aiello, W., Coker, G., Deegan, T., Loscocco, P., Warfield, A. 2011. Breaking up is hard to do: security and functionality in a commodity hypervisor. In Proceedings of the 23rd Symposium on Operating Systems Principles (SOSP) 189-202.

4. Crowcroft, J., Madhavapeddy, A., Schwarzkopf, M., Hong, T., Mortier, R. Unclouded vision. In Proceedings of the International Conference on Distributed Computing and Networking (ICDCN) 29-40.

5. Eisenstadt, M. My hairiest bug war stories. 1997. Communications of the 40(4) 30-37.

6. Engler, D. R., Kaashoek, M. F., O'Toole, Jr., J. 1995. Exokernel: an operating system architecture for应用层resource management. In Proceedings of the 15th Symposium on Operating Systems Principles (SOSP) 251-266.

7. Eriksen, M. 2013. Your server as a function. In Proceedings of the Seventh Workshop on Programming Languages and Operating Systems (PLOS): 5:1-5:7.

8. Galois Inc. The Haskell Lightweight Virtual Machine (HaLVM) source archive; https://github.com/GaloisInc/HaLVM。

9. Kantee, A. 2012. Flexible operating system internals: the design and implementation of the anykernel and rump kernels. Ph.D. thesis, Aalto University, Espoo, Finland.

10. Leslie, I. M., McAuley, D., Black, R., Roscoe, T., Barham, P. T., Evers, D., Fairbairns, R., Hyden, E. 1996. The design and implementation of an operating system to support distributed multimedia applications. IEEE Journal of Selected Areas in Communications 14(7) 1280-1297.

11. Madhavapeddy, A., Ho, A., Deegan, T., Scott, D., Sohan, R. 2007. Melange: creating a "functional" Internet. SIGOPS Operating Systems Review 41(3) 101-114.

12. Madhavapeddy, A., Mortier, R., Crowcroft, J., S. Hand, S. 2010. Multiscale not multicore: efficient heterogeneous cloud computing. In Proceedings of -BCS Visions of Computer Science. Electronic Workshops in Computing, Edinburgh, UK.

13. Madhavapeddy, A., Mortier, R., Rotsos, C., Scott, D., Singh, B., Gazagnaire, T., Smith, S., Hand, S., Crowcroft, J. 2013. Unikernels: library operating systems for the cloud. In Proceedings of the 18th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS): 461-472.

14. Minsky, Y. 2011. OCaml for the masses. Communications of the 54(11) 53-58.

15. Mortier, R., Madhavapeddy, A., Hong, T., Murray, D., Schwarzkopf, M. 2010. Using dust clouds to enhance anonymous communication. In Proceedings of the 18th International Workshop on Security Protocols (IWSP).

16. Porter, D. E.,Boyd-Wickizer,S., Howell, J., Olinsky, R., Hunt, G. C. 2011. Rethinking the library OS from the top down. In Proceedings of the 16th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS) 291-304.

17. Scott, D., Sharp, R., Gazagnaire, T., Madhavapeddy, A. 2010. Using functional programming within an industrial product group: perspectives and perceptions. In Proceedings of the 15th SIGPLAN International Conference on Functional Programming (ICFP): 87-92.

18. Vinge, V. 1992. A Fire Upon the Deep. New York, NY: Tor Books.

19. Watson, R. N. M. 2013. A decade of OSaccess-controlextensibility. Communications of the 56(2) 52-63.

20. Weeks, S. 2006.Whole-programcompilation in MLton. In Proceedings of the 2006 Workshop on ML.

在符合以下条件的情况下，特此授予为个人或课堂使用而复制本作品的数字或硬拷贝的许可，无需任何费用：副本不得为营利或商业优势而制作或分发；副本必须带有本声明和第一页的完整引用。否则，若要复制、再版、张贴在服务器上或再分发到列表，则需要事先获得具体许可和/或支付费用。

喜欢还是讨厌？请告诉我们 [email protected]

Anil Madhavapeddy 是剑桥大学系统研究小组的高级研究员。他是开发 Xen 虚拟机监控程序和行业领先的用 OCaml 编写的 XenServer 管理工具链的原始团队成员。XenServer 已部署在数百万台主机上，并为许多财富 500 强公司驱动关键基础设施。在 2006 年获得剑桥大学博士学位之前，Anil 在 Network Appliance、NASA 和 Internet Vision 等公司拥有多元化的行业背景。他是开源社区的活跃成员，为 OpenBSD 和 OCaml 做出了贡献，是函数式编程商业用途研讨会指导委员会成员，并且是 O'Reilly 出版的 Real World OCaml 的作者。

Dave Scott 是 Citrix Systems 的首席架构师，他在那里从事 XenServer 虚拟化平台的工作。Dave 的主要重点是通过利用开源软件和高级语言方面的进步来提高 XenServer 的可靠性和性能。此前，Dave 曾是新泽西州普林斯顿 Fraser Research 的技术人员。Dave 拥有剑桥大学计算机科学博士学位。

© 2013 1542-7730/13/1100 $10.00

最初发表于 Queue 第 11 卷，第 11 期—
在 数字图书馆 中评论本文

---

更多相关文章

Marc Brooker, Ankush Desai - AWS 系统正确性实践
构建可靠且安全的软件需要一系列方法来推理系统正确性。除了行业标准测试方法（例如单元测试和集成测试）之外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分——也许最重要的是，形式化规范作为测试预言，为 AWS 的许多测试实践提供正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，这些领域已经看到的投资回报加速了这一趋势。

Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经达到了分布式计算无处不在的地步。内存应用程序数据大小正在超过单台机器的容量，因此需要将其分区到集群中；在线服务具有高可用性要求，这只能通过将系统部署为多个冗余组件的集合来满足；高持久性要求只能通过数据复制来满足，有时跨越广阔的地理距离。

David R. Morrison - 模拟：分布式系统中未充分利用的工具
模拟在人工智能系统的出现中发挥着巨大作用：我们需要一种高效、快速且经济高效的方式来训练人工智能代理在我们的基础设施中运行，而模拟绝对提供了这种能力。

Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 公司到云端：谷歌的虚拟桌面
超过四分之一的 Googler 使用内部、数据中心托管的虚拟桌面。这种本地产品位于公司网络中，允许用户从世界任何地方远程开发代码、访问内部资源和使用 GUI 工具。在其最显着的特性中，虚拟桌面实例可以根据手头的任务调整大小，具有持久的用户存储，并且可以在公司数据中心之间移动以跟随出差的 Googler。直到最近，我们的虚拟桌面都托管在使用名为 Ganeti 的本土开源虚拟集群管理系统的 Google 公司网络上的商用硬件上。今天，这项重要且对 Google 至关重要的工作负载在 GCP（Google Compute Platform）上运行。

---

---

© 保留所有权利。