背景#

虚拟化是当今数据中心和云平台的支柱性技术。无数任务以虚拟机的形式存在和运行，而一项关键技术是将一个正在运行的虚拟机从一台物理机迁移到另一台，这个过长成为虚拟机的热迁移。在大型数据中心中，热迁移在每个元中都会发生数百万次。

由于ai训练等搞性能需求工作负载的兴起，数据中心正在广泛采用RDMA作为网络信道。为了让虚拟机中运行的程序可以享受到裸金属级别的性能（即不引入中间虚拟化软件层的ewd开销），现有RDMA硬件支持PCI穿透（让虚拟机内可以通过MMIO直接与PCIe设备通信）、IOMMU（在允许DMA引擎直接访问虚拟机内存的情况下实现地址空间隔离）和SR-IOV（将PCIe资源划分到多个虚拟化设备，并将他们分配到不同虚拟机）。在这些技术的支持下，虚拟机之间可以通过RDMA进行直接通信。

挑战#

虽然PCI穿透可以极大增强虚拟机使用RDMA时的性能，但它却为虚拟机的热迁移带来了很大的挑战。

• 命名空间迁移：RDMA自己为通信相关的对象（如QP,MKey）维护了各自的ID。由于这些ID是硬件分配的，软件层无法在迁移后准确复现这个明明空间，因此必须增加一层在线ID翻译。这回引入对客户机操作系统或中间件的修改
• 在途网络报：由于传输状态只存在于RDMA设备内部，软件层必须在热迁移之前完成所有在途RDMA操作，这会极大增加迁移期间虚拟机的暂停时间
• 重建连接：热迁移后，由于地址和命名空间的变化，被迁移的虚拟机必须重建所有QP，这就意味着所有于这个虚拟机之前建立的连接都需要重建

解决方案#

本文认为，要在保证RDMA性能和最小化downtime的前提下实现热迁移一定需要设备的协助，并列出了一系列实现原则和对应的设备支持

RDMA#

• 硬件网络传输的实现（卸载任务），最小化软件开销，并支持计算与网络的独立推进
• 操作系统旁路————允许应用程序直接访问硬件，以支持数据路径操作（例如：启动数据传输并检测其完成）
• 想远程网络对等方暴露DMA，从而实现单边访问

虚拟化系统中的IO#

PCIe直通中，客户机软件可直接从虚拟地址空间访问内存映射（MMIO）区域与PCIe设备进行通信，为了使设备能够直接访问虚拟机（如DMA和中断）的同时保持隔离性，引入了IOMMU。为了实现单个PCIe设备在多个虚拟机之间的安全共享，PCIe　SR-IOV扩展允许一个物理功能(PF)创建多个虚拟功能(VF)。后端资源由PF和VF共同共享，同时每个VF都拥有独立的PCIe资源集。在Hypervisor中，VF被视为一个独立的PCIe设备，可安全地直通到目标虚拟机。

热迁移#

网络透明#

RDMA设备可能拥有数十万个已建立的连接，但同一时刻仅有一小部分处于活跃状态。在这种情况下，与所有远程对等方进行协调不仅成本高昂，而且毫无必要。此外，部分对等放可能也正在迁移。

为了应对这以问题，可对迁移计划进行全局协调。然而，这种方法需要深入了解租户的工作负责——但是云厂商并不知道——而且可能与其它流程（如滚动更新）产生冲突。此外，迁移过程本身也需要一定时间。在pre-copy阶段，已建立连接的集合可能会经历显著的变化，这使得强制保留连接的做法变得不切实际。

因此，无同步的网络透明性是实现可扩展迁移的关键。通过以下原则来实现这一目标：

DA1: RDMA命名空间的保持。RDMA命名空间包括链路层可见的QP编号和远程MR的memory key。这些值的任何更改，都需要与远程对等方进行协调。.

在目标设备上精确重建RDMA命名空间，可以消除此类协调要求，并确保迁移的虚拟机完全透明。

DA2: 本地连接保持。与RDMA命名空间(DA1)类似，设备必须精确恢复本地网络地址（即MAC/IP或者LID/GID）以及QPs的任何状态。这使得在连接生命周期的任意阶段均可实现迁移，包括连接建立和拆除过程中。

