BMcast：裸金属云的快速部署

提高裸金属云中的敏捷性和弹性

摘要

裸金属云是一种新兴的基础设施即服务（IaaS），它出租物理机器（裸金属实例）而非虚拟机，使资源密集型应用能够独占访问物理硬件。然而，由于缺乏虚拟化层，裸金属实例的部署需要耗时或依赖特定操作系统的任务，从而牺牲了传统IaaS云的一些有益特性，如敏捷性、弹性和操作系统透明性。我们提出了BMcast，这是一种操作系统部署系统，配备了一种专用的de-virtualizable虚拟机监视器（VMM），支持裸金属实例的快速且操作系统透明的启动。BMcast在允许客户操作系统直接访问物理硬件的同时执行流式操作系统部署，并在部署完成后消失。实例的快速启动显著提升了敏捷性和弹性，而操作系统透明性则大大简化了云客户的管理任务。实验结果证实，BMcast启动裸金属实例的速度比镜像复制快8.6倍，在流式操作系统部署期间，BMcast上的数据库性能与当前最先进的VMM（未执行部署时）相当。BMcast在去虚拟化后开销为零。

1. 引言

如今，大多数基础设施即服务（IaaS）提供商向客户租赁虚拟机（VMs）。虚拟化有助于构建其云基础设施，并提供云计算的某些基本特征，如按需自助服务、资源池化和快速弹性。许多研究工作致力于提升虚拟机的性能[17, 27, 39, 49],，使其作为大多数应用程序的平台具备合理的性能。然而，对于具有较高性能、功能和安全需求的某些前沿云应用而言，虚拟化仍可能成为显著的障碍。

例如，大数据应用、高性能计算应用、数据库服务器和媒体服务器必须避免因虚拟化导致的性能下降和不可预测性，以保持持续的高性能，实现不间断的实时数据处理[28, 29]。谷歌和脸书由于这一原因，其主要应用不使用虚拟化[2, 3]。此外，某些应用需要特殊硬件配置，例如专用GPU[8],InfiniBand网卡[10],特定SSD产品[12],和RAID配置[5]。具有严格安全要求的公司不愿使用虚拟化的多租户环境[41, 50]。因此，如今相当数量的客户要求使用物理机器（裸金属实例）而非虚拟机作为其计算平台[28,36]。为应对这一需求，包括IBM在内的多家云服务提供商已开始支持裸金属实例[4, 9, 10]。

遗憾的是，裸金属实例在初始操作系统部署时需要耗费大量时间或依赖特定操作系统的任务。一种直接的操作系统部署方法是在启动实例之前，将整个操作系统镜像从服务器复制到本地磁盘。因此，客户必须等待长达数十分钟（取决于网络带宽和镜像大小）以完成复制过程。复制完成后重启机器还会进一步增加数分钟的总等待时间，特别是当机器采用具有较慢固件初始化的面向服务器的主板时。这种较长的部署时间严重削弱了传统IaaS云的优势特性，例如敏捷性和弹性，并成为临时测试、按需快速扩展以及按小时计费的服务等方面的障碍。虚拟机实例的启动时间的重要性已被用户和研究社区所认识[35, 40],，同样的考虑也适用于裸金属实例。

操作系统流式部署[24] 是一种有望减少等待时间的方法。该方法首先执行网络启动，然后在后台将操作系统镜像复制到本地磁盘。这使得实例能够快速启动，并在操作系统部署完成后实现最终裸金属性能。然而，操作系统流式部署严重依赖于操作系统功能和配置，从而牺牲了基础设施即服务云的另一个重要特性，即操作系统透明性。放弃操作系统透明性不仅给云服务提供商，也给云用户带来了关键限制，因为技术不熟练的用户每次更新、打补丁或定制其操作系统时，都必须测试并验证特殊驱动程序与操作系统内核的兼容性。提供预配置操作系统镜像可能使用户避免此类复杂性，但显著限制了云用户可选择的操作系统种类。使用传统的虚拟机监视器（VMM）可提供操作系统透明性，并缓解兼容性问题，同时支持快速操作系统部署[22]。然而，即使是最先进的VMM也会带来持续的虚拟化开销，难以实现纯裸金属性能[27, 32, 38, 45, 48]。

我们的研究旨在将传统IaaS云的多个有益特性引入裸金属云中：在保持操作系统透明性的同时提升敏捷性和弹性，并且不牺牲性能。为此，我们提出了 BMcast，这是一种配备专用可去虚拟化VMM的操作系统部署系统，支持裸金属实例的操作系统透明的快速启动。BMcast通过透明的流式操作系统部署快速生成可立即使用的裸金属实例，同时允许正在部署的操作系统直接访问硬件，以尽可能地减少开销。在操作系统部署完成后，BMcast关闭虚拟化并从已部署的操作系统下方消失。

该方法的关键挑战在于实现两个冲突目标，即在客户操作系统与虚拟机监视器之间共享设备以实现低开销流式操作系统部署，以及最终实现裸金属性能的无缝去虚拟化。使用虚拟设备使得设备共享变得容易，但由于客户操作系统可见的设备接口在去虚拟化过程中会发生变化，因此使去虚拟化变得复杂。直接向客户操作系统暴露物理设备虽使去虚拟化变得容易，但却使设备共享变得困难。尽管去虚拟化的基本概念先前已被提出[30, 34],，但客户操作系统与虚拟机监视器之间共享I/O设备的运行时去虚拟化仍然是一个开放性问题。为解决此问题，我们引入设备中介器，其通过仔细监控、拦截、操控和插入符合设备规格的I/O请求，执行基于轮询的设备接口级I/O中介。设备中介器允许物理设备先被共享，然后无缝地去虚拟化。

设备中介器的概念新颖且简单通用。开发设备中介器在一定程度上需要了解设备规格；然而，设备中介器的任务相对直接，因此设备中介器比传统设备驱动程序简单得多且代码量更小。事实上，我们为IDE和 AHCI设备开发的设备中介器分别仅有1,472代码行数 （LOC）和2,285 LOC。我们还发现MegaRAID SAS和Revo Drive PCIe SSD设备具有类似的直接接口。我们认为大多数存储主机控制器的软件接口具有相似性，因为主机控制器与磁盘驱动器之间的底层物理接口类型有限（SATA和SAS）。一旦在云提供商端实现，设备中介器通过提供操作系统透明性，显著简化了客户的管理任务。关于设备中介器成本的更多问题在第 6节中讨论。

