PCI 设备跟踪置放

https://blueprints.launchpad.net/nova/+spec/pci-device-tracking-in-placement

OpenStack Placement 服务旨在通过资源类库存跟踪定量资源，通过特性跟踪定性特征。在过去的几个周期中，Nova 已经利用 Placement 跟踪基本资源，如 CPU、RAM 和磁盘，以及更复杂的资源，如虚拟 GPU。本规范描述了 Nova 如何利用 Placement 跟踪通用 PCI 设备，而不涉及这些设备的 NUMA 感知细节。

问题描述

Nova 在许多版本中支持使用专用 PCI 跟踪器以及 PciPassthroughFilter 调度器后置过滤器来实现通用的无状态 PCI 直通。

PCI 跟踪器负责跟踪可用的 PCI 设备、已声明的 PCI 设备和已分配的 PCI 设备，设备的 capabilities，当声明或分配时其消费者，以及 PCI 设备的类型和位置。

PciPassthroughFilter 负责确保 VM 请求的设备在调度期间存在于宿主机上。这些 PCI 请求来自两个来源：基于 flavor 的 PCI 请求，使用 pci_passthrough:alias flavor extra specs 生成，以及基于 neutron 的 PCI 请求，由 SR-IOV 支持的 neutron 端口生成。

虽然当前 PCI 跟踪方法有效，但当前设计存在一些限制，并且有优化的空间。

限制

  • 在服务器创建期间，PCI 设备直到在计算节点上创建 instance_claim 才会被声明。因此，两个并发的服务器创建请求可能会争夺宿主机上的最后一个设备，从而导致重新调度。

  • 虽然 Nova 今天在 pci_devices 表的 extra_info 字段中跟踪网络接口的 capabilities，并且 PciPassthroughFilter 可以匹配这些 capabilities，但没有用户界面来表达对具有特定网络 capability（例如 TSO）的 SR-IOV neutron 端口的请求。

  • 没有管理员界面来检查云中可用的和已分配的 PCI 资源。唯一的方法是查看 Nova 数据库。

优化

  • 今天，当 virt 驱动程序在计算主机上分配 PCI 设备时，它需要查看主机上所有可用的 PCI 设备，并选择一个满足 PCI 和 NUMA 要求的设备。如果我们使用 Placement 建模 PCI 设备，我们只需要考虑 Placement 中 PCI 资源分配中关联的设备。

  • 今天，在调度时，我们使用 Python 对可行的主机进行基于 PCI 设备的过滤。通过利用 Placement，我们可以将过滤移动到 SQL。

用例

  • 作为操作员，我希望实例创建以原子方式声明资源，以减少重试的机会。

  • 作为操作员，我希望通过运行更少的过滤器来缩短选择主机的时间。

  • 作为操作员，我希望利用特性和资源类来建模 PCI 别名和请求，以实现更具表现力的设备管理。

  • 作为操作员，我希望能够将配额与 PCI 设备的使用关联起来。

  • 作为操作员，我希望能够使用 Placement API 来查询云中可用的和已分配的 PCI 设备。

注意

设备配额需要实现统一的限制。实施配额不在本规范的范围内，而是在 Placement 中建模 PCI 设备后启用用例。

本规范还将仅关注基于 flavor 的 PCI 直通。Neutron SR-IOV 端口将在后续规范中解决，以限制范围。

提议的变更

重要

此功能中库存跟踪和分配修复部分已经在 Zed 版本中实现。尽管如此，本规范也包含已实现部分的描述，以便作为上下文。规范中缺失部分的说明从 调度 开始。

在 Placement 中选择性报告 PCI 设备

为了支持配置了 PCI 直通的现有部署的升级，并能够弃用并最终删除当前 PCI 设备跟踪器的一些功能，新的基于 Placement 的 PCI 设备跟踪将在第一个版本中默认禁用。新的 [pci]report_in_placement 配置选项可用于启用该功能。它首先默认为 False，一旦设置为 True，如果再次禁用，nova-compute 将拒绝启动。在未来的版本中，在 Placement 中的 PCI 跟踪功能完成后，默认值将更改为 True。

