libvirt: 支持单个 pGPU 的多种 vGPU 类型¶
https://blueprints.launchpad.net/nova/+spec/vgpu-multiple-types
Nova 中的虚拟 GPU 在 Queens 版本中实现，但每个计算节点仅支持一种 GPU 类型。现在，由于 GPU 作为 嵌套资源提供者 创建，此规范仅针对如何暴露一些操作员选择，以告知应该为每个 GPU 设置哪种 GPU 类型。
注意
由于 Xen 提供了一个特定功能，即支持相同 vGPU 类型的物理 GPU 位于单个 pGPU 组中，因此该虚拟驱动程序不需要知道需要支持特定类型的确切 pGPU，因此此规范仅针对 libvirt 驱动程序。
问题描述¶
目前，虽然可以为用户提出多种 GPU 类型，但存在当前限制，即单个 GPU 设备只能接受一种类型的所有虚拟设备每个图形处理单元。
例如，NVidia GRID 物理卡可以接受不同 GPU 类型的列表，但驱动程序只能支持 每个物理 GPU 一种类型。
因此，我们需要一种指示 libvirt 驱动程序 NVIDIA 或 Intel 物理 GPU 配置为接受哪些 vGPU 类型的方法。
用例¶
操作员需要一种方法来告知 libvirt 驱动程序 NVIDIA 或 Intel 物理 GPU 配置为接受哪些 vGPU 类型。
提议的变更¶
我们已经有了 [devices]/enabled_vgpu_types，它定义了 Nova 计算节点可以使用哪些类型
[devices]
enabled_vgpu_types = [str_vgpu_type_1, str_vgpu_type_2, ...]
现在我们建议 libvirt 将接受与 [devices]/enabled_vgpu_types 相关的配置节，并指定哪些确切的 pGPU 与启用的 vGPU 类型相关联，并将定义一个 device_addresses 选项，如下所示
cfg.ListOpt('device_addresses',
default=[],
help="""
List of physical PCI addresses to associate with a specific GPU type.
The particular physical GPU device address needs to be mapped to the vendor
vGPU type which that physical GPU is configured to accept. In order to
provide this mapping, there will be a CONF section with a name corresponding
to the following template: "vgpu_type_%(vgpu_type_name)s
The vGPU type to associate with the PCI devices has to be the section name
prefixed by ``vgpu_``. For example, for 'nvidia-11', you would declare
``[vgpu_nvidia-11]/device_addresses``.
Each vGPU type also has to be declared in ``[devices]/enabled_vgpu_types``.
Related options:
* ``[devices]/enabled_vgpu_types``
"""),
例如，它将在 nova.conf 中设置
[devices]
enabled_vgpu_types = nvidia-35,nvidia-36
[vgpu_nvidia-35]
device_addresses = 0000:84:00.0,0000:85:00.0
[vgpu_nvidia-36]
device_addresses = 0000:86:00.0
注意
此提案与我们现有的 NUMA 感知 vSwitches 具有的动态选项非常相似。
在这种情况下，nvidia-35 vGPU 类型将由 PCI 地址为 0000:84:00.0 和 0000:85:00.0 的物理 GPU 支持，而 nvidia-36 vGPU 仅由 0000:86:00.0 支持。
如果某个操作员搞砸了，并为同一个 pGPU 提供了两种类型，将引发 InvalidLibvirtGPUConfig 异常。如果操作员忘记为特定的 pGPU 提供类型，那么 enabled_vgpu_types 中给出的第一个类型将被支持，就像现有情况一样。如果操作员错误地输入了 PCI ID，那么在创建清单时，将返回一个异常。
由于单个计算节点现在可以支持多种 vGPU 类型，因此要求操作员提供主机聚合以分组具有相同 vGPU 类型的计算节点变得无关紧要。相反，我们需要要求操作员修改他们的 flavor 以获取特定的 GPU 功能（如果他们关心这些功能），或者 Placement 将随机选择可用的 vGPU 类型之一。为此，我们建议通过拥有一个 nova.virt.vgpu_capabilities 模块来标准化 GPU 功能，不幸的是这些功能非常特定于供应商（例如，CUDA 库版本支持），该模块会将特定于供应商的 vGPU 类型转换为一组 os-traits 特征。如果操作员想要特定于供应商的特征，他们有责任在资源提供者上提供自定义特征，或者要求社区找到适合他们需求的标准特征。
备选方案¶
我们可以要求操作员将这些细节放入 提供者配置文件 中，通过添加一些额外的 libvirt 特定的信息，并告知要为特定的资源提供者使用哪种 GPU 类型。也就是说，这将需要我们修改 YAML 模式以允许一些额外的随机参数可用，这将是 libvirt 特定的，并且会违背提供者配置文件尽可能通用的目的。值得一提的是，GPU 类型不是一个特征，因为它定义了要为匹配的物理 GPU 分配的虚拟资源的定量金额。
数据模型影响¶
无
REST API 影响¶
无。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
无。
其他部署者影响¶
操作员需要查看 sysfs（对于 libvirt）以了解现有的 pGPU 以及支持哪些类型。
开发人员影响¶
无。
升级影响¶
无。
实现¶
负责人¶
- 主要负责人
bauzas
- 其他贡献者
无
功能联络人¶
无
工作项¶
创建配置选项
修改 libvirt virt 驱动程序代码以利用该选项来创建嵌套资源提供者清单。
依赖项¶
无。
测试¶
经典的单元测试和功能测试。
文档影响¶
将添加一个带有“feature”部分的发布说明，并且将修改 虚拟 GPU 文档以解释新功能。
参考资料¶
无。
历史¶
发布名称 |
描述 |
|---|---|
Rocky |
已批准 |
Stein |
重新提出 |
Ussuri |
重新提出 |
