2008年3月4日
第6卷，第1期

网络虚拟化：打破性能瓶颈

虚拟化平台中的共享I/O已经取得了长足的进步，但性能问题仍然存在。

Scott Rixner，莱斯大学

虚拟化最近的重新流行导致其在越来越多的场景中使用，其中许多场景需要高性能网络。以服务器整合为例。网络虚拟化的效率直接影响可以有效整合到单台物理机上的网络服务器的数量。不幸的是，现代网络虚拟化技术会产生显著的开销，这限制了可实现的网络性能。我们需要新的网络虚拟化技术，以在网络密集型领域充分发挥虚拟化的优势。

为了在一组虚拟机之间共享网络接口，虚拟机监控器（VMM）必须完成两个关键任务。首先，VMM必须提供对网络接口的共享访问。这意味着虚拟机的出站网络流量必须在通过网络发送之前多路复用在一起；同样，入站网络流量必须在传递到相应的虚拟机之前解复用。其次，VMM必须保护虚拟机免受彼此的影响。这意味着不允许任何虚拟机将数据传入或传出另一个虚拟机的内存。因此，网络虚拟化的挑战在于提供高效、共享和受保护的网络接口访问。

I/O虚拟化绝不是一个新概念。IBM System/360 允许虚拟机访问 I/O 设备。事实上，System/360 的许多开创性机制至今仍在使用。目前流行的 I/O 虚拟化架构可以大致分为两类：将每个 I/O 设备私有分配给特定的虚拟机，或将特定的 I/O 设备共享分配给多个虚拟机。

私有 I/O 设备

IBM 的 System/360 是第一个广泛可用的虚拟化解决方案。System/370 扩展了对处理器和内存的虚拟化支持，但继续使用与 System/360 相同的机制进行 I/O 虚拟化。为这些系统开发的初始 I/O 虚拟化架构不允许共享访问物理 I/O 资源。相反，物理 I/O 设备（如终端）被独占地分配给特定的虚拟机。因此，每个虚拟机都需要自己的物理 I/O 设备。这些系统使用通道程序来传输数据到/从 I/O 设备。通道程序使用程序控制 I/O 在内存和 I/O 设备之间传输数据。在虚拟化系统上，通道程序在 VMM 内部执行，允许 VMM 确保虚拟机只能访问其自己的内存和设备。

最近的虚拟化系统也依赖于私有设备访问，例如 IBM 的 Power4 处理器 LPAR（逻辑分区）架构的第一个版本。Power4 架构在 PCI 插槽级别隔离设备，并将它们分配给特定的虚拟机实例进行管理。每个虚拟机都需要一个物理上不同的磁盘控制器用于磁盘访问，以及一个物理上不同的网络接口用于网络访问。

现代 I/O 设备使用 DMA（直接内存访问）而不是程序控制 I/O，因此 VMM 无法执行 I/O 数据传输。相反，Power4 LPAR 架构使用 IOMMU（I/O 内存管理单元）来限制每个设备可以访问的内存。为了以这种方式使用 IOMMU，VMM 为每个设备创建一个 I/O 页表，其中包含分配给该设备的虚拟机的页面内存映射。然后，IOMMU 为每个 DMA 操作查询相应的页表。如果设备尝试访问其 I/O 页表中没有有效映射的内存，则 IOMMU 将不允许访问。

私有 I/O 访问具有明显的优点和缺点。它产生高性能的 I/O 访问，因为每个虚拟机都可以直接与其拥有的物理设备通信。然而，这是一个昂贵的解决方案，因为它需要为每个虚拟机复制物理设备。这些设备很可能未被充分利用，并且对于具有大量虚拟机的系统，可能无法包含足够数量的设备。

共享 I/O 设备

减少提供私有 I/O 设备固有成本的好方法是允许在虚拟机之间共享 I/O 设备。第一个共享 I/O 虚拟化解决方案是 System/360 和 System/370 在物理上分离的虚拟机之间网络支持的一部分。这种网络架构支持使用虚拟化假脱机文件接口共享访问网络，该接口由专用于网络的专用虚拟机或 I/O 域提供服务。系统中的其他虚拟机可以从虚拟化假脱机文件读取或写入。VMM 将根据假脱机位置是在本地机器上还是在远程机器上来解释这些读取和写入。如果数据在远程机器上，VMM 会将控制权转移到 I/O 域，然后 I/O 域将使用其物理网络接口与远程机器传输数据。远程机器将使用相同的虚拟化假脱机架构及其自己的专用 I/O 域来服务请求。