PCI 设备规范配置

下面我们建议更改 [pci]passthrough_whitelist 配置选项。虽然我们正在进行此更改，但我们将借此机会更新配置选项的名称。旧名称 [pci]passthrough_whitelist 配置选项将被弃用以供最终删除，并添加一个新名称 [pci]device_spec。新旧名称都将支持新提出的 resource_class 和 traits 标签。

PCI 直通设备列表 配置选项的语法将扩展为支持两个额外的标准标签 resource_class 和 traits。这些新标签只有在将 [pci]report_in_placement 配置选项设置为 True 时才会生效。

device_spec = {
  "vendor_id": "1002",
  "product_id": "67FF",
  "resource_class":"CUSTOM_GPU",
  "traits": "CUSTOM_RADEON_RX_560", "CUSTOM_GDDR5"
}
device_spec = {
  "address": "0000:82:00.0",
  "resource_class":"CUSTOM_FPGA",
  "traits": "CUSTOM_XILINX_XC7VX690T"
}

resource_class 标签仅在未定义 physical_network 标签时才会被接受，并且将启用将 PCI 设备与自定义资源类关联。每个 PCI device_spec 条目最多可以关联一个资源类。具有 physical_network 标签的设备此时不会在 Placement 中报告，因为基于 neutron 的 SR-IOV 超出当前规范的范围。

如果 PCI 设备没有 physical_network 或 resource_class 标签，则会使用生成的自定义资源类报告，资源类为 CUSTOM_PCI_<vendor_id>_<product_id>。

traits 标签将是逗号分隔的标准或自定义特性名称列表，这些名称将在 Placement 中报告设备的 RP。

Nova 将标准化并使用 CUSTOM_ 前缀资源类和特性名称（如果尚未添加前缀），然后再在 Placement 中创建它们。Nova 首先将在 os_traits 中检查提供的特性名称，如果它存在作为标准特性，则将使用该特性而不是创建自定义特性。

注意

最初，特性将仅是累加的，如果将来需要，我们可以允许使用 +/- 语法删除特性，但这不在本规范的范围内。

如 在 Placement 中建模 PCI 设备 部分所述，每个物理设备（PF）都将是 Placement 资源提供程序 (RP)，具有相关 PF 和 VF 资源类的库存。因此，特性不能在同一父 PF 下的 VF 设备之间变化。如果 VF 由不同的 device_spec 条目匹配，则为同一 PF 下的不同 VF 定义不同的 traits 是配置错误，将被拒绝。

虽然可以为同一父 PF 下的不同 VF 定义不同的 resource_class 名称，但这被认为是不良实践和不必要的复杂性。此类配置将被拒绝。

注意

Nova 将检测到 nova-compute 服务重启时，已报告设备的 resource_class 或 traits 配置是否已更改。如果受影响的设备是空闲的，Nova 将在 Placement 中应用更改。如果设备已分配，则更改 resource_class 将导致删除现有的分配，Placement 会拒绝，因此计算服务将拒绝启动。

注意

将来，当 PCI 跟踪在 Placement 中扩展到具有 physical_network 标签的 device_spec 条目时，这些条目将不允许指定 resource_class，但 nova 将使用标准 SRIOV_NET_VF、PCI_NETDEV 和 VDPA_NETDEV 类。这不会阻止通过 PCI 别名消耗 type-VF 和 type-PF 设备，因为别名也可以请求这些标准资源类。

新的基于 Placement 的 PCI 跟踪功能不支持 [pci]device_spec 配置中的 devname 标签。此标签的使用已经有限，因为并非所有 PCI 设备都具有设备名称。此外，devname 仅在跨 hypervisor 重启和升级保持名称稳定时才有效。如果将 [pci]report_in_placement 设置为 True 并且 [pci]device_spec 具有任何带有 devname 标签的条目，则 nova-compute 服务将拒绝启动。

在 Placement 中建模 PCI 设备