DA3: 远程连接的无缝保持。现有方法在迁移前会先断开虚拟机与其远程对等方的连接，待迁移完成后重新建立。而在这个解决方案中，则完全省区了这一步骤。然而，由于挂起的VF无法响应传入数据包，基于可靠连接的协议（TCP和IB RC传输）极易遭遇超时。尽管默认的TCP配置足以应对短暂的宕机时间，但依赖于亚秒级超时的RDMA协议却无法承受迁移操作带来的延迟。为此，采用指数回退机制来解决这一问题。最初，采用极短的超时设置，以弥补正常运行期间偶尔发生的数据包丢失现象；随后，重传之间的延迟将按指数方式逐步延长，从而从容应对迁移过程。

DA4: 以数据包粒度进入静默状态。通过耗尽通信来处理当前传输中的消息会导致做无用功，需要同步机制，并引入对网络状况的依赖（如拥塞）

相比之下，设备辅助机制允许数据包为粒度暂停处理，此时重传大小固定且可忽略不计。这种方法需要访问设备的内部状态，包括

• 当前预期的数据包序列号
• 传输op code
• 虚拟RDMA地址
• 用于重传的原子操作缓存结果

在hypervisor中访问设备状态#

hypervisor负责保存和恢复设备，确保了对虚拟机内部软件的完全透明。然而，目前尚无标准接口可用于提取VF的状态。正如虚拟机管理程序在不深入分析其内存内容的情况下高效传输虚拟机内存页一样，采用类似的方法，一次性批量获取设备状态，而非逐个遍历RDMA资源

首先，我们将讨论为什么RDMA是“带状态的设备”。

在虚拟化基础设施中的集成#

在热迁移中，通过pre-copy来隐藏大部分虚拟机状态传输的延迟。通过限制vCPU来控制虚拟机修改内存的速度，确保迁移过程的平稳。但是如果pre-copy阶段仍然无法充分减少downtime，那么可能还徐进一步引入post-copy。

DA8: pre-copy设备状态。对于具有较大状态的设备，使用pre-copy以缩短停机时间。为避免对pre-copy的轮次的持续时间产生负面影响，设备状态的增量更新不应该依赖于耗时的操作，如memory registration，连接管理和数据路径事务。

DA9: 脏速率控制。RDMA设备能够以极高的速率将虚拟机内存变脏，同时需要极低的vCPU占用。实际上，传入的RDMA写操作完全不涉及任何的vCPU。由于vCPU的限流机制不足以应对这种情况，设备必须提供一种手段来精确控制其内存访问速率。

DA10: 流水线的状态提取。虽然虚拟机内存可被hypervisor直接访问，但设备状态却无法被直接访问，必须显式的将其保存并加载到设备中。因此，设备镜像必须包括

1. 从源VF获取镜像
2. 把镜像传输到目标系统上。
3. 在目标VF上加载镜像。

对于RDMA,镜像的大小取决于所分配的RDMA资源数量，可能高达百MB，并会随着各阶段时间的线性增加而延长整体处理时间。通过流水线化，可以降低整个镜像传输的时间消耗。

在pre-copy的早期阶段，也可以考虑引入流水线。

DA11:(optional) post-copy的支持。如果想要支持post-copy，那么需要设备支持page fault。从设备视角来看，普通的page fault(本地)与由于post-copy造成的page fault是没有区别的。

但是由于hypervisor必须要能够支持post-copy带来的page fault，那么必须通过类似于vCPU的方式一样来实现。 总而言之，本文没有实现。

单设备的一致性#

设备驱动程序依赖于PCIe排序规则来推断一致性问题。PCIe定义了两种类型的事务：posted和non-posted，他们分别生成相应的事务层数据包(TLP)。non-posted的请求TLP（如内存读和原子操作）会返回一个完成TLP，而posted的请求（如内存写入）不会返回一个完成TLP。

一般来说，对于标准（非宽松）事务，posted请求之间无法相互绕过，但可能绕过non-posted请求和完成操作。non-posted请求和完成操作在彼此之间是无序的，但不允许绕过posted请求。