这种软件 I/O 虚拟化架构在逻辑上与当今大多数虚拟化解决方案相同。Xen、VMware 和 Power5 虚拟化架构都通过虚拟化软件接口共享对设备的访问，并依赖于专用软件实体（例如 I/O 域）来执行物理设备管理。控制 I/O 设备的软件实体可以是单独的 I/O 域或 VMM 的管理程序。如果存在单独的 I/O 域，则 I/O 设备实际上对该域是私有的，因此设备对内存的访问应限制为 I/O 域。这可以通过信任 I/O 域或使用 IOMMU 来强制执行。

软件中的网络虚拟化

由于网络接口通常在软件中共享，因此查看此 I/O 虚拟化架构的更具体示例将是有益的。Xen 是 x86 架构上流行的开源 VMM，它在软件中共享 I/O 设备。尽管 VMM 之间存在差异，但 Xen 的 I/O 虚拟化架构代表了其他在软件中支持共享 I/O 设备的系统。

图 1 显示了 Xen VMM 的组织结构。Xen 由两个要素组成：管理程序和驱动程序域。管理程序在虚拟机和实际硬件之间提供了一个抽象层，使每个虚拟机都像在硬件上本地运行一样执行。然而，共享 I/O 设备由一个特殊的 I/O 域控制，在 Xen 中称为驱动程序域。它运行修改后的 Linux 版本，该版本使用原生 Linux 设备驱动程序来管理物理 I/O 设备。为了与驱动程序域（以及物理 I/O 设备）通信，每个虚拟机都配备了一个虚拟 I/O 设备，该设备由一个特殊的设备驱动程序（称为前端驱动程序）控制。为了访问物理设备，虚拟机的前端驱动程序与驱动程序域中相应的后端驱动程序通信。

后端网络接口驱动程序通过驱动程序域内的以太网桥连接到物理 NIC（网络接口卡）。当虚拟机传输数据包时，首先将数据包从虚拟机中的前端驱动程序复制（或重新映射）到驱动程序域中的后端驱动程序。在驱动程序域内，数据包通过以太网桥路由到物理 NIC 的设备驱动程序，然后设备驱动程序将数据包排队以在网络接口上进行传输，就像数据包是驱动程序域内的操作系统正常生成的一样。

当接收到数据包时，网络接口会生成一个中断，该中断被管理程序捕获并作为虚拟中断路由到驱动程序域中 NIC 的设备驱动程序。NIC 的设备驱动程序将数据包传输到以太网桥，以太网桥将数据包路由到相应的后端驱动程序。然后，后端驱动程序将数据包复制（或重新映射）到目标虚拟机中的前端驱动程序。数据包传输完成后，后端驱动程序请求管理程序向目标虚拟机发送额外的虚拟中断，以通知它有新数据包。接收到虚拟中断后，前端驱动程序将数据包传递到虚拟机的网络协议栈，就像数据包直接来自物理设备一样。

在 Xen 中，驱动程序域负责保护 I/O 访问。这意味着必须信任驱动程序域，以指示网络接口仅使用驱动程序域拥有的缓冲区。未来的 x86 系统将包含一个 IOMMU，管理程序可以使用它来强制执行该限制。无论如何，还必须信任驱动程序域，以仅将适当的网络流量传输到每个虚拟机。

Xen 网络虚拟化架构会产生显著的处理和通信开销。例如，Linux 在 Xen 内部只能实现大约三分之一的网络吞吐量，而在本地运行时，它可以实现全部吞吐量。这种开销并非 Xen 独有；为了在软件中启用共享 I/O 设备而必须执行的基本操作在 VMM 实现中是通用的。

共享 I/O 设备开销中经常被忽视的一个组成部分是 VMM 内的域调度。即使只有一个虚拟机，发送或接收网络数据包也涉及两个域：驱动程序域和虚拟机域。这些域必须被调度，并且以正确的顺序调度，然后才能发送或接收网络数据包。这意味着糟糕的调度决策可能会导致网络延迟增加。

