Libvirt: 支持基于 vDPA 的网络

https://blueprints.launchpad.net/nova/+spec/libvirt-vdpa-support

多年来，已经开发了许多不同的技术来将网络和其他功能卸载到外部进程，以加速 QEMU 实例的性能。 在内核 5.7+ 中，引入了一种新的虚拟总线，称为 vDPA（vHost 数据路径加速），旨在提供一种供应商中立的方式，以使用软件或硬件加速器实现来加速标准的 virtio 设备。 vDPA 支持已在 Libvirt 6.9.0 中引入，以利用 QEMU 5.1+ 中引入的 vDPA 功能。 此蓝图跟踪增强 nova，以利用这些新功能，通过硬件卸载的 OVS 将卸载到基于硬件的智能网卡。

问题描述

当前硬件卸载的网络解决方案需要在客户机中使用供应商特定的驱动程序才能正常工作。 vDPA 总线允许在加速器和 VM 之间存在抽象层，而无需传统软件 vHost 实现的 CPU 开销。 支持 vDPA 的 vSwitch 卸载允许客户机使用标准的 virtio 驱动程序，而不是供应商特定的驱动程序。

注意

虽然预计 vDPA 将在未来支持实时迁移，但 QEMU 当前不支持使用 vDPA 设备进行实时迁移。 vDPA 基于网络的的主要优势之一是能够将设备状态从 VM 中抽象出来，从而通过软件回退实现透明的实时迁移。 在 QEMU 中实现该回退之前，实时迁移将在 API 层通过 HTTP 409（冲突）错误响应被阻止，以便我们可以在不使用新的微版本的情况下启用它。

由于 Open vSwitch 是目前唯一能够管理 vDPA 设备的控制平面，并且由于这需要硬件卸载才能正常工作，因此本规范将专注于仅使用硬件卸载的 OVS 启用 vDPA 网络。 在未来的发布版本中，如果它们变为 vDPA 启用状态，可以将此功能扩展到其他 vSwitch 实现，例如 VPP 或 linux bridge。

用例

作为操作员，我希望提供硬件加速的网络，而无需要求租户在其客户机中安装供应商特定的驱动程序。

作为操作员，我希望利用硬件加速的网络，同时保持透明实时迁移的能力。

注意

最初将不支持透明的实时迁移，并且仅在未来的 QEMU 版本中正式支持后才启用。

提议的变更

• neutron 中已引入一个新的 vnic 类型 vdpa，以请求 vDPA 卸载的网络。 https://github.com/openstack/neutron-lib/commit/8c6ab5e

• 将扩展 nova.network.model 类，以定义新的 vdpa vnic 类型常量。

• libvirt 驱动程序将被扩展以生成 vDPA 接口 XML

• PCI 跟踪器将扩展为使用新的设备类型 VDPA。 虽然现有的白名单机制未更改，但如果设备被列入白名单并绑定到 vDPA 驱动程序，则它将被编目为 VDPA。 在 libvirt 驱动程序中，这将通过扩展私有 _get_pci_passthrough_devices 和 _get_device_type 函数来检测 VF 是否是 vDPA nodedev 的父项来完成。 这些函数由资源跟踪器中的 get_available_resources 调用，以生成由计算代理启动时 _setup_pci_tracker 在 _init_compute_node 中使用的资源字典。

注意

需要 vDPA 设备类型以确保与 vDPA 设备关联的 VF 不能通过 PCI 别名或标准的 neutron SR-IOV 支持分配给 VM。 与 vDPA 设备关联的 VF 不能使用标准的内核控制平面命令（例如 ip）进行管理。 因此，将它们分配给由 sriov-nic-agent 管理的接口或通过基于别名的 PCI 直通是不合法的。 这还将提供自动 NUMA 亲和性，并为将来在 placement 中作为通用 PCI 设备跟踪的一部分报告 vDPA 设备提供一条途径。

备选方案

我们可以将 vDPA 支持委托给 cyborg。 这仍然需要 libvirt 和 neutron 的更改，同时也会使部署复杂化。 由于基于 vDPA 的网卡是固定功能的网卡，因此没有真正的好处可以证明这种方法所增加的复杂性是合理的。

我们可以使用为 vPMEM 设备添加的资源表来跟踪数据库中的设备，而不是 PCI 跟踪器。 这将使代码路径复杂化，因为我们无法共享已存在的 PCI NUMA 亲和性代码。

我们可以通过将 vDPA 设备视为直接模式 SR-IOV 接口来支持实时迁移，这意味着 nova 将在迁移期间热插拔接口。 在未来，如果两个主机的 QEMU 版本足够新，这可以替换为透明的实时迁移。 由于我们不知道何时会发生这种情况，因此将此选项推迟到未来的版本，以减少复杂性。