Placement 中 PCI 设备的建模将密切模仿 vGPU。类型为 type-PCI 和 type-PF 的每个 PCI 设备都将建模为 Placement 资源提供程序 (RP)，名称为 <hypervisor_hostname>_<pci_address>。hypervisor_hostname 前缀将与根 RP 的名称相同的字符串。名称中的 pci_address 部分将采用与 DDDD:BB:AA.FF 相同的格式的完整 PCI 地址。

注意

pGPU RP 使用 libvirt nodedev 名称，但本规范不尝试遵循该命名方案，因为 libvirt nodedev 名称被认为不稳定。此外，nova 始终使用 RP UUID 来标识 RP，而不是其名称。因此，这些名称仅用于故障排除目的。

每个 PCI 设备 RP 将具有基于匹配给定设备的 [pci]device_spec 条目的资源类和特性的库存。如果设备具有匹配任何 device_spec 条目的子设备（VF），则子设备的资源库存和特性也将报告给父 PF RP。

如果 PCI 设备匹配没有 physical_network 标签的 device_spec 条目，则将报告匹配 device_spec 条目中指定的 resource_class 的库存 1，或者如果未指定 resource_class，则使用生成的 CUSTOM_PCI_<vendor_id>_<product_id> 资源类。

如果 type-VF 设备匹配 device_spec 条目，则相关的资源库存将报告在其父 PF 设备表示的 RP 上。即使 type-PF 设备不匹配任何 device_spec 条目，PF RP 也会被创建，但此时 RP 上仅存在 VF 库存。

如果来自同一父 PF 的多个 VF 匹配 device_spec，则 VF 的总资源库存将是匹配的 VF 设备的总数。

每个 PCI 设备 RP 将根据匹配 device_spec 条目的 traits 标签报告特性。此外，Nova 将自动在设备 RP 上报告 COMPUTE_MANAGED_PCI_DEVICE 标准特性。这用于 nova-compute 服务拒绝在禁用后重新启用 [pci]report_in_placement 的重新配置。

如果启用了 [pci]report_in_placement，则不支持同时列出父 PF 设备和任何子 VF 设备。有关更多详细信息，请参阅 依赖设备处理 部分。

注意

即使中性子请求的 PCI 设备超出本规范的范围，但处理 type-PF 和 type-VF 设备也不能被忽略，因为这些设备类型也可以通过设置 device_type 标签通过 PCI 别名进行请求。

注意

目前，PCI 别名只能根据 vendor_id 和 product_id 请求设备，这些信息将自动包含在 Placement 库存中作为资源类。

注意

未来，Nova 可以扩展为自动将 PCI 设备功能作为 Placement 中的自定义特征报告。但这超出了当前规范的范围。如果需要，部署者可以通过 [pci]device_spec 配置手动添加这些特征。

从 ResourceTracker 向 Placement 报告库存

ResourceTracker 和 PciDevTracker 实现了一种与 virt 驱动程序无关的 PCI 设备库存和分配处理。此逻辑已扩展为通过将 PciDevice 和 PciDeviceSpec 对象转换为 Placement 资源提供程序、资源库存和特征，为 Placement 提供 PCI 库存信息。

这种新的转换器逻辑还能够基于分配的 PciDevice 对象的 instance_uuid 字段修复现有实例的缺失 PCI 资源分配。缺失的分配将通过 /reshape API 在 Placement 中创建。

为了辅助通过 placement 进行 PCI 调度，此逻辑还将表示 PCI 设备的资源提供程序的 UUID 记录到 PciDevice 对象中。然后现有的 PCI 池化逻辑会将这种映射转换为 PCI 设备池、资源提供程序 UUID 映射。请注意，调度器需要资源提供程序和 PCI 设备池之间的一对一映射，因此 PCI 池化逻辑已更改为将每个 type-PCI 和 PF 设备表示为单独的池，并且仅将来自同一父 PF 的 VF 池化到同一个池中。

库存和分配处理逻辑将在 update_available_resource 定期以及由于实例操作导致资源跟踪更新期间运行。