由于一个posted请求的TLP无法被绕过，它会自动刷新其路径上的所有其它TLP。例如，网卡同城通过写入通知消息来向所有软件告知有新数据的到来，而这以操作也会同时刷新相应的有效载荷。我们采用双向的PCIe内存写操作来实现挂起命令：驱动程序通过MMIO向设备发送挂起请求，随后设备通过DMA将挂起响应报告回宿主机内存。

设备必须在有限时间内完成所有待处理的命令，并根据需要掌握新的内存事务。

多设备的一致性#

然而，独立地将流程应用于多个设备，并不足以实现状态的一致性，。当两个活多个虚拟功能通过PCIe交换机直接通信时，这些虚拟功能将无法被连续挂起。这是因为，处于挂起状态的虚拟功能仍可能受到来自其活动PCIe对等设备的事务。然而，这些事务无法被挂起的虚拟功能正确处理，因为他们会修改虚拟功能的状态，并可能需要完成操作。

DA12: 两阶段挂起于恢复。为确保一致性，挂起和恢复操作必须分为两个阶段————主动阶段和被动阶段，并由各自独立的命令执行

• suspend-active: 指示设备停止接管新的DMA事务，并完成所有正在进行的non-posted事务。显然，之前已posted的事务可能仍处于in-flight状态。除此之外，设备仍可作为功能正常的PCIe目标设备。在处理传入事务的同时，选择性地更新内部状态。
• suspend-passive: 锁定设备状态，使其进入准备保存为镜像的模式。在此之后，任何传入事务的结果是未定义的。
• resume-passive: 将设备恢复到suspend-active状态
• resume-active: 完全恢复设备

1
// algorithm 1: VM-stop-and-copy
2
// input: set of physical device descriptors
3
// state of the suspended VM
4
HV_SuspendVMvCPUs()
5

6
for dev in devdesc:
7
  Suspend(ACTIVE, dev)
8
end
9

10
for dev in devdesc:
11
  Suspend(PASSIVE, dev)
12
end
13

14
HV_SendVM_State()
15

16
for dev in devdesc:
17
  HV_SendDevState(dev)
18
end

以上就是挂起流程的算法。其中,hyervisor的功能都带有前缀HV，与设备迁移API区分开来。首先，vCPU被挂起，以确保客户机软件不会发起任何请求。然而，虚拟机内存仍可能受到设备的修改。接下来，将设备切换到suspend-active状态，确保其不会像内存活其它设备发起新的事务。所有设备都进入suspend-active阶段后，方可进入suspend-passive状态。

接下来，虚拟机的状态（即自上一轮pre-copy依赖被修改的vCPU执行状态和内存页）被传输到目标端，随后是设备镜像。

虚拟机恢复的步骤与上面相反。

以上提出的两部阶段方案也适用于其它内存架构设备，例如一个支持以下功能的NVLink:

• 在继续作为目标设备响应的同时，暂停新事务的发起
• 检测正在进行中的事务是否已完成

使PCIe架构暂停#

虽然算法1给出了设备挂起顺序的概要，但它并未明确指出所有正在进行中的事务必须在设备被置于挂起-活动状态之前到达这些设备。

PCIe架构可以被表示为一个树$T=(V, E)$，其中节点$V$对应于结构中的各个组件，而边$E$对应于连接这些组件的链路。树的根$r \in V$代表PCIe架构的根。叶子节点$d = \{ \forall v \in V : deg(v) = 1 \}$代表设备，而非叶子节点代表交换机。给定两个顶点$A, B \in \{r, D\}$，我们用$P_{AB}$表示A到B的路径。

设备之间的事务可能遵循两种可能的路径: (1)经由根节点的遍历（由于IOMMU转换活跨根端口操作）。(2)直接在同一个根端口下的设备之间进行（利用缓存的转换信息）。

假设在完成了激活命令后，设备$A, C \in D$有一些正在进行的posted事务发送给了B，表示为$\omega _{AB}$和$\omega_{AC}$。使用$\rho _{AB}$和$\rho _{CB}$表示来自A和C的suspend-active响应回复。而相应的，发送给B的suspend-passive请求表示为$\pi_{rB}$