通过直接在管理程序中管理共享 I/O 设备，可以消除部分调度问题。VMware ESX 和早期版本的 Xen 使用了这种方法。这消除了为传输网络数据包而调度额外的 I/O 域的需要。然而，及时调度虚拟机的域仍然是必要的，但这并非总是可能的，尤其是在多个域同时具有未完成的网络流量时。也许更重要的是，这要求网络接口的设备驱动程序直接合并到管理程序中。这否定了虚拟化经常吹捧的优势之一：从机器的可信代码库中删除经常有缺陷的设备驱动程序。由于设备驱动程序直接位于管理程序中，因此管理程序的复杂性显著增加，其可靠性也相应降低。

多队列网络接口

通常，现代网络接口包括一个发送队列和一个接收队列。发送队列保存指向出站网络数据包的指针，接收队列保存指向将用于存储入站网络数据包的空缓冲区的指针。设备驱动程序几乎完全通过这些队列与网络接口通信。

近年来，具有多组队列（有时称为多队列网络接口）的网络接口已经出现，以提高多核系统中联网性能。这些设备支持 Microsoft 的接收端缩放架构和 Linux 的可扩展 I/O 架构。这些架构允许每个核心独占访问网络接口上的一组队列之一。这使每个核心能够并发运行网络接口的设备驱动程序，而无需额外的同步。以这种方式使用多队列网络接口提高了操作系统网络协议栈内的可实现并行性，从而更有效地利用多个核心进行联网。

惠普实验室和 Citrix 的研究人员最近提出了一种使用这些多队列网络接口来提高 Xen 中网络虚拟化性能的方法。他们通过将网络接口队列直接分配给驱动程序域中的后端驱动程序，消除了驱动程序域内的以太网桥。通过这种方式，后端驱动程序可以并发地与网络接口通信，而无需同步。然后，网络接口而不是驱动程序域内的以太网桥将多路复用/解复用网络流量。为了多路复用发送网络流量，网络接口通过公平地服务于所有发送队列来交织虚拟机的网络流量。当网络接口接收到网络数据包时，NIC 使用每个数据包的目标以太网地址来识别相应的接收队列。

以这种方式使用多队列网络接口的明显好处是消除了驱动程序域内的流量多路复用开销。一个不太明显的好处是消除了驱动程序域和虚拟机之间的复制。由于每个虚拟机的网络流量都将仅通过一组队列与网络接口交互，因此驱动程序域可以指示网络接口直接与该虚拟机拥有的内存传输数据。虚拟机只需要授予驱动程序域使用其网络缓冲区的权利。

以这种方式使用多队列网络接口应通过消除在虚拟机之间软件共享 I/O 设备固有的多路复用和复制开销来提高网络虚拟化性能。然而，该技术仍然存在一些缺点。首先，驱动程序域现在必须通过确保在网络接口的特定队列上排队的缓冲区属于分配给该队列的虚拟机来保护每个虚拟机的网络流量。其次，管理虚拟机已授予驱动程序域用于联网的缓冲区存在固有的开销和复杂性。最后，前面描述的调度问题仍然存在，因为仍然必须调度驱动程序域以通过将缓冲区入队/出队和接收中断来与网络接口通信。

并发直接网络访问

CDNA（并发直接网络访问）使多队列网络接口的使用更进一步。在 CDNA 网络虚拟化架构中，管理程序直接为每个虚拟机分配其自己在多队列网络接口中的一组队列。这完全消除了 Xen 中网络中的驱动程序域。

图 2 显示了 CDNA 网络虚拟化架构。与以前一样，网络接口必须直接在硬件中支持多组队列。然而，管理程序不是将整个网络接口的所有权分配给驱动程序域，而是将每组队列视为物理网络接口，并将每组队列的所有权直接分配给虚拟机。请注意图中缺少驱动程序域：每个虚拟机都可以使用其自己的私有队列集来传输和接收网络流量，而无需与其他虚拟机或驱动程序域进行任何交互。但是，驱动程序域仍然存在以执行控制功能并允许访问其他 I/O 设备。

