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 端口将在后续规范中解决，以限制范围。

提议的变更

在 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 别名消耗类型-VF 和类型-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 也会被创建，但此时仅 VF 库存存在于 RP 上。

如果来自同一父 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 设备将不受支持。 有关更多详细信息，请参阅 依赖设备处理 部分。

注意

即使 neutron 请求的 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 设备。

调度

重要

调度支持的实现未能在截止日期前完成，因此不属于 Zed 版本。

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 字段填充，而 spec 字段又从匹配的 [pci]alias 条目的字段填充，该条目通过 flavor extras_spec 请求。 如果请求来自没有关联 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 请求组，并使用已经提出的预过滤器。 有关更多详细信息，请参阅 调度。 在这种情况下，与 PCI 别名情况相比，调度时不知道资源类的名称或 vendor ID、product 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 标签，并且还具有提供 VF 的能力，则将具有特性 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 满足命名请求组，但允许在同一子树内关联这些请求组。）我们这里有多种选择

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

• 将带宽和 PCI 资源报告在同一个 RP 上。这将打破单个 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 启用 PCI 库存报告。在配置 [pci]report_to_placement = True 的 nova-compute 服务启动期间，该服务将重塑提供程序树，并开始将 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

工作项

• 将 PCI passthrough_whitelist 重命名为 device_spec

• 支持将资源类和特征添加到 device_spec

• 引入 [pci]report_in_placement

• 拒绝依赖设备配置和 devname 配置

• PCI 重塑和现有实例的分配修复

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

• 预过滤器

• 扩展 HostState 对象，添加分配候选者列表

• 扩展调度器，用候选者填充 HostState 对象，然后在过滤后重建候选者列表。

• 扩展 hardware.py，以便在过滤 NUMA 亲和性时考虑分配候选者。

• 扩展 PCI 管理器声明，使其了解分配。

依赖项

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

测试

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

文档影响

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

参考资料

• CPU 资源跟踪规范: https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/cpu-resources.html

• Nova 中的统一限制集成: https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/unified-limits-nova.html

• 支持虚拟 GPU 资源: https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/add-support-for-vgpu.html

历史

修订版

发布名称	描述
Xena	引入
Zed	扩展并重新提出