我们基于BitVisor [46]实现了一个BMcast的原型 VMM。我们仅对BitVisor 1.4的核心进行了3,576行代码的修改。该原型支持配备IDE和AHCI磁盘控制器，以及 Intel PRO/1000、X540、Realtek RTL816x和 Broadcom NetXtreme网络接口控制器（NIC）的x86环境。我们还设计并实现了一种网络存储协议，该协议扩展了以太网上的ATA（AoE）协议[43]，以提升网络存储性能。尽管与客户机操作系统共享网卡在技术上是可行的，但我们当前的实现使用专用NIC进行流式操作系统部署，以避免性能干扰。我们认为为管理用途配置专用NIC是一种合理的方案，因为现代服务器机器通常具备多个网卡。

共享网卡的可能性将在第6节中讨论。

我们当前的实现尚未完全支持 VMXOFF（即完全关闭 CPU 的硬件虚拟化功能）。尽管其性能优势可忽略不计，但支持 VMXOFF 以及支持嵌套虚拟化 [20],将允许客户操作系统利用 CPU 的硬件虚拟化功能。由于支持 VMXOFF 涉及一些复杂性，我们目前仅有一个带有客户内核模块支持的实现（未用于性能评估）。然而，在虚拟机监视器中实现完全的操作系统透明实现是可行的，也是我们未来的工作方向。

实验结果证实，BMcast 可以在无需任何修改的情况下部署 Windows（Vista、7、8.1、Server 2008）和 Linux（Ubuntu 10.04 及更高版本，以及 CentOS 6.3 及更高版本）。BMcast 启动裸机实例的速度比镜像复制快 8.6 倍，且 BMcast 上的平均数据库吞吐量与最先进的虚拟机监视器（即支持无退出中断（ELI）的基于内核的虚拟机（KVM））相当[1, 27]，尽管 BMcast 正在执行流式操作系统部署，而支持 ELI 的 KVM 并未执行该操作。经过去虚拟化后，BMcast 实现了零开销。

2. 相关工作

我们首先介绍操作系统部署方法，然后从操作系统部署的角度讨论虚拟机监视器的开销。

操作系统部署

镜像复制，如 OpenStack Nova [7],中的实现，是一种对操作系统透明但耗时较长的操作系统部署方法。例如，在 130 MB/秒的速度下复制一个 30 GB 的镜像 （Amazon EC2 上默认的 Windows Server 2008，通过 10‐Gb 以太网从 1.5 K rpm SAS 磁盘传输）大约需要 5 分钟。使用固态硬盘可能缩短复制时间；然而，当同时部署多个实例时，服务器或网络可能会达到饱和。复制后重启机器还会因较长的固件初始化时间而额外增加数分钟。网络安装，如 Linux 中的 Kickstart，是另一种类似的方法，它通过网络将系统文件从服务器复制并安装到本地磁盘。但这种方法依赖于特定操作系统，且完成复制操作需要数十分钟。

网络启动可以快速启动操作系统；然而，它不会将操作系统镜像部署到本地磁盘，导致每次磁盘I/O都需要通过网络重定向，从而产生持续的开销。在本地磁盘上缓存数据[22]可以减少I/O开销，但必须在关键I/O路径上的每次磁盘访问时检查缓存是否过期，这会增加磁盘访问延迟。

操作系统流式部署[24]是一种结合网络启动和镜像复制的混合方法，能够实现操作系统的快速启动并将其部署到本地磁盘。尽管该方法可以减少启动时间和开销，但仍会牺牲操作系统的透明性。我们的方法通过利用可去虚拟化 VMM，在保持操作系统部署期间低开销和最终裸金属性能的同时，增强了操作系统流式部署，提供了操作系统透明性。

VMM overhead

利用传统的虚拟机监视器（如Xen [17]和 KVM [31],）是一种快速启动操作系统同时保持操作系统透明性的简便方法。然而，尽管已有努力通过半虚拟化 [17]和I/O直通[39, 49],等技术来降低虚拟化开销，此类虚拟机监视器在计算密集型和I/O密集型工作负载中仍无法达到裸金属性能[18, 29, 37]，原因包括持有锁的抢占问题[47],、缓存污染、嵌套分页以及中断处理开销[21, 27]。

另一种可能的方法是在操作系统部署后卸载虚拟机监视器。一些最近的虚拟机监视器支持原始磁盘和虚拟到物理转换。因此，在流式操作系统部署期间使用虚拟机监视器，然后将虚拟实例转换为物理实例是可行的。然而，卸载虚拟机监视器需要重启操作系统，这会导致停机时间。最近的一项研究表明，可以实现更无缝的转换通过利用操作系统休眠[32]可以实现。然而，除了对操作系统进行轻微修改外，这还需要90秒用于物理到虚拟转换。

创建具有与物理设备相同设备接口的虚拟设备，可以在保持操作系统透明性的同时简化去虚拟化。然而，模拟一台具有与底层物理机器（包括所有设备，例如芯片组和ACPI功能）完全相同的硬件接口的整台机器，代价较高。此外，同步虚拟设备与物理设备的内部状态是一个开放性问题。因此，实现虚拟实例到物理实例的无缝且透明的转换十分困难。

NoHype [30]允许在启动客户操作系统后移除虚拟化层以消除攻击面。Microvisor [34]展示了用于服务器在线维护的运行时去虚拟化。基于直通的VMM允许客户操作系统对I/O设备进行直接控制[44, 46]，也可以实现去虚拟化。然而，当前的可去虚拟化VMM不支持客户操作系统与VMM之间的设备共享。因此，VMM无法访问本地磁盘以复制操作系统镜像。

BMcast 实现了无缝去虚拟化和最终的裸金属性能，这与传统的虚拟机监视器不同。BMcast 还实现了与客户操作系统之间的低开销设备共享，这不同于现有的可去虚拟化或直通虚拟机监视器。

3. 设计

在本节中，我们首先解释部署过程。然后介绍三种BMcast功能，如I/O中介、background copy和去虚拟化。

3.1 部署过程

BMcast 通过以下四个阶段来部署操作系统：初始化、部署、去虚拟化和裸机。

在初始化阶段，虚拟机监视器在目标机器上启动。尽管可以从本地磁盘启动，但我们采用网络启动以简化 VMM管理（例如打补丁和更新）。为了实现快速启动，我们尽可能减小VMM的大小，并通过并行化初始化过程来优化启动速度。VMM仅初始化专用NIC，而其他硬件设备则保持未初始化状态，因为客户操作系统将负责初始化这些设备。实际启动时间在几秒之内。在此阶段，本地磁盘尚未初始化；所有磁盘块均为空，不包含操作系统镜像（图1a）。