此实现中的分配修复部分是临时的，用于支持将具有 PCI 分配的现有部署升级到新的基于 Placement 的逻辑。一旦部署升级完成并且启用了调度器逻辑，预计修复将不起作用，因为调度器将在 Placement 中创建所有必要的分配。因此，我们计划在未来的版本中从代码库中删除修复逻辑。

注意

计算重启逻辑需要处理设备不再存在的情况，这可能是由于 [pci]device_spec 配置选项的更改或由于从 hypervisor 物理设备移除所致。驱动程序需要修改 PF RP 上的 VF 资源库存（当移除 VF 时），或删除 PF RP（如果移除 PF 并且没有匹配的子 VF）。Nova 无法在设备分配给 VM 时阻止从 hypervisor 移除 PCI 设备。尽管如此，Nova 在这种情况下会发出警告。

PCI 别名配置

在 [pci]alias 配置选项中的 PCI 别名定义 将扩展为支持两个新标签，resource_class、traits。 resource_class 标签可以包含一个资源类名称。而 traits 标签可以包含一个逗号分隔的特征名称列表。此外，traits 中的特征名称可以以 ! 为前缀，以表示禁用的特征。当指定 resource_class 时，不再需要 vendor_id 和 product_id 标签。

注意

如果别名中同时提供了 resource_class 和 vendor_id 和 product_id 字段，那么 Nova 将使用 resource_class 进行 Placement 查询，但 vendor_id 和 product_id 过滤将在 PciPassthroughFilter 中发生。

注意

如果将来需要更复杂的特征要求，我们可以通过添加一个自由后缀来支持多个 traits 标签。此外，我们还可以添加对 traits 标签的值中 in: 前缀的支持，以表示 OR 关系。例如：

{
    "traits1": "T1,!T2",
    "traits2": "in:T3,T4"
}

请求 PCI 设备

pci_passthrough:alias flavor extra specs 的语法和处理方式不会改变。此外，Nova 将继续使用 InstancePCIRequest 来跟踪 VM 请求的 PCI 设备。

调度

RequestSpec 创建逻辑已扩展为将 InstancePCIRequest 对象转换为 RequestGroup 对象，并将新的组存储在 RequestSpec 的 resource_request 字段中。此时 nova 将仅转换基于 flavor 的 InstancePCIRequests，基于 neutron 端口的请求将在后续版本中处理。

默认情况下禁用此转换逻辑，并且可以在启用部署中每个计算节点上的 [filter_scheduler]pci_in_placement 配置后启用，并且启用了 [pci]report_in_placement 配置选项。

为了能够明确地将 InstancePCIRequest 连接到 RequestGroups，InstancePCIRequest 对象的 request_id 字段始终需要填充为 UUID。过去 nova 仅为基于 neutron 的请求填充该字段。

单个 InstancePCIRequest 对象可以潜在地请求多个设备，因为基于 flavor 的请求的 count 字段可以设置为大于 1。在这种情况下，单个请求对象被拆分为多个 RequestGroup 对象，以允许从独立的资源提供程序满足这些设备请求。生成的 RequestGroup 对象的 requester_id 填充了 InstancePCIRequest.request_id-<index> 公式生成的某个值，其中 index 是请求中 0..``count`` 之间的运行索引。

RequestGroup 对象的 resources 和 required_traits 字段根据 InstancePCIRequest 的 spec 字段填充，而后者又从通过 flavor extras_spec 请求的匹配 [pci]alias 条目的字段填充。如果请求来自没有关联 resource_class 的别名，则它将默认为 CUSTOM_PCI_<vendor_id>_<product_id>。

现有的调度器实现可用于生成包含新的 PCI 相关组的 /allocation_candidates 查询到 Placement。

依赖设备处理

目前，nova 允许在配置中匹配父 PF 及其子 VF，这些设备被跟踪为单独的资源。但是，它们不能独立使用。当消耗 PF 时，其子 VF 将不可用。同样，当消耗 VF 时，其父 PF 将不可用。这种动态设备类型选择将被弃用，新的基于 Placement 的 PCI 跟踪将仅允许配置 PF 设备或其子 VF 设备。旧的 PCI 跟踪器将继续支持此功能，但一旦计算节点上的 [pci]report_in_placement 设置为 True，该计算节点将拒绝启用 PF 及其子 VF 的配置。

