Neutron SR-IOV Port Live Migration

https://blueprints.launchpad.net/nova/+spec/libvirt-neutron-sriov-livemigration

当 nova 扩展以支持 SR-IOV 时 [0]，live migration（实时迁移）并未作为提议变更的一部分直接解决。因此，虽然使用 SR-IOV 进行 live migration 在技术上是可行的，但 libvirt 驱动程序仍然不支持它。本 spec 旨在解决 libvirt virt 驱动程序中 live migration 支持的这一差距。

问题描述

使用 SR-IOV 设备进行 Live Migration 有几个复杂因素。

  • NUMA 亲和性

  • 硬件状态

  • SR-IOV 模式

  • 资源声明

NUMA 亲和性不在本 spec 的范围内，将由 [1] 单独解决。

neutron port 的 SR-IOV 模式直接影响 live migration 的方式。本 spec 将重点关注两种主要类型的 SR-IOV，即直接直通 (vnic_type=direct|direct-physical) 和间接直通 (vnic_type=macvtap|virtio-forwarder)。为了简单起见，在 spec 的其余部分中使用“直接模式”和“间接模式”代替 vnic_type。

当通过直接模式 SR-IOV 将设备暴露给 guest 时，虽然以暴露硬件状态为代价，但可以实现最大性能。由于没有标准机制来复制硬件状态，因此无法通过常规方式 live migrate 直接模式 SR-IOV。本 spec 将提供一种解决方法来启用此配置。

硬件状态传输是 SR-IOV live migration 的一个属性，OpenStack 无法解决，因此本 spec 不打算复制硬件状态。复制硬件状态需要硬件、驱动程序和 hypervisor 级别的显式支持，而 SR-IOV 设备目前不具备这种支持。

注意

在此上下文中，硬件状态是指任何 NIC 状态，例如卸载状态或 Tx/Rx 队列，这些状态是在硬件中实现的，无法通过 hypervisor 进行软件编程。例如，MAC 地址不被视为在此上下文中的硬件状态，因为 libvirt/qemu 可以通过标准主机级别接口设置 SR-IOV 设备的 MAC 地址。

对于 SR-IOV 间接模式，SR-IOV 设备通过软件中介层（例如 macvtap + kernel vhost、vhost-user 或 vhost-vfio）暴露。从 guest 的角度来看，SR-IOV 接口被暴露为虚拟 NIC，并且不会观察到任何硬件状态。因此，间接模式 SR-IOV 允许在无需任何解决方法的情况下迁移 guest。

当今 SR-IOV live migration 支持的主要差距是资源声明。如引言所述，即使在今天，使用间接模式 SR-IOV 设备在两个主机之间进行 live migration 在技术上是可行的，但是，这样做时，资源没有被正确声明。由于没有声明 SR-IOV 设备，在 VM 成功迁移到目标主机后，会在迁移后清理过程中引发异常。

在今天进行 live migration 时，如果需要更改 PCI 映射，迁移也会失败。换句话说，只有当目标节点上有一个空闲的 PCI 设备，其 PCI 地址与源节点相同，并且连接到相同的 physnet 并且位于相同的 NUMA 节点上时，迁移才会成功。

这是因为两个问题。首先，nova 没有在目标节点上正确声明 SR-IOV 设备，其次，nova 没有修改 guest XML 以反映目标主机上的 PCI 地址。

由于上述问题，即使 VM 成功移动，libvirt 驱动程序中的 SR-IOV live migration 当前是不完整且不正确的。

用例

作为拥有具有长期对等时间等有状态 VNF（例如 vPE 路由器）的电信运营商，我希望能够利用直接模式 SR-IOV 来满足我的性能 SLA，但希望在维护期间具有 live migration 的灵活性。因此，作为运营商，我愿意在 guest 中使用绑定到 vSwitch 或间接 SR-IOV 接口的绑定，以促进迁移并在迁移期间保留对等关系，同时了解性能 SLA 将无法满足。

作为利用间接模式 SR-IOV 的硬件卸载 vSwitch 的云提供商，我希望向我的客户提供它所实现的性能，但也希望能够灵活地迁移 guest 而不会中断流量，从而实现维护。

提议的变更

本 spec 建议分几个步骤解决问题陈述。

资源声明

在最近添加的多端口绑定功能的基础上，本 spec 建议扩展现有的 check_can_live_migrate_destination 函数，以便通过 PCI 资源跟踪器在目标节点上声明 SR-IOV 设备。如果声明失败，则将释放部分声明的资源，并且 check_can_live_migrate_destination 将失败。如果声明成功，则 LiveMigrateData 对象中与 SR-IOV 设备对应的 VIFMigrateData 对象将使用目标主机 PCI 地址进行更新。如果迁移在目标资源声明后应失败，则必须在 rollback_live_migration_at_destination 调用中释放它们。如果迁移成功，则源主机 SR-IOV 设备将在 post_live_migration（清理源）中释放，并且目标上声明的设备的狀態更新为已分配。通过主动更新成功和失败情况下的资源跟踪器，我们无需依赖 update_available_resource 定期任务来修复分配/声明。