在部署阶段，虚拟机监视器（VMM）为流式操作系统部署执行两项任务：（1）对空块通过按读复制从服务器获取数据；（2）通过后台复制主动填充空块。按读复制可实现操作系统实例的快速启动，而后台复制最终可达到裸机性能。在按读复制过程中，当客户操作系统请求的块为空块时，虚拟机监视器（VMM）会从服务器获取相应数据，然后将数据返回向客户操作系统提供数据，就像从本地磁盘读取一样（参见图1b 中的重定向）。虚拟机监视器还会将数据写入本地磁盘以供将来使用。在其他情况下，来自客户操作系统的I/O请求通过虚拟机监视器，并由本地磁盘提供服务（图1b中读取和写入的实线箭头）。

与读时复制并行，虚拟机监视器通过后台复制操作主动填充空块（参见图1b中的后台复制）。本地磁盘逐渐被磁盘镜像填充，客户操作系统最终获得裸机磁盘性能。为了减少对客户操作系统的性能干扰，虚拟机监视器会调节后台复制的速度。此过程的详细信息在第 3.2和3.3节中描述。为了实现无缝去虚拟化，我们对本地磁盘和服务器上的磁盘镜像使用相同的块地址空间；磁盘镜像的扇区号与本地磁盘的扇区号相对应。

在去虚拟化阶段，虚拟机监视器关闭虚拟化，以允许所有硬件访问通过虚拟机监视器（图1c）。为了实现客户操作系统无感知的无缝去虚拟化，虚拟机监视器在去虚拟化期间向客户操作系统暴露相同的硬件接口，并且虚拟机监视器等待一致的硬件状态，即停止虚拟化的适当时机。此过程的详细信息在第3.4节中讨论。

在裸金属阶段，虚拟机监视器不存在。操作系统直接在裸金属实例上运行（图1d）。此时，磁盘镜像与服务器上的相同，除了已经写入数据的磁盘区域。

3.2 通过DeviceMediators实现I/O中介

设备中介器是在向客户操作系统直接暴露物理硬件接口的同时，实现设备共享所需的关键组件。设备中介器执行I/O中介；它们中介客户操作系统与虚拟机监视器对设备的访问。I/O中介包括三项任务：I/O解释、I/O重定向和I/O多路复用。I/O解释涉及监控来自客户操作系统的I/O序列并确定其上下文。I/O重定向I/O重定向涉及拦截来自客户操作系统的I/O请求并将其实重定向到服务器，而I/O多路复用涉及将来自虚拟机监视器的I/O请求插入设备。需要注意的是，I/O解释 是I/O重定向和I/O多路复用的基础。按读复制中使用了I/O重定向，后台复制中使用了I/O多路复用。

I/O解释

I/O解释用于确定I/O序列的上下文，以正确控制来自客户操作系统的I/O访问。例如，在磁盘控制器中，设备中介器解释三种类型的上下文信息：命令、状态和数据。命令信息包含操作类型（例如读取或写入）、逻辑块地址（LBA）以及扇区计数。状态信息用于确定设备处于空闲或忙状态，这是判断操作何时终止所必需的。数据信息涉及实际的数据传输，例如客户操作系统中DMA缓冲区的地址。

设备中介器可以通过监控程序化I/O（PIO）和内存映射I/O（MMIO），并结合队列等内存数据结构，根据设备规格轻松捕获这些信息。尽管实际的I/O序列因设备而异，但该基本概念可应用于多种不同类型的磁盘控制器。此外，设备中介器只需确定这些基本的 I/O序列，而可以忽略其他无关的序列，例如设备初始化和厂商特定配置。因此，设备中介器比传统全规格设备驱动程序更简单、更小巧。

I/O重定向

I/O重定向在部署阶段用于将对空块的读取访问重定向到存储服务器。设备中介器必须（1）捕获块信息，（2）从服务器检索相应的数据，然后（3）将数据传递给客户操作系统。

图2展示了I/O重定向的基本操作。设备中介器使用I/O解释来捕获命令信息（图2中的“1. 解释”）。通过解释I/O请求，设备中介器可以确定是否需要访问是读取还是非读取，如果是读取，则确定其位置（逻辑块地址和扇区计数）。基于此信息，虚拟机监视器判断这些块是空的还是已填充的。

当块为空时，设备中介器必须从服务器检索相应的数据（图2中的“2. 检索”）。首先，设备中介器临时阻塞对设备的I/O访问，以防止设备启动数据传输。然后，设备中介器通过网络发送命令信息，并从服务器检索数据。在检索数据期间，设备中介器模拟状态信息，使客户操作系统能够判断设备处于忙碌状态。在检索到数据后，设备中介器充当虚拟DMA控制器，将数据传递给客户操作系统；即，将数据复制到客户DMA缓冲区（图2中的“3. 复制”）。设备中介器通过I/O解释获取客户DMA缓冲区的地址。

此时，设备中介器必须生成一个中断以指示操作已完成。这里的问题是如何生成该中断。一种可能的方法是虚拟化中断控制器；但这会使去虚拟化变得复杂。另一种可能的方法是使用类似于I/O多路复用的技术，透明地与客户操作系统共享中断控制器，如下所述。然而，共享中断控制器非常复杂，尤其是当使用高级可编程中断控制器（APIC）时。跟踪客户操作系统分配给设备的中断号也很困难，因为它依赖于平台硬件，例如芯片组中的低引脚计数器控制器和PCI桥。因此，这种方法会大幅降低可移植性。

设备中介器不会发送虚拟中断，而是简单地重新启动对设备的阻塞I/O访问，使设备自身生成中断（图2 中的“4. 重启”）。为了防止设备覆盖客户机DMA缓冲区，设备中介器会配置设备将数据传输到虚拟缓冲区。设备中介器还会修改命令信息（逻辑块地址和扇区计数），使设备读取一个命中磁盘缓存的虚拟扇区。该技术实现了中断的简单且透明的生成。

I/O multiplexing

I/O多路复用用于后台复制。I/O多路复用允许虚拟机监视器在客户操作系统控制设备的同时，向设备发出自身的I/O请求。设备中介器必须（1）查找插入I/O请求的合适时机，（2）模拟设备状态并处理请求，以及（3）管理请求队列。

图3说明了基本的I/O多路复用操作。首先，设备中介器查找合适的时机以安全地通过分时方式共享设备（图3 中的“1. 查找”）。如果该设备正在处理来自客户操作系统的I/O请求，设备中介器将等待请求完成。设备中介器通过I/O解释来检测这一情况。

当请求完成后，设备中介器将来自虚拟机监视器（ VMM）的I/O请求发送到设备（图3中的“2. 请求”）。为了保持一致性，即使设备实际上正在处理来自VMM的请求，设备中介器仍模拟设备的状态，使其看起来处于非忙碌状态。因此，在此时，客户操作系统可能会尝试发送自己的I/O请求。为了防止与客户操作系统发生冲突，设备中介器会拦截该请求并将其排队。在来自VMM的请求完成后，设备中介器停止模拟设备状态，并将已排队的请求发送到设备。

