Libvirt 驱动程序模拟器线程放置策略¶
https://blueprints.launchpad.net/nova/+spec/libvirt-emulator-threads-policy
Nova 调度器根据风味中 vCPU 的数量确定 CPU 资源利用率和实例 CPU 放置。许多虚拟机监控程序都在宿主机操作系统中代表客户机实例执行操作。这些操作应该被统计和调度，并且应用自己的放置策略控制。
问题描述¶
Nova 调度器通过计算为每个客户机分配的 vCPU 数量来确定 CPU 资源利用率。在进行超卖时，与专用资源相反，此 vCPU 数量乘以超卖比例。然后，此利用率用于确定跨计算节点或在 NUMA 节点内的最佳客户机放置。
然而，许多虚拟机监控程序代表客户机实例在与虚拟实例 vCPU 不关联的执行上下文中执行工作。对于 KVM / QEMU，有一个或多个与 QEMU 进程关联的线程，用于 QEMU 主事件循环、异步 I/O 操作完成、迁移数据传输、SPICE 显示 I/O 等。对于 Xen，如果使用 stub-domain 功能，则使用整个域来为主域提供 I/O 后端。
Nova 目前没有机制来跟踪此额外的客户机实例计算需求以衡量利用率，也没有对其执行策略进行任何控制。
libvirt 驱动程序为 KVM 实现了一种通用的放置策略，允许 QEMU 模拟器线程在与实例 vCPU 运行的相同 pCPU 上浮动。换句话说，模拟器线程会在有工作要做时从 vCPU 窃取一些时间。在 CPU 过度提交的情况下，这大致可以接受。但是，当客户机想要专用 vCPU 分配时，希望能够表达其他放置策略，例如，将一个或多个 pCPU 分配给客户机的模拟器线程专用。随着 Nova 继续实现对实时工作负载的支持，这将变得至关重要，因为不允许模拟器线程从实时 vCPU 窃取时间是不可以接受的。
虽然 libvirt 驱动程序可以添加不同的放置策略，但除非以某种方式将模拟器线程的概念暴露给调度器，否则无法以令人满意的方式表达 CPU 使用情况。因此，需要一种向调度器描述与客户机关联的其他 CPU 使用情况的方法，并在放置期间考虑该情况。
用例¶
在当前的 Nova libvirt 实时支持中，要求为运行非实时工作负载保留一个 vCPU。QEMU 模拟器线程被固定在与此 vCPU 相同的宿主机 pCPU 上运行。虽然此要求对于 Linux 客户机来说大致可以接受，但它阻止了 Nova 运行其他需要对所有 vCPU 进行实时响应的实时操作系统。为了扩展实时支持，有必要将模拟器线程与 vCPU 分开固定，这需要调度器能够考虑每个客户机的额外 pCPU 使用量。
项目优先级¶
无
提议的变更¶
在风味上启用模拟器线程放置策略功能的先决条件是，它还必须将 ‘hw:cpu_policy’ 设置为 ‘dedicated’。
每个虚拟机监控程序都有不同的架构，例如 QEMU 具有模拟器线程，而 Xen 具有 stub-domain。为了避免偏袒任何特定实现，想法是扩展 estimate_instance_overhead 以返回 1 个额外的宿主机 CPU 以在声明期间考虑。希望隔离模拟器线程的用户必须使用配置为接受该规范的风味，如下所示：
hw:cpu_emulator_threads=isolate
这将表示该实例应被视为消耗 1 个额外的宿主机 CPU。用于运行模拟器线程的 pCPU 将始终配置在相关的客户机 NUMA 节点 ID 0 上，以便用户可以预测它。目前，没有希望自定义运行模拟器线程的宿主机 CPU 数量，因为在几乎所有使用情况下，只有一个就足够了。如果将来希望隔离多个宿主机 CPU 来运行模拟器线程，我们将实现 I/O 线程以增加对在宿主机 CPU 上运行客户机时使用的专用资源的粒度。
正如我们所说，将消耗一个额外的 pCPU，但此首次实现不会更新用户配额，这是出于简单性的考虑，因为配额已经在不同的场景中泄漏了。
备选方案¶
我们可以使用主机级别的可调参数来仅为运行模拟器线程全局保留一组宿主机 pCPU，而不是尝试按实例进行计算。这在简单的情况下有效，但当使用 NUMA 时，拥有更细粒度的配置来控制模拟器线程放置是高度可取的。当使用实时或专用 CPU 时，将不同 KVM 实例的模拟器线程分开将至关重要。
另一个选项是硬编码假设风味中设置的 vCPU 数量隐式包含 1 个用于模拟器的 vCPU。例如，vCPU 值为 5 将意味着 4 个实际 vCPU 和 1 个系统伪 vCPU。这可能会让租户用户和开发人员感到非常困惑。
什么都不做始终是一个选项。如果我们什么都不做，那么这将限制可以在 Nova 上运行的工作负载类型。这将对使用专用 vCPU 功能的用户产生负面影响，因为无法保证他们的 vCPU 不会被模拟器线程抢占。可以通过设置固定策略来在一定程度上通过实时方式解决此问题，即模拟器线程仅在具有非实时策略的 vCPU 上运行。这要求使用实时的所有客户机操作系统都是 SMP，但有些客户机操作系统想要实时，但仅是 UP。
数据模型影响¶
InstanceNUMATopology 对象将扩展以包含一个新字段
cpu_emulator_threads=CPUEmulatorThreadsField()
此字段将实现为具有两个选项的枚举
shared - 模拟器线程在与客户机关联的 pCPU 上浮动。
isolate - 模拟器线程隔离在一个 pCPU 上。
默认情况下将使用 ‘shared’。重要的是要注意：由于 [1] 内核中从内核命令行使用 ‘isolcpus=’ 隔离 CPU 的负载平衡已被删除。这意味着模拟器线程不会在专用于客户机的 pCPU 的联合体上浮动，而是会被限制在运行 vCPU 0 的 pCPU 上。
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
对于最终用户，使用 ‘cpu_emulator_threads’ 选项将消耗与客户机分配的 vCPU 相关的资源配额中的额外宿主机 CPU。
性能影响¶
NUMA 和计算调度器过滤器将进行一些更改，但预计它们不会变得更具计算成本到任何可测量的程度。
其他部署者影响¶
希望使用该新功能的部署者必须配置其风味以使用专用 cpu 策略 (hw:cpu_policy=dedicated)，同时将 ‘hw:cpu_emulator_threads’ 设置为 ‘isolate’。
开发人员影响¶
其他虚拟化驱动程序的开发人员可能希望使用新的风味额外规范属性和调度器会计。如果使用stub domain功能，这将对Xen hypervisor特别感兴趣。
指标或 GUI 系统的开发人员必须考虑到将由 cpu_emulator_threads 设置为 isolate 的实例消耗的宿主机 CPU 开销。
实现¶
负责人¶
- 主要负责人
sahid-ferdjaoui
- 其他贡献者
berrange
工作项¶
增强风味额外规格以考虑 hw:cpu_emulator_threads
增强 InstanceNUMATopology 以考虑 cpu_emulator_threads
使资源跟踪器处理带有 vcpus 的 ‘estimate_instance_overhead’
扩展 libvirt 的 estimate_instance_overhead
如果请求，使 libvirt 正确地固定模拟器线程。
依赖项¶
实时规格不是先决条件，但与这项工作互补
测试¶
这可以在任何能够测试当前 NUMA 和专用 CPU 策略的 CI 系统中进行测试。即，它需要能够使用 KVM 而不仅仅是 QEMU。将添加调度和驱动程序位（libvirt）的功能测试。
文档影响¶
描述NUMA和专用CPU策略使用情况的文档需要扩展到也描述这项工作引入的新选项。