PCI NUMA 亲和性

PCI NUMA 亲和性代码（主要在 hardware.py 中）需要修改为仅限制被包含在分配候选摘要中的 PCI 设备。同时，此代码应向调度器提供有关哪些分配候选从亲和性角度有效的信息。

为了启用此功能，分配候选将添加到筛选调度器的 HostState 对象中。 PciPassthroughFilter 和 NUMATopologyFilter 然后需要将分配候选传递给 hardware.py 函数，这些函数需要删除不满足 PCI 或 NUMA 要求的任何分配候选。然后筛选器应从 HostState 对象中弹出任何无效的分配候选。在调度过程结束时，筛选调度器将不得不从 HostState 对象重建主机分配候选集。

通过使用分配候选扩展 HostState 对象，我们将使筛选器不仅可以按主机进行筛选，还可以选择性地按主机的分配候选进行筛选，而无需更改筛选器 API，从而保持与外部筛选器的兼容性。

PCI 统计模块

统计模块需要增强以支持感知分配的声明。需要将 PciDevicePool 对象映射到资源提供程序。这将由 PciDevTracker 中的 PCI 设备库存报告逻辑完成。在调度尝试期间，筛选器可以提供当前分配候选映射到的资源提供程序 UUID，以根据候选限制 PCI 拟合逻辑。

在做出调度决策后，所选映射将记录到 InstancePCIRequest 对象中。这样，在 PCI 声明逻辑期间，将从这些对象提供此信息，以确保声明消耗 Placement 中为此请求分配的 PCI 设备。

VM 生命周期操作

初始调度与稍后由于移动操作而进行的调度非常相似。因此，可以重用现有实现。此外，可以重用当前逻辑，该逻辑将源节点 Placement 分配切换为由迁移 UUID 保有。

使用 PCI 别名 PCI 设备不支持实时迁移，并且当前规范不会更改这一点。

附加和分离 PCI 设备仅受 Neutron SR-IOV 端口支持，这不在本规范的范围内。

Neutron SR-IOV 端口（超出范围）

这在当前规范中超出范围。但是，已知问题的某些方面已在此处列出。

存在一个 Neutron 端口 vnic_type 列表（例如，direct、direct-physical 等），其中端口需要由 VF 或 PF PCI 设备支持。

在更简单的情况下，如果端口只需要一个 PCI 设备，而不需要任何其他资源（例如带宽），那么 Nova 需要为每个 Neutron 端口创建 Placement 请求组，并使用前面提出的预筛选器。有关更多详细信息，请参阅 Scheduling。在这种情况下，与 PCI 别名情况相比，调度时不知道资源类的名称或供应商 ID、产品 ID 对，因此预筛选器不知道需要在 Placement 请求组中请求什么资源类。

为了解决此问题，打算用于基于 Neutron 的 SR-IOV 的 PCI 设备不应在 [pci]device_spec 中使用 resource_class 标签。相反，Nova 将使用标准资源类来模拟这些资源。

目前，nova 允许为 direct 端口消耗 type-PCI 或 type-VF。这主要是由于历史原因，应该清理。建议使用更好的设备分类。

  • 如果设备在 device_spec 中没有附加 physical_network 标签，则该设备才能通过 PCI 别名使用。

  • 如果设备附加了 physical_network 标签，则该设备将被视为网络设备，并将建模为 PCI_NETDEV 资源。

  • 具有 physical_network 标签并且能够提供 VFs 的设备将具有特征 HW_NIC_SRIOV，但仍使用 PCI_NETDEV 资源类。

  • 具有 physical_network 标签并且是 VF 的设备将被建模为 SRIOV_NET_VF 资源。

这样，每个 Neutron vnic_type 都可以映射到 Nova 的一个单一资源类。建议的 vnic_type -> 资源类映射如下

  • direct, macvtap, virtio-forwarder, remote-managed -> SRIOV_NET_VF

  • direct-physical -> PCI_NETDEV

  • vdpa -> VDPA_NETDEV