设备共享还会导致中断方面的另一个问题。由于难以获取客户机操作系统分配的中断号，设备中介器无法准确检测到由虚拟机监视器（VMM）请求所产生的中断。此外，由于中断控制器未被虚拟化，发往虚拟机监视器的中断也会被传递给客户机操作系统。尽管设备驱动程序可以安全地忽略未知中断以支持中断共享，但仍应避免额外的中断传递以保持可移植性。因此，设备中介器会临时禁用中断，并通过细粒度调度的轮询线程来检测请求的完成情况。此过程的详细信息在第4.1节中描述。

3.3 后台复制

为了用操作系统镜像填满整个本地磁盘，虚拟机监视器在后台主动获取空块的数据。由于检索和磁盘写入速率会有所不同，虚拟机监视器使用一对线程，获取线程和写入线程thread，它们通过一个先进先出队列连接。获取线程从服务器检索空块的数据并将其推送到队列中。写入线程随后从队列中弹出数据并写入本地磁盘。虚拟机监视器按逻辑块地址从低到高的顺序填充块。然而，为了最小化寻道，如果客户操作系统访问了磁盘，虚拟机监视器会更改与最后访问块相邻的地址。

在具有多个请求队列的设备中，如果本地磁盘由 VMM和客户操作系统共享，则可能会出现一致性问题。为了说明此问题，让我们考虑以下示例。VMM尝试填充一个空块并向服务器发送请求。在响应到达之前，客户操作系统向同一磁盘块发出写请求。在这种情况下，来自客户操作系统的数据是最新的，应保留在本地磁盘中。然而，响应在客户操作系统的写入之后才到达；因此，简单地以先进先出的方式将写请求放入队列会破坏一致性。为缓解此问题，VMM持有一个位图来管理每个磁盘块的状态，并原子性地检查状态，以防止VMM向已填充的磁盘块写入数据。在关机和重启的情况下，VMM将位图保存在本地磁盘上。VMM使用本地磁盘上的未使用区域（例如两个分区之间的未分配空间）来保存位图。为了保护位图不被客户操作系统访问，VMM通过将其转换为对虚拟扇区的读取访问来阻止对该区域的访问。

为了避免性能干扰，应适度控制后台复制速度。如果写入频率过高，客户机存储性能会显著下降；如果过低，则部署阶段耗时较长。为解决此问题，虚拟机监视器根据客户操作系统负载以及三个可配置参数：客户I/O频率阈值、VMM写入间隔和VMM写入暂停间隔来调整写入频率。当磁盘I/O频率高于客户I/O频率阈值时，虚拟机监视器将等待由VMM写入暂停间隔指定的时间；否则，虚拟机监视器将以VMM写入间隔指定的时间间隔写入块。

由于这种调节，虚拟机监视器在操作系统启动期间不会执行过多的后台复制操作。作为一种优化技术，我们可以配置调节功能，通过后台复制操作预取操作系统启动所需的磁盘区域，这可能会缩短操作系统启动时间。然而，我们并不假设这种预取信息是普遍可用的。

3.4 去虚拟化

为了便于去虚拟化，我们直接将物理硬件暴露给客户操作系统。例如，所有物理CPU核心和I/O设备（包括 PCI设备和中断控制器）以及其他硬件功能（如高级配置与电源接口）都会暴露给客户操作系统。内存地址空间是恒等映射的；客户机物理地址与机器物理地址相同。然而，虚拟机监视器必须分配其自身的内存区域并防止客户机操作系统访问它。因此，虚拟机监视器通过操控BIOS功能来保留该内存区域，以确保客户操作系统不会分配该区域。虚拟机监视器还使用嵌套分页来防止客户操作系统意外损坏该内存区域。

在去虚拟化阶段，虚拟机监视器会关闭嵌套分页以消除分页开销。此时，虚拟机监视器需要在所有CPU上使 TLB失效。然而，由于虚拟机监视器不管理中断控制器，因此无法使用处理器间中断（IPI）进行TLB清除。幸运的是，在虚拟机监视器的整个生命周期中，页面映射保持不变（始终为恒等映射），不会导致CPU之间的一致性问题。因此，虚拟机监视器不再需要同步所有CPU的TLB失效时序。每个CPU可以在不同的时间点独立地使TLB失效并关闭嵌套分页。在所有CPU都禁用嵌套分页后，虚拟机监视器终止虚拟化。

4. 原型实现

在本节中，我们描述了我们的原型实现。首先，我们介绍了 CPU虚拟化和网络存储协议。然后，我们讨论了实现状态。

4.1 CPU虚拟化

我们假设中央处理器配备了硬件辅助虚拟化功能（Intel VT‐x 或 AMD‐V）。为了最小化开销，我们尽可能让中央处理器运行客户操作系统，仅在发生最低必要事件时才切换到虚拟机监视器。从客户操作系统切换到虚拟机监视器的过程称为虚拟机退出。

我们确定了几个需要触发虚拟机退出的事件。为了实现I/O中介，针对存储设备的程序化I/O和内存映射I/O指令需要触发虚拟机退出。为了检测启动过程，启动IPI和INIT信号需要触发虚拟机退出。为了检测客户操作系统分页及处理器模式的变化，控制寄存器0（CR0）中的位（PE、ET、WP、AM、NW、CD、PG）以及控制寄存器4（CR4）中的位（PSE、PAE、PGE、VMXE、SMXE、PCIDE、SMAP、SMEP）发生变化时也应触发虚拟机退出。为了在内存映射I/O上触发虚拟机退出，虚拟机监视器使用嵌套分页（Intel VT‐x上的EPT或AMD‐V上的NPT），并保持目标内存区域未映射。为了引发其他虚拟机退出，虚拟机监视器会配置用于控制虚拟机的数据结构（Intel VT‐x上的VMCS或AMD‐V上的VMCB）。需要注意的是，CPUID指令无条件地导致虚拟机退出；不过，该指令执行频率较低。

为了在I/O中介中轮询设备，虚拟机监视器需要被定期调度。借助Intel VT‐x，我们利用preemption timer来调度线程。抢占定时器由最新的Intel CPU支持，可无条件地在指定间隔触发虚拟机退出。它允许以中央处理器时钟周期为粒度，对虚拟机退出的时间进行细粒度控制。轮询间隔根据最近的平均网络往返时间和I/O延迟时间进行估算。这种方法实现了合理的性能。如果抢占定时器不可用能够实现时，虚拟机监视器会在硬件中断上启用虚拟机退出，并使用类似于软定时器的技术[16]。