令$X$为A和B的最小公共祖先(LCA)。在suspend-active阶段，因为$X \in P_{AB}$，$\rho_{Ar}$刷新$\omega_{AB}$到$X$，把$\omega _{AB}$放入X面向B的出端口。类似的，$\rho _{Cr}$刷新$\omega _{CB}$到$r$，因为他们都在路径$P_{Cr}$上，并把$\omega_{CB}$置于r的面向B的转发出口上。在suspend-passive阶段，$\pi_{rB}$遍历$P_{rB}$，同时刷新了到B的$\omega _{AB}$和$\omega_{CB}$。最终，B执行suspend-passive命令，并且所有的in-fligh事务都已经被B知道了。

ConnectX-7 overview#

包含一个PCI接口一个或多个RDMA物理接口，以及一组代表RDMA网卡的PCIe功能，同时还颇为被一个嵌入式交换机，用于在这些功能于端口之间路由数据包。于特定RDMA虚拟功能相关的状态分布于这些组件之中。

PCIe State（包括通用配置空间，MSI-X，错误处理及其它功能）由PCIe规范定义。在迁移过程中，虚拟机管理器负责为物理功能和虚拟功能分别重建该状态。

embedded switch包含用户内部数据包路由于转换的流规则，例如封装及包头字段修改。这些规则由SDN控制器通过与hypervisor的接口进行变成。需要注意的是，与嵌入式交换机相连的VF虚拟端口的状态被归入VF自身的状态。

VF state包括RDMA网卡逻辑（传输对象及其关联关系）以及队列、doorbell等接口。该状态被划分为虚拟机内存、hypervisor内存和设备三个部分。其中，虚拟机内存用于存放RDMA控制结构，如命令提交条目，以及QP和CQ的数据路径的descripto ring。绝大多数的VF内部状态被保存在Interconnect Context Memory，出于安全原因，位于hypervisor中。除了内存分配外，ICM完全由设备管理。瞬态执行状态(transient execution state)（例如传输计时器、服务质量(QoS)状态以及doorbell）和缓存则保存在设备的内部存储器中。

ConnectX-7的迁移支持#

该实现充分靠靓装了ConnextX的以下特性。首先，宽松组件(DA5)完全由VF的ICM表示，而瞬态部分则主流在设备的内部存储器中；其次，ICM按每个VF进行分区，因此VF状态被封装起来，能够以批量方式(DA6)快速检索，且不会影响其它VF的正常运行；最后，设备为每个VF维护了一组独立的RDMA命名空间，这有效避免了明明空间冲突，并支持在目标端精确重建这些命名空间(DA1)，从而避免了之前讨论的RDMA资源标识符转换开销。

我们使用了约6000行固件代码实现了所提出的迁移API。由于VF归VM所有，该迁移API通过响应的PF向hypervisor公开。

Hypervisor的驱动#

传统上来说，PCIe直通功能是通过于厂商无关的驱动程序实现的，如Linux VFIO，它负责管理VF，并依赖PCIe规范将任意PCIe设备暴露给虚拟机，由于迁移功能并不属于PCIe规范的一部分，VFIO需要特定于厂商的代码来支持设备的热迁移。因此，我们基于所提出的于厂商无关的迁移API，未VFIO驱动程序扩展了一套模块化基础设施。

ConnextX-7的热迁移由mlx5-vfio-pci VFIO插件提供。该插件实现了通用基础设施于ConnextX-7驱动程序(mlx5_core模块)之间的桥接，后者回将热迁移调用转发至PF接口。此VFIO驱动的扩展以及mlx5-vfio-pci插件的实现需要大概3000行代码，自linux 6.7版本其正式发布。

虚拟机管理软件#

QEMU是一个开源的广泛使用的hypervisor。我们通过以下方式实现了PCIe直通设备的迁移支持

• 集成了VFIO驱动程序提供的全新迁移功能
• 扩展了迁移基础设施，以充分利用pre-copy和流水线式的镜像传输

其中，Qemu设备热迁移支持所需的代码量约1K行，并已从Qemu8.1版本开始提供。借助相同的直通迁移基础设施于API，后续还将开发诸如NVMe和GPU的支持。