Virt 驱动 guest vCPU 拓扑配置¶
https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology
此功能旨在赋予用户和管理员控制暴露给 guest 的 vCPU 拓扑的能力。这使得他们能够避免受到操作系统厂商对其产品施加的 vCPU 拓扑限制。
问题描述¶
当 guest 被赋予多个 vCPU 时，这些通常在硬件模型中作为离散的 socket 暴露出来。一些操作系统厂商会对他们的产品支持的拓扑结构施加人为限制。例如，一个 Windows guest 可能只有在暴露为每个 socket 4 个核心的 2 个 socket 时才支持 8 个 vCPU。如果 vCPUs 被暴露为每个 socket 1 个核心的 8 个 socket，那么一些 vCPUs 将无法被 guest 访问。因此，能够控制暴露给 guest 的核心和 socket 组合是可取的。云管理员需要能够为 flavor 定义拓扑结构，以覆盖 hypervisor 的默认设置，从而避免常用操作系统遇到其 socket 数量限制。最终用户也需要能够表达对与他们的镜像一起使用的拓扑结构的偏好。
虽然 socket 与核心的选择对性能没有显著影响，但如果 guest 被赋予线程或正在运行在具有线程兄弟关系的 host OS CPU 上，则这可能会对性能产生明显影响。只有当所有 guest vCPU 都严格绑定到 host pCPU 并且一些 host pCPU 是线程兄弟关系时，才应该向 guest 暴露大于 1 的线程值。虽然此蓝图将描述如何设置线程数，但只有在 CPU pinning 功能集成到 Nova 后，将其设置为大于 1 的值才有意义。
如果 flavor 管理员希望定义避免在具有线程 > 1 的 pCPU 的 host 上调度的 flavor，则可以使用 scheduler aggregates 设置 host 组。
提议的变更¶
该提案是在多个级别添加对 vCPU 拓扑各个方面进行配置的支持。
在 flavor 中，将能够使用 flavor extra specs 定义 vCPU 拓扑的默认参数
hw:cpu_sockets=NN - 暴露给 guest 的首选 socket 数量
hw:cpu_cores=NN - 暴露给 guest 的首选核心数量
hw:cpu_threads=NN - 暴露给 guest 的首选线程数量
hw:cpu_max_sockets=NN - 暴露给 guest 的最大 socket 数量
hw:cpu_max_cores=NN - 暴露给 guest 的最大核心数量
hw:cpu_max_threads=NN - 暴露给 guest 的最大线程数量
预计管理员不会将所有这些参数设置为每个 flavor。最简单的预期用例是云管理员设置“hw:cpu_max_sockets=2”以防止 flavor 超过 2 个 socket。虚拟化驱动程序将根据 flavor vCPU 数量和此最大 socket 约束来计算确切数量的核心/socket/线程。
对于较大的 vCPU 数量，可能有许多可能的配置，因此“hw:cpu_sockets”、“hw:cpu_cores”、“hw:cpu_threads”参数使云管理员能够表达他们从大量集合中的首选选项。
“hw:cpu_max_cores”参数允许云管理员放置在使用的核心数量上限，这对于确保大于 1 的 socket 数量并从而使 VM 能够跨 NUMA 节点展开非常有用。
“hw:cpu_max_sockets”、“hw:cpu_max_cores”和“hw:cpu_max_threads”设置允许云管理员设置允许配置的强制上限，用户可以使用镜像上的属性来覆盖这些配置。
在镜像级别，将允许使用完全相同的参数集，唯一的例外是镜像属性将在整个过程中使用下划线而不是初始冒号。
hw_cpu_sockets=NN - 暴露给 guest 的首选 socket 数量
hw_cpu_cores=NN - 暴露给 guest 的首选核心数量
hw_cpu_threads=NN - 暴露给 guest 的首选线程数量
hw_cpu_max_sockets=NN - 暴露给 guest 的最大 socket 数量
hw_cpu_max_cores=NN - 暴露给 guest 的最大核心数量
hw_cpu_max_threads=NN - 暴露给 guest 的最大线程数量
如果用户设置“hw_cpu_max_sockets”、“hw_cpu_max_cores”或“hw_cpu_max_threads”，则这些必须严格低于已经设置为 flavor 的值。其目的是允许用户进一步限制计算主机将考虑用于实例的可能拓扑结构的范围。
镜像上“hw_cpu_sockets”、“hw_cpu_cores”和“hw_cpu_threads”的值不得超过 flavor 或镜像上设置的“hw_cpu_max_sockets”、“hw_cpu_max_cores”和“hw_cpu_max_threads”值。如果超过上限，将被视为配置错误，实例将进入错误状态并且无法启动。
如果由 flavor 或镜像上定义的参数集暗示了多个可能的拓扑解决方案，那么 hypervisor 将优先选择使用更多 socket 的解决方案。这种偏好可能会在后续蓝图集成 NUMA 放置支持时得到进一步完善。
如果用户希望他们的设置被计算主机未更改地使用，他们应该在镜像上设置“hw_cpu_sockets” == “hw_cpu_max_sockets”、“hw_cpu_cores” == “hw_cpu_max_cores”和“hw_cpu_threads” == “hw_cpu_max_threads”。这将强制使用精确指定的拓扑结构。
请注意，在此设计或实现中，计算主机的拓扑结构与暴露给 guest 的拓扑结构不要求匹配。例如，这将允许 flavor 被赋予 sockets=2,cores=2，仍然可以用于在 sockets=16,cores=1 的 host 上启动实例。如果管理员希望选择性地控制这一点，他们可以通过设置 host aggregates 来做到这一点。
计划针对 libvirt 驱动程序实现此功能，目标是 QEMU / KVM hypervisor。从概念上讲，它适用于所有其他完全虚拟机 hypervisor，例如 Xen 和 VMWare。
备选方案¶
虚拟化驱动程序可以硬编码不同的默认拓扑结构，以便所有 guest 始终使用
cores==2, sockets==nvcpus/cores
而不是
cores==1, sockets==nvcpus
虽然这将解决当前 Windows OS 的直接需求，但它不太可能对长期而言足够灵活，因为它会强制所有操作系统使用核心，即使它们没有类似的许可限制。过度使用核心将限制有效执行 NUMA 放置的能力，因此尽可能少地使用核心是可取的。
可以仅在镜像上定义设置，而不使用 flavor extra specs。这是不可取的，因为为了获得最佳 NUMA 利用率，云管理员需要能够约束用户允许使用的拓扑结构。管理员还希望能够设置定义行为，以便 guest 可以获得特定的拓扑结构，而无需将相同的重复属性标记到上传到 glance 的每个镜像。
更细粒度的配置选项将是允许为每个单独的 socket 指定核心和线程计数。这将允许不对称拓扑结构，例如
socket0:cores=2,threads=2,socket1:cores=4,threads=1
但是，值得注意的是，在撰写本文时，没有任何虚拟化技术可以配置这种不对称拓扑结构。因此，Nova 最好忽略这种纯粹的理论可能性，并保持其语法更简单，以匹配已经存在的现实能力。
数据模型影响¶
没有影响。
新的属性将使用现有的 flavor extra specs 和镜像属性存储模型。
REST API 影响¶
没有影响。
新的属性将使用现有的 flavor extra specs 和镜像属性 API 工具。
安全影响¶
socket 与核心的选择可能会对涉及 NUMA 的主机资源利用率产生影响，因为过度使用核心会阻止 guest 跨多个 NUMA 节点拆分。此功能通过允许 flavor 管理员定义硬性上限来解决此问题，并确保 flavor 始终优先于镜像设置。
通知影响¶
没有影响。
此功能不需要与通知集成。
其他最终用户影响¶
用户将获得控制 guest 使用的 vCPU 拓扑的各个方面。他们将通过在 glance 中设置镜像属性来实现这一点。
性能影响¶
核心与 socket 与线程的决策不涉及任何调度器交互，因为此设计并未尝试将主机拓扑结构与 guest 拓扑结构匹配。后续蓝图中的 CPU pinning 将使其能够实现这种主机到 guest 拓扑结构匹配，其性能影响将在那里考虑。
其他部署者影响¶
flavor extra specs 将在 extra specs 中获得新的参数，云管理员可以选择使用这些参数。如果没有设置任何参数，则默认行为不会从以前的版本中更改。
开发人员影响¶
初始实现将针对 libvirt 与 QEMU/KVM 完成。应该能够添加对在 XenAPI 和 VMWare 驱动程序中使用核心/socket/线程参数的支持。
实现¶
负责人¶
主要负责人
berrange
工作项¶
为计算驱动程序基类提供计算给定 hw_cpu_* 参数的有效 CPU 拓扑结构的辅助方法。
添加 Libvirt 驱动程序支持，以根据给定的 hw_cpu_* 参数选择 CPU 拓扑结构解决方案。
依赖项¶
没有外部依赖项
测试¶
没有 tempest 更改。
云管理员和最终用户设置 flavor 和/或镜像参数的机制已经过充分测试。新功能侧重于解释参数并设置相应的 libvirt XML 参数。这在单元测试框架中得到了有效覆盖。
文档影响¶
需要记录新的 flavor extra specs 和镜像属性。应向云管理员提供指导，说明如何最有效地使用新功能。应向最终用户提供指导，说明如何使用新功能来解决他们的用例。
参考资料¶
当前关于 CPU 和内存资源利用率和放置主题的“大图景”研究和设计。 vCPU 拓扑是这项工作的一个子集