SR-IOV 模式

间接模式

间接模式 SR-IOV 不需要对 nova 进行其他修改，除了资源声明部分中已经涵盖的修改之外。

直接模式

对于直接模式 SR-IOV，为了启用 live migration，必须在 pre_live_migrate 之后在源主机上先分离 SR-IOV 设备，然后在 post_live_migration_at_destination 中重新连接它们。

这模仿了现有的挂起 [2] 和恢复 [3] 工作流程，我们通过这种方式绕过 QEMU 在挂起到磁盘操作期间无法保存设备状态的问题。

注意

如果您希望在迁移过程中保持网络连接，由于直接模式 SR-IOV 设备将被分离，因此需要在 guest 中使用绑定到透明 live migratable 接口（例如 vSwitch 接口或间接模式 SR-IOV 设备）的绑定。最近添加的 net_fallback 内核驱动程序在本 spec 范围之外，但也可以使用。

XML 生成

间接模式 SR-IOV 不会在 libvirt XML 中编码 PCI 地址。在多端口绑定功能中引入的 XML 更新逻辑足以启用间接用例。

直接模式 SR-IOV 会在 libvirt XML 中编码 PCI 地址，但是，由于 SR-IOV 设备将在迁移前分离并在迁移后连接，因此不需要 XML 更新。

备选方案

  • 与不做任何事情并继续不支持使用 SR-IOV 设备进行 live migration 相比，运营商将不得不回退到冷迁移。在这种情况下，如果运营商不知道此限制，则需要额外的文档或可选的驱动程序级别检查来拒绝 live migration 以保护运营商。

  • 我们可以添加一个新的 API 检查来确定实例是否具有 SR-IOV 端口，并明确以新的错误来拒绝迁移。

数据模型影响

预计不需要任何数据模型更改，因为 migration_data 对象中的现有 VIF 对象应该能够存储相关的 PCI 地址信息。如果不是这样，则需要对这些对象进行小的扩展才能存储此信息。

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

直接模式 SR-IOV 的用户应注意，自动热插拔对于 guest 来说并不像挂起那样透明。这将在发布说明和 live migration 文档中记录。

性能影响

这不应显着影响 live migration 的性能。声明资源和更新 XML 会产生轻微的开销。

其他部署者影响

如果源节点和目标节点都支持 SR-IOV live migration，则将启用 SR-IOV live migration。如果任一计算节点不支持此功能，则迁移将被 conductor 终止。

开发人员影响

无

升级影响

此功能可能会帮助未来具有启用 SR-IOV 的 guest 的主机升级，因为它允许使用 live migration，但是，首先需要源节点和目标节点都支持 SR-IOV live migration。因此，此功能对本次发布没有影响。

为了确保跨版本兼容性，conductor 将验证源节点和目标节点是否支持此功能，方法与用于检测是否支持多端口绑定相同。

从 stein 升级到 train 时，conductor 检查将允许使用此功能，无需运营商干预。

实现

负责人

主要负责人

sean-k-mooney

其他贡献者

adrian.chiris

工作项

  • Spec: Sean-K-Mooney

  • PCI 资源分配和间接 live-migration 支持：Adrianc

  • 直接 live-migration 支持：Sean-K-Mooney

依赖项

本 spec 没有依赖项，但打算与 NUMA 感知 live migration 的实现 [1] 合作。

请注意，可能需要修改 sriovnicswitch ml2 驱动程序才能支持多端口绑定。如果需要此工作，将使用 Neutron RFE 错误和/或 spec 进行跟踪。

测试

此功能将主要通过单元和功能测试进行测试，由于 SR-IOV 测试在 gate 中不可用，因此无法进行 tempest 测试。可以实施第三方 CI，但这不在本 spec 的范围内。评估了使用 netdevsim 内核模块来允许在没有 SR-IOV 硬件的情况下测试 SR-IOV。虽然 netdevsim 内核模块允许创建 SR-IOV PF netdev 并分配 SR-IOV VF netdev，但它不会模拟 PCIe 设备。因此，目前 netdevsim 内核模块无法用于在 gate 中启用 SR-IOV 测试。

文档影响

需要更新操作员文档以描述新功能并指定直接模式自动连接对于 guest 来说并不透明。

参考资料

历史

修订

发布名称

描述

Stein

提议