4.2 网络存储协议

虚拟机监视器需要使用网络存储协议将I/O请求重定向到服务器。为了减少开销并提高透明性，应选择一种能够以最小 effort 实现I/O请求到网络数据包转换的协议。因此，文件级协议（如NFS和CIFS）并不合适，而块级协议更为可取。

我们扩展了与ATA设备亲和性更高的AoE协议 [43],，尽管也可以使用其他协议。该协议具有一个包含设备寄存器字段的头，虚拟机监视器可轻松将设备寄存器的值转换为AoE头。待读取的数据作为带有该头的数据包的有效载荷进行传输。如果传输的数据过长而无法放入单个以太网数据包中，虚拟机监视器会将数据拆分为多个AoE片段。在这种情况下，虚拟机监视器会在 AoE头中设置标签字段，以确定接收到的片段的偏移量。

为了提高性能，我们修改了AoE协议以支持巨型帧，并增加了重传功能来容忍丢包。我们使用vblade[15]作为AoE服务器实现的基础。然而，原始的vblade由于是单线程的，在虚拟机监视器发送大量读取请求时无法充分利用网络带宽，成为性能瓶颈。因此，我们在vblade中实现了线程池。

4.3 实现状态

我们基于BitVisor [46] 实现了一个原型VMM。它支持配备 Intel VT‐x或AMD‐V CPU的x86环境。我们在VMM和服务器中实现了针对IDE和AHCI磁盘控制器的设备中介器，以及 AoE协议的扩展版本。我们确认该VMM能够在无需修改操作系统的情况下部署Windows（Vista、7、8.1、Server 2008）和Linux（Ubuntu 10.04及更高版本，CentOS 6.3 及更高版本）。

IDE设备中介器的大小为1,472代码行数，AHCI设备中介器的大小为2,285代码行数。我们假设可以使用专用的网络接口卡进行流式操作系统部署，以避免性能干扰。因此，我们为Intel PRO/1000、X540、Realtek 816x和Broadcom NetXtreme网络适配器实现了小型网络驱动程序。由于我们仅需实现通过轮询收发数据包的最基本功能，因此实现成本较低：PRO/1000驱动程序为718代码行数，X540驱动程序为614代码行数，RTL816x驱动程序为757代码行数，NetXtreme驱动程序为620代码行数。我们的实现在 BitVisor 1.4的基础上进行，仅对BitVisor的核心修改了 3,576代码行数。虚拟机监视器的总大小约为27 KLOC。在添加新设备的设备中介器时，无需修改虚拟机监控器核心。

我们当前的实现存在一些限制。首先，用于虚拟机监视器的内存区域（目前为128 MB）在去虚拟化后不会释放回客户操作系统。我们可以通过实现内存热插拔功能来缓解这一问题。其次，我们向客户操作系统隐藏了硬件辅助虚拟化功能，因为我们尚未实现嵌套虚拟化。然而，已知嵌套虚拟化是可以实现的 [20]。第三，我们尚未完全支持 VMXOFF（禁用虚拟机监视器模式）。

为了支持VMXOFF，我们需要在虚拟机退出时执行以下操作：发出VMXOFF指令，将内存中保存的客户机 CPU状态（VMCS或VMCB）直接恢复到真实CPU上，而不使用虚拟机进入操作，并跳转到引发虚拟机退出的指令处。由于在VMXOFF时虚拟机监视器上下文已经丢失，因此这些操作必须在客户上下文中执行。因此，我们需要在客户上下文中映射的内存页来完成这些操作。我们确认可以通过客户内核模块的支持来实现这一点（但在性能评估中未使用）。然而，理论上也可以通过其他方式实现，而无需客户操作系统支持，例如使用设备PCI BAR（基地址寄存器）的一个额外页面[27]。因此，这些限制并非本质性的，我们计划在未来版本中实现它们。

专用NIC不会明确地释放回客户操作系统。然而，如果客户操作系统在去虚拟化后尝试检测该NIC，则可以发现它。如果专用NIC连接到管理网络，并且出于安全原因不应暴露给客户操作系统，则虚拟机监视器应继续存在而不执行VMX‐OFF，并隐藏该NIC的PCI配置空间。由于正常的（非恶意的）客户操作系统不会尝试访问此类隐藏的NIC，其开销可忽略不计。

提高裸金属云中的敏捷性和弹性

5. 性能评估

在本节中，我们展示了评估BMcast性能的实验结果。首先，我们展示测量操作系统启动时间的结果，以证明 BMcast实现了裸金属实例的快速启动。其次，我们解释数据库基准测试的结果，以证明BMcast实现了低开销流式部署和最终的裸金属性能。第三，我们展示 MPI基准测试的结果，以显示BMcast在集群环境中的性能。第四，我们展示内核编译基准测试的结果，以说明BMcast的整体性能。第五，我们展示微基准测试的结果，以揭示对线程、内存、存储和网络性能的影响。最后，我们展示后台复制的调节行为。

我们使用了一个机器集群（实际中原本用于高性能计算应用），每台机器均为富士通PRIMERGY RX200 S6，配备两颗Intel Xeon X5680处理器（3.33 GHz， 2 × 6核，禁用超线程）、96 GB内存、一块Mellanox MT26428 InfiniBand卡（4X QDR）和一块希捷Constellation.2 ST9500620NS（500GB/7200转每分钟）SATA硬盘。此外，还配有两块英特尔82575EM千兆网卡，其中一块专用于虚拟机监视器。这些机器通过一台FUJITSU SR‐S348TC1千兆以 太网交换机（最大传输单元（MTU）为9000字节）和一台 Mellanox Grid Director 4036E InfiniBand交换机连接。在所有实验中，我们部署了Ubuntu 14.04和Linux内核3.13.0。作为对比，我们使用了带ELI补丁[1]的KVM（Linux内核3.9.0）。

5.1 操作系统启动时间

我们首先评估了操作系统启动时间。我们测量了在裸金属机器（Baremetal）和BMcast（BMcast）上实例的启动时间。作为对比，我们还测量了通过iSCSI进行镜像复制的时间（ Image Copy）。此外，我们测量了使用NFS的网络启动时间（NFS Root），以及在KVM上使用通过NFS或iSCSI传输的磁盘镜像启动客户操作系统的启动时间（KVM/NFS和 KVM/iSCSI）。在所有实验中，我们使用了千兆以太网和 32GB操作系统镜像。

