OpenStack 的 SR-IOV 虚拟机热迁移

目录

文章目录

• 目录
• 前言列表
• 前言
• SR-IOV Pass-through 虚拟机热迁移的问题
• 基于 macvtap 层的 SR-IOV 虚拟机热迁移
• Workaround SR-IOV Pass-through 虚拟机热迁移
• 中兴的 SR-IOV 热迁移实现思路

前言列表

《SR-IOV 网卡虚拟化技术》
《启用 SR-IOV 解决 Neutron 网络 I/O 性能瓶颈》

前言

NOTE：本文主要参考了国防科技大学计算机学院的论文《基于SR—IOV的IO虚拟化技术》（编号：1005—1228(2010)05-0001-05），以及中兴通讯的专利《实现SR-IOV网卡的方法和装置、实现动态迁移的方法和装置》（编号：CN201510646047.X）。

OpenStack 中，虚拟机对 SR-IOV 的使用可以分为两种模式：

• Indirect mode（间接模式）：通过 macvtap 层来进行转接，支持 Hypervisor 层面的热迁移，但性能会损失（20%-30%）。
• Direct mode（直接模式）：即 Pass-through，不支持 Hypervisor 层面的热迁移，好处是性能几乎没有损失。

本文主要描述这两种模式的实现方式，以及验证在 Train 版本中官方给出的 Workaround 热迁移 SR-IOV Pass-through 虚拟机的方法，最后再讨论一下中兴支持的 SR-IOV Pass-through 虚拟机热迁移的实现方式。

SR-IOV Pass-through 虚拟机热迁移的问题

首先明确一个热迁移的概念，KVM 虚拟机热迁移并不是单纯的 重新创建 了一个一模一样的虚拟机，而是在 Hypervisor 层采用了类似于 从挂起状态到运行状态 的状态转换方式，即：使用系统盘在目的节点启动虚拟机时，并不存在 GuestOS 启动的过程，只是纯粹的启动了 Guest，这就意味着虚拟机在源节点上的所有配置与状态都会在目的节点上重现。所以，从 vNIC 的角度来看，虚拟机从源节点迁移到目的节点的整个过程中，都不存在向 DHCP 获取 IP 地址的动作。

而正是这一合情合理的实现原则，导致了 SR-IOV Pass-through 虚拟机无法进行热迁移。这需要从 Pass-through 所采用的技术 Passthrough I/O 说起。

Passthrough I/O 是一种硬件辅助的 I/O 虚拟化技术，对于 Xen 或 VMware 支持的纯软件实现的 I/O 虚拟化技术而言，显然具有性能上的优势。但缺点也很明显就是需要硬件的支撑。Intel 和 AMD 都在 CPU 架构中提供对 Passthrough I/O的支持。Intel 将这种支持称为 VT_d（Virtualization Technology for Directed l/O），AMD 称之为 IOMMU（I/O Memory Managemnt Unit）。这种技术的 Host CPU 能够将 PCI 设备的物理地址映射到 Guest 中。当这种映射发生时，硬件将负责访问和保护，GuestOS 像 HostOS 一样可以直接使用该设备。除了将 Guest 映射到物理内存外，还提供隔离机制，以便预先阻止其他 Guest（或管理程序）访问该区域。

简而言之，Passthrough I/O 就是将分配给网卡 DMA 的物理地址给到了 Guest，Guest 就可以直接访问这个物理地址来接收和发送数据报文。那么，显然的，使用了 Passthrough I/O 的 Guest 就不再是 “无状态” 的 Guest，它具有一个 Host 物理地址与 Guest 虚拟地址的映射表。也正是这一 “状态” 注定 Guest 无法随意的进行迁移。必须执行网卡 Detached 再 Reattach 的过程（重新建立地址映射表）。

这就是 SR-IOV Pass-through 虚拟机热迁移的难题。表现到实际的现象就是，对 SR-IOV Pass-through 虚拟机执行热迁移完成后，需要登录到 GuestOS 上手动的执行 ifup <vnic> 指令，然后再获取到 IP 地址。这个过程中，网络流量肯定是断掉了。

基于 macvtap 层的 SR-IOV 虚拟机热迁移

计算机科学的名言之一就是：所有的问题都可以通过添加一个新的层来解决！SR-IOV Pass-through 虚拟机热迁移的问题亦然。基于 macvtap 层的 SR-IOV 虚拟机热迁移就是这样的一个 “解决方案”。

既然 SR-IOV Pass-through 到 Guest 会产生 “状态” ，那么将 “状态” 转移到别的地方不就好了吗？macvtap 层（Virt NIC-FE、Virt NIC-BE、macvtap）就是这般的存在。VF 的 Detached 再 Reattach 的过程在 macvtap 层完成，并且由 Hypervisor 来完成 Detached 再 Reattach 管理。对于虚拟机而言，依旧是 “无状态” 的，可以任意迁移。这就是基于 macvtap 层的 SR-IOV 虚拟机可以进行热迁移原因。

但严格来说，这并不是一个解决的方案，因为根本问题（“无状态”）没有被解决，而是通过一种方式来转移了，是一种中庸的实现。引入 macvtap 层的缺点就是 20%-30% 的性能损失，因为 macvtap 是一个内核态设备，需要进行内核协议栈的处理，这就意味着内存拷贝、上下文切换以及 Cache Miss 等等数据面转发的性能问题。

Workaround SR-IOV Pass-through 虚拟机热迁移

在 Train 版本中，OpenStack 官方给出了一个 Workaround 执行 SR-IOV Pass-through 虚拟机热迁移的思路（https://docs.openstack.org/neutron/latest/admin/config-sriov.html）。

Live migration support has been added to the Libvirt Nova virt-driver in the Train release for instances with neutron SR-IOV ports. Indirect mode SR-IOV interfaces (vnic-type: macvtap or virtio-forwarder) can now be migrated transparently to the guest. Direct mode SR-IOV interfaces (vnic-type: direct or direct-physical) are detached before the migration and reattached after the migration so this is not transparent to the guest. To avoid loss of network connectivy when live migrating with direct mode sriov the user should create a failover bond in the guest with a transparently live migration port type e.g. vnic-type normal or indirect mode SR-IOV.

操作起来大致有以下步骤：

1. 为 SR-IOV 虚拟机添加一个 normal（OvS）或者 indirect mode SR-IOV（macvtap SR-IOV）的 Port。
2. 在 GuestOS 中将原有的 SR-IOV Port 与 Step1 添加的 Port 做一个 Bond。
3. 对 SR-IOV 虚拟机执行热迁移。
4. 迁移完成后，登录 GuestOS 执行 ifup <vnic> 执行拉起原有的 SR-IOV Port。
5. 删除 Step1 中添加的 Port。

显然，Workaround 的思路就是使用支持热迁移的 Port 来承接 SR-IOV Port 在迁移过程中的流量。

中兴的 SR-IOV 热迁移实现思路

中兴的 SR-IOV 热迁移实现思路和加入 macvtap 层的实现方式类似，本质上是对后者的优化，具体说来主要有以下两点：

1. 把 macvtap 去掉， 直接对接 VF Driver
2. 将 Virt NIC-BE 和 VF Driver 移到了用户态

这两点优化，实现了在支持热迁移的同时进一步压缩的性能的损耗。从架构图上看，应该需要对 VirtIO 进行定制开发，还需要实现一个用户态的 vNIC 进程来管理 Virt NIC-BE 和 VF Driver 的 Detached 再 Reattach 流程。