分享一种智能网卡对热迁移支持的新思路

什么是热迁移（LM）？
热迁移是目前云厂商提供的一项必要服务。要求虚拟机（VM）必须在很短的时间内从一台物理机迁移到另一台物理机上继续运行，以达到用户在使用VM时感知不到这一变化过程。

热迁移提出的原因
提出热迁移的意义包括但不限于以下理由：

负载均衡，VM中运行的负载依赖客户的需求，这会导致某些物理机的负载过重，可以通过LM将此物理机中的VM迁移到其他物理机中，达到负载均衡目的。

软硬件维护，物理机的设备需要定期维护，其上的系统软件可能出于安全考虑也需要定期更新等，就需要临时将上面运行的VM迁移到其他物理机运行。

省电，当VM零散的占用一些物理机时，为了节约电力，可以迁移到集中几台上运行，关闭其他闲置的物理机。

热迁移原理介绍

以上框图是以hypervisor（即qemu）的视角来阐述说明。分为Host state, Guest, Devices三部分。Host state 由qemu启动参数确定，一般通过Libvirt这一工具来管理。Guest是指里面的RAM区域，不需要内容可见。Deivces主要指设备的工作状态。

热迁移的过程分以下几步完成：

发起热迁移后，在目的物理机上会启动一个VM，命令参数等同于源物理机上正在运行的VM的启动参数。

标记RAM中所有需要迁移的page为dirty。

发送标记为dirty的page到目的机的VM中，重复多次，直到dirty的page数量减少到某个临界值，或者是达到其他可以触发本阶段结束的条件。

停止源物理机上VM中Guest的运行，并将剩余dirty pages和设备状态发送到目的物理机上的VM中。

目的物理机上VM中Guest开始运行，源物理机上的VM退出。

当前设备对热迁移的支持（以网卡为例）
通过上面对热迁移原理的介绍，我们知道热迁移中设备状态的获取是必不可少的。在VM中，传统的设备都是通过软件模拟来实现的。因此设备的状态qemu是完全可见的，当发起热迁移时，设备的状态可以轻易获取。

近年来，为了追求云计算的性能，虚拟机（VM）里的设备模拟经历从全虚拟化到半虚拟化的演进，且目前正过渡到借助某些技术将物理设备pass-through到VM中，直接被Guest访问的阶段。Pass-through物理设备的方式是可以达到跟HOST访问设备同等的性能，逐渐成为一种主流。

但这给热迁移带来了问题，Pass-through的设备状态要想被获取，就需要硬件配合软件。目前市面上常用的pass-through设备大多都还不支持这一功能。于是有人以可pass-through的网卡为例，提出了如下方案，且已被广大云服务厂商所采用。

上面，左边代表源物理机上热迁移过程中VM的示意图，右边代表热迁移后目的物理机上VM的示意图。主要思想是，在发起热迁移时，源物理机的VM会临时创建一个软件模拟的网卡设备，接管pass-through网卡的工作，pass-through网卡便可以卸载掉。而目的物理机的VM也会创建一个软件模拟的网卡设备，以便在获取源VM的网卡设备状态后，可以顺利工作。当目的VM在稳定运行后，目的物理机的pass-through设备会择时插入VM，接管目的VM中虚拟网卡的工作，当虚拟网卡被完全接管后，便被qemu从VM中删除掉。

这一方案，规避了热迁移时难以获取pass-through设备状态的问题，保证了LM后对pass-through设备的继续使用，以满足高性能的需求。但也存在一些弊端，比如迁移过程比较缓慢；LM时动态添加网卡会对云服务中网络资源的管理带来很大挑战，可能会付出一些高额代价。

智能网卡如何支持LM？
这些年智能网卡在市场上越来越火爆，当然也有许多演进的命名，比如DPU，SmartOffload…，毕竟它已不仅仅局限于网卡的功能（一般也包含存储）。目前我们仍借用最初的叫法。它作为pass-through设备被VM使用时，也同样面临支持热迁移的问题。

对于Pass-through设备支持LM的弊端上面已提及，我们再回到Pass-through设备不支持LM的根源是硬件不支持VM对设备状态的读取。因此解决的途径就是在设计智能网卡时，提供硬件对设备状态读取的支持。好像问题一下子迎刃而解了，只要硬件配合提供VM读取设备状态的接口等功能，我们便不再需要借助虚拟网卡作为LM过程的过渡，弊端由此彻底消除。

只要细想一下，便会发现新的问题，对于智能网卡设备厂商实现此接口将会呈现一个多样性，各家会有各家自己的实现方式。这必然引出了跟VM对接的挑战，需要有统一的软件接口来规范。开始新标准的制定是一个任重道远的过程，那能否找到一套现存的软件生态满足接口统一的要求呢？经过调查研究，我们发现了vDPA这一框架。

什么是vDPA？
vDPA是Virtual Data Path Acceleration的英文缩写。显然是为设备加速提出的。vDPA规范要求设备的数据面必须实现virtio（一种虚拟设备）的数据面。设备的控制面可以按照厂商自定义的格式实现，vDPA会协助完成virtio控制面命令到厂商控制面命令的转换。

目前实现vDPA的框架有两种方式，一种是借助DPDK以实现vDPA的框架，如下图：

在此框图中，vDPA driver由厂商实现，是借助vfio实现的用户态的设备驱动，主要负责对接vDPA接口，实现厂商控制面信息与vDPA的交互。Vhost-library是virtio后端的实现，主要负责virtio控制面信息与vDPA的交互。

另一种是基于Linux Kernel的vDPA实现，示例框图如下：

此框图中，vDPA driver, vhost跟DPDK中的作用相同，只不过是在kernel中实现。

当然VM启动时，qemu可以根据传递不通的命令选取使用DPDK内的vDPA框架还是kernel内的vDPA框架。

通过以上对vDPA的介绍，我们得知vDPA呈现给VM的是virtio设备，但VM中Guest访问的virtio数据面却是真实物理设备的数据面。因此性能可以等同于Host端对物理设备的访问。当然我们介绍vDPA这里不是强调它的加速，而是正因为它对VM呈现的是虚拟设备，即virtio设备，它可以很容易的支持热迁移的特性。

对于智能网卡厂商，尤其面对人力资源投入有限的情况下，通过遵循vDPA的规范可以达到一种快速有效的支持热迁移的方案。此外，如果下一代的virtio规范能够加入对热迁移的支持，我想对智能网卡支持LM会是更加快速有效的方案。

原作者：James 张·