图4显示了实验结果。在我们的机器上，固件初始化耗时133秒，裸金属机器上的操作系统启动耗时29秒。在 BMcast上，裸金属实例的启动时间为63秒（包括5秒的虚拟机监视器启动时间）。另一方面，镜像复制耗时544秒 （其中通过网络启动安装程序操作系统耗时50秒，传输磁盘镜像耗时320秒，重启耗时145秒，从本地磁盘进行操作系统启动耗时29秒）。因此，BMcast启动裸金属实例的速度比镜像复制快8.6倍（不包括首次固件初始化）或快 3.5倍（包括首次固件初始化）。

镜像复制中的网络传输速率约为100 MB/sec，受限于千兆以太网的带宽。因此，在这种情况下使用固态硬盘不会加快镜像复制速度。使用更高速的网络，如 InfiniBand或10Gbit以太网，可能会减少传输时间。然而，当同时启动多个实例时，存储服务器的性能将达到饱和，传输时间不会显著减少。另一方面， BMcast仅传输了72MB的数据，在58秒内启动操作系统并加载磁盘镜像，平均速率为 1.2 MB/s。这意味着同时启动的实例数量仍有提升空间。因此，即使使用固态硬盘或更高速的网络， BMcast仍将保持快速启动时间的优势。

在图4中，网络启动的操作系统启动时间为49秒，略快于BMcast。但网络启动并未将操作系统镜像部署到本地磁盘，在数据库工作负载中持续产生开销。KVM自身启动耗时30秒。如3.1节所述，BMcast的 VMM设计为快速启动，其启动时间（5秒）比KVM快 6倍。KVM上客户操作系统的启动时间在NFS情况下为 42秒，在iSCSI情况下为55秒。BMcast上操作系统的启动时间为58秒，与iSCSI情况相当。此外，当比较包含VMM启动时间在内的总启动时间时，BMcast分别比使用NFS和iSCSI的KVM快1.14倍和1.35倍。

从这些结果中，我们确认了BMcast实现了裸机实例的快速启动。

5.2 数据库基准测试

为了评估部署和去虚拟化阶段的性能，我们模拟了一种场景：用户启动一个带有NoSQL数据库的新实例，该实例向客户端提供数据，并追踪了性能的变化。我们测试了两种在云中广泛使用的数据库： mem-cached和Cassandra[33]。memcached 是一种内存数据库，通常用于改善读密集型工作负载的数据服务延迟。Cassandra 是一种支持高吞吐量写入访问的数据库，适用于更新密集型工作负载。这两种数据库均设计为可扩展的，可根据需要处理的数据量跨越多个实例。我们使用 Yahoo! 云计算服务基准（YCSB）[23]进行性能评估，该基准从另一个实例持续向数据库实例发送请求。对于 memcached，我们模拟了一个读取占比95%、写入占比5%的读密集型工作负载；对于 Cassandra，则模拟了一个读取占比30%、写入占比 70%的写密集型工作负载。我们创建了一个配置好数据库的 32GB操作系统镜像。

图5显示了memcached和Cassandra基准测试的吞吐量和延迟结果。每张图中的横轴表示YCSB测试开始后 的经过时间，纵轴表示相对于裸金属机器上的平均性能的比率。我们在BMcast上执行了基准测试，分别在流式操作系统部署进行时、去虚拟化后（BMcast），以及在具有InfiniBand网卡直通访问和半虚拟化存储设备的 KVM实例上（KVM）进行。需要注意的是，KVM未执行流式操作系统部署，且没有产生设备共享的开销。

在memcached基准测试中，即使BMcast处于部署阶段并执行后台复制，其性能也略优于KVM。平均吞吐量为34.6千事务每秒（KT/sec）。在BMcast上，性能达到裸金属性能的94.8%，是 KVM性能的102%（见图5a）。BMcast上的平均延迟为 291 µ秒，比裸金属性能慢7%，但比KVM性能快 14.8%（见图5b）。BMcast导致性能下降的主要原因是TLB污染；由于嵌套分页的二维页遍历，TLB缺失次数增加了多达 5倍，且TLB缺失时的延迟翻倍。BMcast还消耗了总 CPU时间的6%：其中5%用于操作系统流式部署中的线程处理，1%用于虚拟机监控器核心本身。

在memcached基准测试中，部署阶段耗时16分钟。因此，在图5a和图5b中，经过990秒后，吞吐量增加，延迟降低；吞吐量达到36.4 KT/sec，延迟降低至 281 µsec，与裸金属性能相同。在阶段切换期间没有出现暂停或性能下降。因此，我们确认BMcast实现了无缝去虚拟化和最终裸金属性能。

在部署阶段，BMcast上Cassandra基准测试的性能略低于memcached基准测试。平均吞吐量为51.4 KT/sec，达到裸金属性能的91.4%，KVM性能的98.7%（见图5c）。BMcast上的平均延迟为2,609 µsec，比裸金属性能慢7%，比KVM性能慢3%。高于KVM性能（见图5d）。部署阶段耗时17分钟（ 1020秒），比memcached基准测试更长，因为 Cassandra基准测试是写密集型的。然而，在去虚拟化后，BMcast上的吞吐量增加到60.0 KT/sec，延迟降低至2,443 µsec，几乎与裸金属性能相同。

5.3 MPI基准测试

为了评估BMcast对集群计算性能的影响，我们运行了基本 MPI操作的微基准测试。我们使用的集群由10台通过 InfiniBand交换机连接的机器组成，操作系统配置为使用MPICH2。我们使用OSU微基准测试[6]并测量了所有机器间MPI集合通信的延迟。我们在所有操作系统均在 BMcast上运行的集群中进行了测试（BMcast）。我们还进行了所有操作系统均在KVM上运行的相同测试（ KVM）。我们将结果与裸机集群上的结果进行了比较。

图6显示了测试结果。虽然BMcast上的大多数结果与裸机上的结果几乎相同，但KVM在许多测试中引入了较大的开销。在全收集操作中，KVM上的延迟是裸金属机器上的 235%，而BMcast上的延迟与裸机几乎一致。在全归约操作中，BMcast引入了22%的开销，而KVM引入了35%的开销。我们推测InfiniBand的延迟开销（见第5.5.3节）是导致 MPI基准测试中出现严重开销的主要原因。

5.4 内核编译基准测试

为了说明BMcast的整体性能，我们使用了kernbench，该工具通过最小配置（allnoconfig）并使用12个并行任务 （make ‐j 12）编译Linux内核版本2.6.32，并在裸金属机器（Baremetal）、BMcast的部署阶段（Deploy）、 BMcast去虚拟化后（Devirt）以及KVM（KVM）上测量总的经过时间。

