支持通用介导设备¶
https://blueprints.launchpad.net/nova/+spec/generic-mdevs
由于 Nova 已经支持通过 libvirt 驱动程序管理现有的虚拟 GPU 介导设备，我们希望帮助操作者将其用于使用 VFIO-mdev 框架但不是 GPU 的通用 PCI 设备。
问题描述¶
由于 Linux 内核支持名为 VFIO-mdev 的框架，硬件供应商可以使用它来支持其设备，例如 NVIDIA 对其 GPU 所做的那样。例如，您可以要求内核为父设备创建一个新的介导设备，从而创建虚拟 GPU。由于此 API 是抽象的，任何硬件都可以使用此框架来支持从物理设备创建虚拟设备的功能。
在 Queens 版本中，libvirt 驱动程序获得了查找现有介导设备以启用 管理虚拟 GPU 的支持，并且还可以直接调用内核 API 来 创建新的介导设备（如果需要）。不幸的是，虽然此内核 API 在不同支持介导设备的物理设备之间的可用性方面是抽象的，但我们在 Nova 中创建了一个虚假且不必要的虚拟 GPU 和介导设备之间的对应关系：虚拟 GPU 确实是一种介导设备，但介导设备可以是虚拟 GPU 以外的其他东西。
在此规范中，我们建议通过将介导设备视为一个独立的 Placement 资源类，而不是虚拟 GPU（如果指定），来消除这种无关的对应关系。
注意
目前，我们仅支持无状态物理设备，因为 Nova 只是在实例之间重用现有的介导设备。
用例¶
作为操作者，我希望为我的客户提供新的风味，这些风味将要求使用不是虚拟 GPU 的通用介导设备，因为我已经拥有使用 Linux 内核中的 VFIO-mdev 框架抽象虚拟资源的硬件。
提议的变更¶
我们将尽量减少更改次数，不会破坏 Nova 中现有虚拟 GPU 的用户
我们将通过提出一个额外的选项来扩展 Nova 中管理介导设备的配置选项，该选项将说明它是用于 GPU 还是其他用途。
我们将建议使用自定义资源类进行调度决策。
现有的风味无需更改。
配置更改¶
目前，您可以允许 Nova libvirt 驱动程序通过在 nova.conf 中定义来使用介导设备进行虚拟 GPU 管理
[devices]
enabled_vgpu_types = <type1>,<type2>
[vgpu_<type1>]
device_addresses = <pci_address_1>,<pci_address_2>
[vgpu_<type2>]
device_addresses = <pci_address_3>
我们建议将 enabled_vgpu_types 选项名称重命名为 enabled_mdev_types，并仅将旧名称用作遗留别名。相应地，组可以命名为 mdev_<type> 或在几个版本中保持为 vgpu_<type>。可以在 mdev_<type> 组下指定一个额外的选项，命名为 mdev_class，定义如下
cfg.StrOpt('mdev_class',
default='vgpu',
regex=[a-zA-Z0-9_],
max_limit=248,
help='Class of mediated device to manage.')
一个例子如下
[devices]
enabled_mdev_types = nvidia-35,mlx5_core-local
[mdev_nvidia-35]
device_addresses = 0000:84:00.0,0000:85:00.0
[mdev_mlx5_core-local]
device_addresses = 0000:86:00.0
mdev_class=mlx5
注意
我们已经有 配置检查 用于此目的，但我们可以尝试查看清单以检测不希望的更改（如果创建了分配），并防止计算服务启动。
自定义资源类¶
这里没有什么特别的。Nova libvirt 驱动程序将查找支持介导设备的现有 PCI 设备并像现在一样创建清单。唯一的区别是，如果将 PCI 设备设置为默认值以外的 vgpu 类，则它可以创建的特定类型虚拟设备的数量的清单将使用名为 CUSTOM_<type> 的自定义资源类。例如，在上面的示例中，使用 mlx5 mdev 类的物理设备的清单将具有名为 CUSTOM_MLX5 的资源（我们将把字符转换为大写以被 Placement API 接受）。
相应地，如果一个风味指定带有资源组的 extraspec，例如 resources:CUSTOM_MLX5=1，那么 Placement 将在具有此资源类的资源提供程序上创建分配。稍后在引导序列中，libvirt 驱动程序将在 spawn() 方法（或其他移动操作）中获取实例的分配，它不仅会查找 VGPU 相关的分配，还会查找 CUSTOM_MLX5 分配，并因此绑定现有的 mdev 或要求 sysfs 创建一个新的 mdev。为此，驱动程序将首先查看配置选项中接受的所有自定义资源类。
备选方案¶
我们可以使用新的库存 YAML 文件来描述容量，但这会稍微破坏现有框架的用户。另一种选择是停止使用 VGPU 资源类并仅使用新的 MDEV 资源类，但这对于可能需要修改现有分配的用户来说是一个更具破坏性的更改。此外，其他 virt 驱动程序可以继续使用 VGPU 资源类，这意味着 virt 驱动程序之间存在差异。
Cyborg 也可以是一个显而易见的选择，因为他们也开始实现虚拟 GPU。这两个项目都支持通用设备没有问题，因为我们让操作者在维护和使用方面选择他们喜欢的，而代码本身大部分是共享的（因为最终 Cyborg 中的 mdev 分配会重用相同的方法）。
数据模型影响¶
无。
REST API 影响¶
没有。目前，所有操作（除了实时迁移）都受支持，我们不认为有必要为选择通用设备的用户提出一个微版本。由于风味由操作者管理，因此最终用户不会看到可见的更改。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
无。
其他部署者影响¶
请参阅上面描述的配置更改。
开发人员影响¶
潜在的其他 virt 驱动程序也可以利用这个机会来提出通用设备，主要是 Xen 驱动程序，它已经支持虚拟 GPU。
升级影响¶
没有，现有的风味和库存不会改变。我们将指定仅对新硬件使用新的通用类，以防止对 Placement 库存进行不必要且不必要的修改，但这并没有改变操作者决定使用不同类型的 GPU 的情况。
实现¶
负责人¶
- 主要负责人
sylvain-bauza
- 其他贡献者
无
功能联络人¶
无。
工作项¶
修改 libvirt 驱动程序以填充自定义资源类的库存。
修改 libvirt 方法以查找已知自定义资源类的分配。
公开配置更改。
依赖项¶
无。
测试¶
好消息是，我们可以使用 mtty 假驱动程序 来测试通用 mdev（以及通过扩展 Nova 中的虚拟 GPU 管理）而无需依赖一些专有且昂贵的驱动程序，这对于我们的上游 gate 作业来说是不可能的。
文档影响¶
主要是 https://docs.openstack.org/nova/latest/admin/virtual-gpu.html。
参考资料¶
历史¶
发布名称 |
描述 |
|---|---|
Xena |
引入 |