Nova 将使用这些资源类向 Placement 报告设备清单。然后，预过滤器可以将端口的 vnic_type 转换为请求调度期间的特定资源类。

基于 Neutron 的 SR-IOV 的另一个特点是，device_spec 中列出的设备始终具有 physical_network 标签。需要将此信息作为特征报告给 Placement 中的 PF RP。此外，端口请求的 physnet 需要包含在预过滤器的 Placement 请求组中。

当 Neutron 端口不仅请求 PCI 设备，还通过端口 resource_request 属性请求其他资源（例如带宽）时，存在更复杂的情况。在这种情况下，Nova 已经从 resource_request 生成 Placement 请求组，并且像在简单情况下一样，将从 PCI 请求生成一个请求组。这些 neutron 端口的资源请求需要相关联，以确保端口从同一物理设备获取 PCI 设备和带宽。但是，今天带宽是在 Neutron RP 子树下建模的，而 PCI 设备将在根 RP 下建模。因此，要分配的两个 RP 不在同一个子树中。（请注意，Placement 始终从单个 RP 满足命名请求组，但允许在同一子树内关联这些请求组。）我们这里有多种选择

  • 创建一个调度器过滤器，该过滤器删除从不同物理设备满足这些请求组的分配候选者

  • 在同一个 RP 上报告带宽和 PCI 设备资源。这将打破单个 RP 的清晰所有权，因为带宽由 neutron 代理报告，而 PCI 设备由 Nova 报告。

  • 将两个 RP（带宽和 PCI 设备）移动到同一个子树中。这需要在 Nova 和 Neutron 开发人员之间达成协议，确定将 RP 移动到哪里，并且需要额外的重塑来实现移动。

  • 增强 Placement 以允许在同一个 RP 树内的 RP 之间共享资源。通过这种方式，我们可以使带宽 RP 成为与代表物理设备的 PCI 设备 RP 共享资源的共享 RP。

基于所选的解决方案，要么

  • Neutron 通过端口 resource_request 字段请求 SRIOV 端口的特定资源类

  • Nova 可以在基于请求的端口创建 InstancePCIRequest 对象时将这些资源包含到请求中。

备选方案

  • 我们可以继续使用遗留跟踪，并保留其优点和缺点。

  • 我们可以将每个 PCI 设备记录作为单独的 RP 进行跟踪。这将导致每个 VF 都有自己的 RP，从而允许每个 VF 具有不同的特征。不建议这样做，因为它会显著增加每个主机的分配候选者的可能排列组合。

  • 我们可以继续支持 Placement 中的动态 PF 或 VF 消耗，但认为其复杂性大于实用性。我们将继续通过遗留代码路径支持它，但新的代码路径将不支持它。

  • 我们可以将每个 PCI 设备建模在 NUMA 节点下。将来可以通过将 RP 移动到 NUMA 节点 RP 而不是计算节点 RP 来实现，但这被声明为超出此初始规范的范围。

数据模型影响

InstancePCIRequest 对象将被扩展，以包含所需的和禁止的特征以及通过 flavor 中的 PCI 别名和 PCI 别名配置中定义的资源类。

PciDevicePool 对象将被扩展，以存储资源提供程序 UUID，以便在 Placement 中分配的 PCI 设备可以与 PCI 跟踪器要声明的 PCI 设备相关联。

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

通常，预计这将提高调度性能，但不应影响客户的运行时性能。

引入新的 PCI RequestGroup 对象将使 Placement 查询的计算稍微长一些，并且具有 PCI 请求的实例的执行时间可能会增加，但不应影响没有 PCI 请求的实例。预计这种增加的复杂性将通过将过滤卸载到 Placement 以及消除由于争夺主机上的最后一个 PCI 设备而导致重新调度来抵消。

其他部署者影响

为了利用新功能，操作员将不得不定义两个新的配置选项。一个用于启用 Placement 调度逻辑，另一个用于启用将 PCI 设备报告给 Placement。

开发人员影响

无

升级影响