在 CDNA 网络虚拟化架构中，驱动程序域和虚拟机之间的通信开销完全消除。管理程序现在必须在网络接口上的队列集之间提供保护，并将中断直接传递到虚拟机。

与驱动程序域使用多队列网络接口类似，CDNA 通过在网络接口上多路复用/解复用网络流量，消除了驱动程序域内的软件多路复用开销。与以前一样，每个虚拟机都分配有一组队列和一个关联的以太网地址，以使网络接口能够执行此任务。然而，来自网络接口的中断不再传递到驱动程序域中相应的后端驱动程序。相反，它们直接传递到相应的虚拟机。

为此，管理程序必须理解网络接口由多个虚拟机“拥有”。通常，管理程序假定每个设备都由特定的虚拟机独占拥有。在 CDNA 的原型实现中，网络接口向管理程序传递一个位向量，然后生成一个物理中断。位向量中的每个位对应于网络接口上的一组队列。然后，管理程序扫描此位向量，并将虚拟中断传递到相应的虚拟机。可以使用消息信号中断来完成类似的行为，但代价是物理中断率会增加。将中断直接传递到虚拟机，而无需通过驱动程序域的中间过程，可以减少虚拟机的中断响应时间。

CDNA 网络虚拟化架构在一定程度上确实改善了调度问题。对于虚拟机发送或接收网络流量，它不需要调度驱动程序域。这提高了整体响应速度，从而提高了网络性能。然而，具有未完成网络流量的多个虚拟机的调度问题仍然存在。

尽管 CDNA 网络虚拟化架构消除了驱动程序域的开销，但它使内存保护复杂化。由于可信驱动程序域不再调节对网络接口的访问，因此虚拟机可能会指示网络接口访问任意内存位置。在 x86 架构中，这个问题尤其严重，在 x86 架构中，设备驱动程序为 I/O 设备提供物理内存地址。如果错误的或恶意的虚拟机向网络接口提供不属于其地址空间的物理地址，它可能会征用网络接口来读取或写入不属于该虚拟机的内存。

为了保证 CDNA 中的内存保护，管理程序必须执行两项任务。首先，它必须在将所有缓冲区传递到网络接口之前对其进行验证。仅当缓冲区归使用它的虚拟机所有时，管理程序才会验证缓冲区，从而确保虚拟机不会将不属于自己的缓冲区排队到网络接口。如果网络接口收到未经验证的缓冲区，则不会使用该缓冲区。其次，管理程序必须确保在网络接口上排队的任何缓冲区的所有权不会更改。在 Xen 中，内存所有权通过使用页面的引用计数来维护。在 CDNA 中，当页面内的缓冲区排队到网络接口时，页面的引用计数会递增，当缓冲区出队时，页面的引用计数会递减。这保证了页面的所有权不会更改，因为 Xen 仅在页面的引用计数为零时才允许更改页面的所有权。

虽然 CDNA 原型在软件中执行这些保护任务，但使用 IOMMU 可以简化它们。在具有 IOMMU 的系统中，管理程序将为每个虚拟机创建一个 I/O 页表，其中包含虚拟机允许用于 I/O 操作的页面的内存映射（可能包括虚拟机的全部内存）。每当内存所有权发生更改时，管理程序都会更新这些 I/O 页表。这将消除单独验证每个缓冲区和跟踪网络缓冲区所有权的需要。相反，IOMMU 将为每次网络传输查询 I/O 页表，以确保允许网络接口进行的每次内存访问。然而，为了使这项工作正常进行，IOMMU 必须能够区分网络接口代表不同虚拟机进行的内存访问。IOMMU 需要此信息来确定应为特定访问查询哪个 I/O 页表。当前的 PCI 总线实现没有为网络接口以这种方式区分其内存访问提供明显的方法，但即将到来的 PCI I/O 虚拟化规范应包含这种能力。

图 3 显示了使用 Xen 和 CDNA 网络虚拟化架构可实现的聚合带宽，因为虚拟机的数量是变化的。仅使用了两个网络接口，将带宽限制为 2 Gbps。如图所示，直接访问网络接口可带来显著的性能提升。事实上，该图低估了整体改进，因为在使用 CDNA 网络虚拟化架构时存在空闲时间。如果有系统中额外的网络接口，这些空闲处理资源可以用于实现更高的网络带宽。相比之下，在使用 Xen 网络虚拟化架构时，永远不会有空闲时间，因此这些数字显示了 Xen 的峰值网络带宽。

