使用带有资源请求的端口

从 microversion 2.72 开始，nova 支持使用 neutron 端口创建服务器，这些端口的资源请求显示为仅管理员可见的端口属性 resource_request。例如，如果 neutron 端口附加了 QoS 最小带宽规则，则该端口具有资源请求。

《服务质量 (QoS)：保证带宽》文档描述了如何配置 neutron 以使用此功能。

资源分配

Nova 收集并组合启动请求中每个端口的资源请求，并在调度期间将一个分配候选请求发送到 placement，以便 placement 确保满足端口的资源请求。在调度结束时，nova 在 placement 中分配一个候选实例。因此，来自单个启动请求的每个端口的请求资源将在 placement 中在服务器的分配下分配。

资源组策略

当查询 placement 以获取分配候选实例时，Nova 将每个 neutron 端口的资源请求表示为单独的 细粒度资源请求组。如果服务器创建请求包含多个带有资源请求的端口，则在分配候选查询中使用多个组。在这种情况下，placement 需要定义 group_policy。目前，只能通过 flavor extra_spec 的 group_policy 键来实现。可能的值是 isolate 和 none。

如果策略设置为 isolate，则每个请求组，因此每个 neutron 端口的资源请求，将从单独的资源提供程序中满足。对于具有 vnic_type=direct 或 vnic_type=macvtap 的 neutron 端口，这意味着每个端口将使用来自不同物理函数的虚拟函数。

如果策略设置为 none，则 neutron 端口的资源请求可以从重叠的资源提供程序中满足。对于具有 vnic_type=direct 或 vnic_type=macvtap 的 neutron 端口，这意味着端口可以使用来自相同物理函数的虚拟函数。

对于具有 vnic_type=normal 的 neutron 端口，组策略定义了 OVS 网桥级别上的共置策略，因此在这种情况下 group_policy=none 是一个合理的默认值。

如果 flavor 中缺少 group_policy，则服务器创建请求将失败，并显示“未找到有效的宿主机”，并且会记录一条描述缺失策略的警告。

Virt 驱动程序支持

支持带有 vnic_type=direct 或 vnic_type=macvtap 的 neutron 端口取决于 virt 驱动程序的capability。有关受支持的 virt 驱动程序，请参阅 支持矩阵

如果计算宿主机上的 virt 驱动程序不支持所需的 capability，则宿主机上的 PCI 声明将失败，并触发重新调度。建议不要在这些计算宿主机上的 neutron agent 中配置带宽库存，以避免不必要的重新调度。

扩展资源请求

预计 neutron 20.0.0 (Yoga) 将通过 port-resource-request-groups neutron API 扩展实现扩展资源请求格式。截至 nova 24.0.0 (Xena)，如果每个 nova-compute 服务升级到 Xena 版本，并且 upgrade_levels.compute 配置不会阻止 compute 使用最新的 RPC 版本，nova 已经支持此扩展。

扩展资源请求允许单个 Neutron 端口在多个请求组中请求资源。这也意味着在服务器创建请求中使用单个端口将需要在 flavor 中提供组策略。今天，单个端口生成多个请求组的唯一情况是该端口具有同时具有最小带宽和最小包速率规则的 QoS 策略。由于这些功能的 placement 资源模型，在这种情况下，两个请求组将始终从单独的资源提供程序中满足，因此 flavor extra spec 中的 group_policy=none 或 group_policy=isolate 不会对资源的 placement 产生任何额外的限制。在多端口情况下，上述资源组策略部分仍然适用。