基准测试结果如图7所示。在裸金属机器上，内核编译耗时约16秒。在操作系统部署过程中，BMcast使编译时间增加了8%。产生此开销的主要原因是客户操作系统与虚拟机监视器通过I/O多路复用共享存储设备所带来的成本。然而，由于第3.3节中描述的后台复制的调节机制有效，其性能影响有限。KVM（KVM）使编译时间增加了3%。该结果未包含流式操作系统部署的开销，因为KVM未执行此操作，因此这完全是KVM的虚拟化开销。在BMcast上去虚拟化后，编译时间与裸金属机器上的时间相同。这些结果表明，后台复制的调节是有效的，且去虚拟化具有降低虚拟化开销的优势。

5.5 微基准测试

我们进行了三项微基准测试，以测量线程、内存、存储和网络性能。

5.5.1 线程和内存基准测试

为了评估对线程和内存性能的影响，我们使用了 SysBench[11]。线程基准测试在多个线程中对8个互斥锁重复执行1000次获取‐让出‐释放操作，并测量平均执行时间。我们将线程数量从1个增加到24个。内存基准测试重复分配内存块并向该内存块写入数据，直到写入的总数据量达到1兆字节。我们将内存块的大小从1 KB调整到16 KB。我们在裸金属机器（Baremetal）、 BMcast的部署阶段（Deploy）以及KVM（KVM）上执行了这些基准测试。我们配置KVM使用处理器绑定以避免虚拟处理器调度的开销，并使用2 GB大页内存以减少嵌套分页的开销。

图8显示了线程基准测试的结果。随着线程数量的增加，KVM的开销显著上升（在24个线程时达到68%）。我们推测这种开销是由锁持有者被抢占问题[47]引起的；持有锁的线程从虚拟CPU上被调度离开后，其他线程必须等待该线程重新被调度回来。这种虚拟化开销可能对高并发应用造成严重影响。另一方面，即使在进行流式操作系统部署时，BMcast也仅引入了适中开销（在24个线程时为6%）。其原因是BMcast仅捕获流式操作系统部署所需的最少事件，因此虚拟机退出的发生频率远低于传统虚拟机监控器。

图9显示了内存基准测试的结果。在BMcast上的吞吐量仅产生了6%的开销，而KVM在16‐KB块大小下产生了 35%的开销。我们推测这种开销是由嵌套分页的代价以及虚拟机监视器（包括宿主操作系统）引起的缓存污染所导致的。这些结果证实了BMcast在部署期间对线程和内存性能产生的开销较低。需要注意的是，在去虚拟化之后，BMcast在两个基准测试中的性能与裸机情况完全相同。

5.5.2 存储基准测试

为了评估对存储性能的影响，我们测量了客户操作系统上磁盘访问的吞吐量和延迟。为了测量存储吞吐量，我们使用了灵活的IO测试器（fio）[13]，并使用直接I/O和Linux原生异步I/O引擎（libaio）以1兆字节的块大小读取200兆字节的数据。为了测量存储延迟，我们使用了ioping [14]，以4千字节的块大小读取1兆字节的数据100次。我们在裸金属机器 （Baremetal）、BMcast的部署阶段（Deploy）以及去虚拟化后的BMcast（Devirt）上测量了性能。作为对比，我们还在网络启动的操作系统（Netboot）、使用本地磁盘的 KVM上的客户操作系统（KVM/Local）以及使用NFS的 KVM上的客户操作系统（KVM/NFS）上测量了性能。

图10显示了读写吞吐量。在裸机上，读取和写入吞吐量分别为116.6兆字节/秒和111.9兆字节/秒。在部署情况下，读取吞吐量下降了4.1%，而去虚拟化情况下下降了1.7%。写入吞吐量几乎与裸机情况相同。该结果表明，后台复制中对速度的调节起到了有效作用。去虚拟化实现了几乎等同于裸金属性能的水平。另一方面，KVM在KVM/本地环境下使读取吞吐量降低了 10.5%，在KVM/NFS环境下降低了12.3%；写入吞吐量在KVM/本地环境下降低了13.6%，在KVM/NFS环境下降低了15.3%。这些开销主要由虚拟I/O设备引起。

图11显示了存储延迟。在部署情况下，BMcast使平均延迟增加了4.3毫秒。这一增加是由于访问存储设备时的阻塞时间所致。如第3.2节所述，当虚拟机监视器处理 I/O请求时，来自客户操作系统的请求会被排队并阻塞。该阻塞时间被测量为延迟开销。然而，在去虚拟化情况下，没有出现延迟开销（实际上由于某种未知行为甚至略微更快）。在这种情况下，除了CPUID之外没有任何指令触发虚拟机退出。CPUID引发的虚拟机退出间隔为几秒到几分钟，其开销可忽略不计。这些结果证实了BMcast实现了最终的裸机存储性能。

5.5.3 网络基准测试

为了评估对网络性能的影响，我们测量了原始 InfiniBand吞吐量和延迟。我们使用了Open Fabrics Enterprise Distribution的ib rdmabw和ib rdma lat命令，这些命令发送64千字节数据包1000次，并测量通过InfiniBand进行远程直接内存访问（ RDMA）的吞吐量和延迟。我们在裸金属机器（ Baremetal）、BMcast的部署阶段（Deploy）、 BMcast去虚拟化后（Devirt）以及使用直接设备分配的KVM（KVM/直连）上测量了性能。

图12显示了吞吐量，图13显示了延迟。在我们的环境中，没有差异在吞吐量方面，此时CPU利用率非常低。这意味着网络已饱和，而虚拟化开销被RDMA硬件的命令队列所掩盖。然而，KVM使延迟增加了23.6%。其原因可能是英特尔输入/输出内存管理单元（IOMMU）的开销、缓存污染以及嵌套分页所致。这种开销在对延迟敏感的应用中成为一个显著问题。另一方面，BMcast带来的开销可忽略不计（小于1%）。因此，这些结果证实了BMcast在InfiniBand环境中实现了裸金属性能。

5.6 BackgroundCopy的调节

在部署阶段，BMcast通过调整每次块写入之间的间隔来调节后台复制速度。为了明确该间隔与客户机操作系统存储性能之间的关系，我们测量了客户机操作系统的读/写吞吐量以及VMM的写入吞吐量，同时改变 VMM写入的间隔。VMM写入的块大小为1024 KB。

图14a展示了客户机操作系统读取吞吐量与VMM写入吞吐量之间的关系。图14b展示了客户机操作系统的写入吞吐量与VMM写入吞吐量之间的关系。在两个图表中，最左边的条形表示裸金属吞吐量（Bare‐metal）。我们将VMM写操作的间隔时间从1秒开始指数级地减少到1µ秒，最终VMM以无间隔方式发出写请求（全速）。随着VMM写入间隔的缩短，客户机吞吐量逐渐下降，而VMM写入吞吐量逐渐增加。在任何情况下，两者吞吐量之和均未达到裸金属吞吐量，因为VMM采用了基于轮询的存储访问方式，且客户操作系统和 VMM写入磁盘的不同区域，增加了寻道开销。然而总体而言，总性能相当合理，表明在VMM中调整写入间隔是调节后台复制速度的一种有效方法。