磁盘 vs. 网络 I/O

本文重点介绍了网络虚拟化，因为它是最复杂的 I/O 虚拟化类型。由于网络流量是未经请求的，因此与与其他 I/O 设备相比，更难以有效地共享网络接口。系统必须准备好接收和响应随时发送到任何虚拟机的网络流量。这与许多其他硬件资源的虚拟化不同，因为 VMM 对网络的使用控制较少。例如，磁盘访问的控制性更强，因为磁盘读取和写入仅在虚拟机显式请求时才会发生。

在软件 I/O 虚拟化架构（如 Xen）中，虚拟机始终可以在启动磁盘访问时为驱动程序域提供缓冲区。这消除了在虚拟机和驱动程序域之间复制（或重新映射）数据的需要。同样，网络所需的以太网桥的等效物是不必要的，因为所有磁盘读取流量的目的地都是提前知道的。因此，软件中的磁盘虚拟化本质上比网络虚拟化更简单。

此外，IBM 使用迷你磁盘和 DASD（直接存取存储设备）架构来改进磁盘虚拟化，并避免为每个虚拟机需要昂贵的专用磁盘。System/360 将磁盘分区为逻辑上分离的虚拟迷你磁盘。尽管多个虚拟机可以通过迷你磁盘抽象访问同一物理磁盘，但它们不会并发共享访问同一迷你磁盘区域。这减少了系统中所需的磁盘数量，但仍然是一种私有 I/O 访问形式，因为磁盘块无法在虚拟机之间真正共享。

System/360 和 System/370 还实现了 DASD 架构，以实现并发直接磁盘访问。如前所述，这些早期 IBM 系统中的 I/O 设备是使用程序控制 I/O 通过通道程序访问的。支持 DASD 的设备有几个单独寻址的通道，因此多个通道程序可以并行执行。然而，磁盘访问仍然是同步的，因此一次只有一个通道程序可以实际访问磁盘。额外的通道程序可以同时执行数据比较或地址计算，从而显著提高 I/O 吞吐量。在虚拟化系统上，虚拟机的通道程序将在管理程序内部运行，从而允许管理程序确保虚拟机只能访问其自己的内存和设备。

尽管这些技术提高了磁盘虚拟化性能，但它们不能直接用于现代网络虚拟化。首先，网络无法以与磁盘相同的方式进行分区，因此迷你磁盘抽象对于联网没有逻辑等效物。其次，DASD 需要为每次同步磁盘访问运行通道程序。这与异步接收网络数据包不兼容。此外，CDNA 通过允许受保护的、异步的和并发的网络访问来构建在 DASD 概念之上。

CDNA 的前景

在过去的几十年中，虚拟机监控器一直在软件中共享 I/O 设备。尽管这种软件 I/O 虚拟化架构简单而灵活，但它们创造了一个显著的网络性能瓶颈，这严重限制了虚拟化在网络密集型领域的价值。为了充分发挥虚拟化的全部潜力，我们需要更高效的网络虚拟化架构。

鉴于未经请求的网络流量的性质，直接在网络接口上执行流量多路复用和解复用是有价值的。这种能力已经显示出在提高多核系统的网络效率方面的前景。CDNA 是一种即将到来的网络虚拟化架构，它进一步利用此功能来提供使用私有网络接口的许多性能优势，而无需大量未充分利用的网络接口。这将显著提高虚拟化系统的效率，并增加每台物理机可以支持的网络密集型虚拟机的数量。

参考文献