基于 Placement 的新的 PCI 跟踪默认情况下将被禁用。已经使用 PCI 设备的部署可以自由升级到新的 Nova 版本，而不会产生任何影响。在此状态下，PCI 设备管理将由调度器中的 PciPassthroughFilter 和计算服务中的 PCI 设备跟踪器中的 PCI 声明来完成，就像在 Nova 的先前版本中一样。然后，在升级后，新的 PCI 设备跟踪可以分两个阶段启用。

首先，需要在每个计算主机上通过 [pci]report_to_placement 在 nova-compute 服务的启动时启用 PCI 库存报告，配置 [pci]report_to_placement = True，该服务将重塑提供程序树并开始将 PCI 设备库存报告给 Placement。Nova compute 还会修复 Placement 中现有实例的 PCI 分配。在预过滤器默认启用之前，将为具有 PCI 请求的新实例完成此修复。这对于即使在没有预过滤器请求 Placement 中的 PCI 分配的情况下，也要保持 Placement 中的资源使用同步是必需的。

注意

鼓励操作员借此机会将 [pci]passthrough_whitelist 配置选项重命名为新的 [pci]device_spec 选项。这两个选项的语法相同。

注意

如果启用了 [pci]report_to_placement，则不再支持 [pci]device_spec 和 [pci]passthrough_whitelist 中的 devname 标签。我们建议使用 address 标签代替。

注意

如果部署配置为依赖于动态依赖设备行为，即 PF 及其子 VF 都匹配 device_spec，则需要重新配置，因为新的代码补丁将不支持此行为，并且 nova-compute 服务将拒绝启动此类配置。要进行重新配置，部署者需要查看每个计算节点上 PCI 设备的当前分配

  • 如果既未分配 PF 也未分配其任何子 VF，则部署者可以决定保留哪些设备在 device_spec 中。

  • 如果 PF 已经分配，则需要将 PF 保留在 device_spec 中，但必须删除所有子 VF。

  • 如果分配了任何子 VF 设备，则需要从 device_spec 中删除父 PF，并且至少需要保留当前分配的 VF 在配置中，而其他未分配的子 VF 可以保留或从 device_spec 中删除。

注意

一旦为计算主机启用了 [pci]report_to_placement，就无法禁用它了。

其次，在每台计算主机都配置为将 PCI 库存报告给 Placement 后，需要在 nova-scheduler 配置中通过 [filter_scheduler]pci_in_placement 配置选项启用调度逻辑。

实现

负责人

主要负责人

balazs-gibizer

功能联络人

功能联络人

sean-k-mooney

工作项

  • 将 InstancePCIRequest 对象转换为 RequestGroup 对象 在 RequestSpec 中

  • 支持将资源类和所需的特征添加到 PCI 别名

  • 按 PCI 或 PF 设备拆分 PCI 池

  • 将每个 PCI 池映射到它所代表的 RP

  • 扩展 HostState 对象，以包含分配候选者列表

  • 更改 PciPassthroughFilter 和 NUMATopologyFilter 以过滤分配候选者

  • 扩展 stats 和 hardware 模块，以便在过滤 PCI NUMA 亲和性时考虑分配候选者。

  • 在 InstancePCIRequest 中存储分配的 RP UUID

  • 扩展 PCI 声明代码路径，以基于 Placement 分配消耗设备。

  • 确保在每次移动操作之前发生 InstancePCIRequest 到 RequestGroup 转换。

依赖项

统一的限制功能处于启用状态的实验状态，如果启用，将允许为新的 PCI 资源定义限制。

测试

由于这是一个 PCI 直通相关的功能，因此无法在上游 tempest 中进行测试。测试将主要通过存在于 libvirt 功能测试中的具有 PCI 设备和 NUMA 拓扑的实例的广泛单元和功能测试套件来完成。

文档影响

PCI 直通文档需要重写，以记录新的 resource_class 和 trait 标签，用于 PCI device_spec 和 PCI 别名。

参考资料

历史

修订版

发布名称

描述

Xena

引入

Zed

扩展并重新提出。库存跟踪和分配修复已经实现。

2023.1 - Antelope

重新提出以完成调度支持