6. 讨论

专用与共享网卡

我们决定为虚拟机监视器使用专用 NIC以通过网络传输操作系统镜像。然而，通过使用设备中介器与客户机操作系统共享网卡在技术上是可行的。为了共享网络接口卡，我们创建了环形缓冲区的影子版本。影子环形缓冲区由虚拟机监视器维护，并将指向这些缓冲区的指针设置到物理网络接口卡。客户机环形缓冲区由客户机操作系统的设备驱动程序维护，其内容由虚拟机监视器复制到影子环形缓冲区中，或从其中复制出来。为了在缓冲区更新时执行复制操作，虚拟机监视器对网络接口卡中环形缓冲区的头指针和尾指针寄存器进行虚拟化。虚拟机监视器将其自身的网络请求与来自客户机操作系统的请求交错插入到影子环形缓冲区中，以实现网络接口卡的共享。大部分网络接口卡上的维护操作由客户机设备驱动程序完成，而虚拟机监视器仅需执行最少的虚拟化操作。当客户机设备驱动程序正常工作时，此方法是有效的。

在操作系统启动阶段（网络设备驱动程序尚未初始化）以及关机阶段（驱动程序已终止）时，虚拟机监视器必须使用其自己的设备驱动程序来处理网络接口卡。在虚拟机监视器设备驱动程序与设备中介器之间切换时存在一些复杂性。由于初始化和终止操作会使网络接口卡停止工作，除非进行虚拟化，否则虚拟机监视器将无法使用网络，因此在客户机设备驱动程序执行初始化和终止期间，虚拟机监视器必须临时对网络接口卡进行虚拟化。然而，可以通过部分虚拟化某些硬件寄存器来处理这种情况。我们已经为Intel PRO/1000和 Realtek RTL8169实现了设备中介器。共享网络接口卡的另一种可能方法是利用单根I/O虚拟化的虚拟功能。

然而，我们并未选择使用共享网络接口卡，主要是出于性能方面的考虑。例如，在虚拟机监视器中使用设备中介可能会增加客户机网络性能的延迟和抖动。这类网络性能下降对于裸机云应用是不可取的，因为网络往往是这类应用性能的关键路径。此外，如果应用程序频繁访问本地存储，客户机网络吞吐量可能会显著降低，因为客户操作系统和虚拟机监视器会争夺共享网络接口卡的网络带宽。另外，如上所述，在虚拟机监视器中结合使用设备中介器和驱动程序会使实现略微复杂化。由于现代服务器机器普遍配备多个网卡，我们认为使用专用 NIC是一个合理的设计选择。

操作系统透明性 v.s. 实现成本

可能会有人持反对意见，认为不应以支付设备中介的实现成本为代价来提供操作系统透明性。我们在此强调，提供操作系统透明性非常重要。如果裸金属云中使用的操作系统类型较少，云服务提供商准备预配置操作系统镜像而客户直接使用这些镜像是合理的。然而，我们认为裸金属云提供商应支持广泛的操作系统，以最大化客户的潜在收益。例如，客户可能出于性能原因希望使用研究型内核，如多内核（例如Barrelfish [19]）、微内核（例如L4[25]）或库操作系统（例如Exokernel [26]）。即使他们使用Linux或Windows，也可能希望使用这些操作系统的各种类型、版本和发行版，并深度定制其配置以充分利用裸金属云的优势。为不同实例安装和维护定制驱动程序对提供商和客户而言都是艰巨的任务。设备中介器一旦在提供商侧实现，便可使所有（众多）客户受益，从而消除此类任务。

我们还强调，实现设备中介器的成本并不高。与通用操作系统中的设备驱动程序一样，设备中介器也需要设备特定知识和实现成本。然而，设备中介器的实现比设备驱动程序更简单，因为设备中介器无需处理所有I/O操作，而只需处理与I/O重定向和多路复用相关的关键I/O操作。例如，它们基本上可以省略对设备初始化、电源管理、版本特定的琐碎配置以及错误修正的变通措施等操作的处理。

除了实现单个设备中介器的成本外，支持各种设备的成本也可能成为讨论的话题，因为每种类型的设备都必须实现相应的设备中介器。然而，我们认为这个问题并不严重，因为服务器硬件种类相较于客户端是有限的，并且软件供应商能够应对这一需求。例如， VMware ESXi 为其支持的各种服务器硬件维护着自己的一套设备驱动程序。这意味着虚拟机监视器供应商支持各种服务器硬件在实践中是可行的。

给定形式化设备规范，设备中介器的自动生成在理论上是可行的，并且是一个富有前景的研究方向。这项工作旨在以最小的开发成本覆盖各种设备。从高层视角来看，设备中介器与设备驱动程序具有相似的逻辑，因为它们都需要针对客户操作系统发出的请求执行特定于设备的操作。因此，适用于自动设备驱动程序合成的现有技术[42]也可应用于设备中介器的开发。此外，设备中介器独立于操作系统特定接口，预期可以通过更简化的方 法进行合成。

总体而言，我们认为提供操作系统透明性的优势超过了实现设备中介器的成本。

7. 结论

裸金属云是一种新兴且重要的服务，但实例的启动时间长一直是提供敏捷性和弹性的关键限制。我们提出了BMcast，这是一种配备专用可去虚拟化VMM的操作系统部署系统，支持裸机实例的操作系统透明的快速启动。BMcast通过按读复制和从服务器向本地存储进行后台复制的方式，透明地执行低开销流式操作系统部署，并在部署完成后消失。为了实现I/O设备的无缝去虚拟化，我们引入了设备中介器，其执行基于轮询的设备接口级I/O中介（I/O解释、I/O重定向和I/O 多路复用），使物理设备能够直接暴露并与客户操作系统共享。

我们基于BitVisor实现了一个支持IDE和AHCI设备的设备中介器、专用于VMM的小型网络设备驱动程序以及扩展AoE协议的网络存储协议的原型VMM。BMcast能够无需任何修改地部署Windows和Linux，并且启动数据库实例的速度比镜像复制快8.6倍。在流式部署过程中，BMcast上的数据库吞吐量与使用ELI的KVM相当。去虚拟化后，BMcast实现了零开销。因此，我们确认BMcast实现了裸金属实例的快速启动、无缝去虚拟化以及最终裸金属性能。