Parmelee, R. P., Peterson, T. I., Tillman, C. C., Hatfield, D. J. 1972. 虚拟存储和虚拟机概念。IBM Systems Journal 11(2): 99–130。
Gum, P. H. 1983. System/370 扩展架构：虚拟机设施。IBM Journal of Research and Development 27(6): 530–544。
Jann, J., Browning, L. M., Burugula, R.S. 2003. 动态重配置：IBM pseries 服务器上自主计算的基本构建块。IBM Systems Journal 42(1): 29–37。
MacKinnon, R. A. 1979. 变化的虚拟机环境：与真实硬件、虚拟硬件和其他虚拟机的接口。IBM Systems Journal 18(1): 18–46。
Armstrong, W. J. Arndt, R. L. Boutcher, D. C., Kovacs, R. G., Larson, D., Lucke, K. A., Nayar, N., Swanberg, R.C. 2005. Power5 系统的高级虚拟化功能。IBM Journal of Research and Development 49(4/5): 523–532。
Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., Warfield, A. 2003. Xen 和虚拟化艺术。《操作系统原理研讨会论文集》（十月）。
Sugerman, J., Venkitachalam, G., Lim, B. 2001. 在 VMware Workstation 的托管虚拟机监控器上虚拟化 I/O 设备。《Usenix 年度技术会议论文集》（六月）。
参见参考文献 6。
Willmann, P., Shafer, J., Carr, D., Menon, A., Rixner, S., Cox, A. L., Zwaenepoel, W. 2007. 虚拟机监控器的并发直接网络访问。《高性能计算机体系结构国际研讨会论文集》（二月）。
Ongaro, D., Cox, A. L., Rixner, S. 2008. 虚拟机监控器中的 I/O 调度。《虚拟执行环境国际会议论文集》（三月）。
VMware Inc. 2006. VMware ESX 服务器：用于虚拟化服务器、存储和网络的平台；http://www.vmware.com/pdf/esx_datasheet.pdf。
参见参考文献 6。
Santos, J. R., Janakiraman, G., Turner, Y., Pratt, I. 2007. Netchannel 2：优化网络性能。Xen Summit 演讲（十一月）。
参见参考文献 9。
参见参考文献 1。
Brown, D. T., Eibsen, R. L., Thorn, C. A. 1972. 通道和直接访问设备架构。IBM Systems Journal 11(3): 186-199。
参见参考文献 2。

喜欢还是讨厌？请告诉我们

[email protected]

SCOTT RIXNER 是莱斯大学计算机科学以及电气与计算机工程的副教授。他获得了麻省理工学院电气工程博士学位，并且是成员。他的研究兴趣包括网络系统架构、内存系统架构以及操作系统和计算机体系结构之间的交互。

最初发表于 Queue vol. 6, no. 1—
在数字图书馆中评论本文

更多相关文章

Mendel Rosenblum, Carl Waldspurger - I/O 虚拟化
“虚拟”一词被过度使用，引发了从在云中运行的虚拟机到在虚拟世界中运行的化身等各种联想。即使在计算机 I/O 的狭隘背景下，虚拟化也具有悠久而多样的历史，逻辑设备就是例证，这些逻辑设备与它们的物理实例化刻意分离。

Ulrich Drepper - 虚拟化的成本
虚拟化可以通过多种不同的方式实现。它可以借助或不借助硬件支持来完成。可以期望虚拟化操作系统会发生更改以准备虚拟化，或者可以期望它在不更改的情况下工作。无论如何，软件开发人员都必须努力实现 Gerald Popek 和 Robert Goldberg 阐述的虚拟化的三个目标：保真度、性能和安全性。

Werner Vogels - 超越服务器整合
虚拟化技术在 20 世纪 60 年代后期被开发出来，目的是为了更有效地利用硬件。当时硬件价格昂贵，而且硬件资源还不太普及。计算处理业务当时主要外包给少数拥有计算机的机构。在一台 IBM System/360 主机上，用户可以并行运行多个相互隔离的环境，让每个客户都感觉像是在独占使用硬件。虚拟化技术本质上是以一种粗粒度的方式实现的分时技术，而隔离性则是这项技术的核心成就。

Tom Killalea - 会见虚拟化技术专家
当你深入挖掘那些所谓的“一夜成名”的故事时，你经常会发现它们实际上是多年积累的结果。虚拟化技术已经存在了 30 多年，早在你们中的一些人还在向物理机器中输入成堆穿孔卡片的时代就出现了，但在 2007 年，它终于迎来了爆发。VMware 成为当年 IPO 市场的轰动事件；2007 年 11 月，不少于四家主要的操作系统供应商（微软、Oracle、Red Hat 和 Sun）宣布了重要的全新虚拟化功能；而在时尚技术专家中，似乎“虚拟化”已经成为新的潮流。