可以添加一个新的解决方法配置选项 enable_virtual_vdpa_devices=True|False（默认值：False）。 当设置为 True 时，它将允许跟踪和使用虚拟 vDPA 设备，例如 vdpa_sim 设备。 虚拟 PCI 设备没有 VF 或 PCI 设备与之关联，因此设置此值将导致使用无操作 os-vif 驱动程序，并使用一个哨兵值在 PCI 跟踪器中跟踪该设备。 这将允许在 CI 中使用真实 vDPA 硬件进行测试，并且不适用于生产用途。 为了避免添加仅用于测试的配置选项和代码，将使用功能测试来确保足够的代码覆盖率。

可以报告一个新的标准特征 HW_NIC_VDPA，由 libvirt 驱动程序在具有 vDPA 设备的宿主机上报告，以及所需的 QEMU 和 libvirt 版本。 这将与一个新的 placement 预过滤器结合使用，以将所需的特征请求附加到未命名的组，如果任何 VM 接口具有 vnic 类型 vdpa。 这将不会完成，因为它在 placement 中跟踪 PCI 设备时将不再需要。 由于无法删除标准特征，因此将不会添加新的特征，并且 PCI 直通过滤器将用于根据设备类型过滤主机。

数据模型影响

将扩展 nova.network.model.VIF 类中 vnic 类型的允许值。 将扩展 pci_devices 表中 device_type 列的允许值。

可选地，VIFMigrateData 或 LibvirtLiveMigrateData 对象可以扩展，以表示目标主机是否支持透明的 vDPA 实时迁移。 这是可选的，因为目前它总是错误的，直到发布支持此功能的 QEMU 和 libvirt 版本。

REST API 影响

neutron 端口绑定扩展 vnic 类型已扩展为添加 vnic 类型 vdpa。 不需要 nova API 更改。

安全影响

无

通知影响

无

其他最终用户影响

从最终用户角度来看，vDPA 端口将像 SR-IOV 端口一样工作，但是客户机呈现的设备模型将是 virtio NIC，并且实时迁移最初将被阻止，直到 QEMU 支持为止。

性能影响

性能将与 SR-IOV 相同，就数据平面性能而言，nova 调度或 VM 创建而言，即无。

其他部署者影响

vDPA 需要非常新的内核和非常新的 QEMU 和 libvirt 版本才能使用。 vDPA 的初始支持已在内核 5.7、QEMU 5.1 和 libvirt 6.9.0 中添加。

操作员需要确保存在所有依赖项才能使用此功能。 Intel 网卡支持存在于 5.7 中，撰写本文时，Intel 市场上没有可用的支持 vDPA 的网卡。 首次公开可用的具有 vDPA 功能的网卡是 Mellanox/Nvidia ConnectX-6 DX/LX 网卡，这些网卡仅在内核 5.9 中启用

开发人员影响

无

升级影响

无

实现

负责人

主要负责人

sean-k-mooney

其他贡献者

stephen.finucane

功能联络人

sean-k-mooney

工作项

• 更新 libvirt 驱动程序

• 添加预过滤器

• 添加文档

• 更新测试

依赖项

• libvirt 6.9.0+

• QEMU 5.1+

• Linux 5.7+

测试

这将主要通过单元和功能测试进行测试，但是，如果证明这样做切实可行，可以使用 vDPA sim 模块创建一个 Tempest 作业。 主要挑战是创建一个具有所需依赖项的稳定测试环境。 Fedora rawhide 具有所有必需的依赖项，但附带 python 3.9。 OpenStack 当前无法在 python 3.9 下正常工作

替代测试环境，例如 Ubuntu 20.04，默认情况下不提供足够新的内核，或者不提供所需的 libvirt 和 QEMU 版本。 从源代码编译是一个选项，但我们可能不想在上游 CI 中这样做。

文档影响

现有的管理网络文档将被扩展，以介绍 vDPA 并描述使用要求。

参考资料

关于此主题的 nova-neutron PTG 讨论可以在此处第 186 行找到：https://etherpad.opendev.org/p/r.321f34cf3eb9caa9d87a9ec8349c3d29

对该主题的介绍可在以下博客中找到：https://#/en/blog/introduction-vdpa-kernel-framework，关于该主题的演变和当前状态的其他博客也可用：https://#/en/blog?search=vdpa

历史

修订版

发布名称	描述
Wallaby	引入
Wallaby	更新以反映 HTTP 错误代码的更改