libvirt - 存储并允许更改默认机器类型¶

https://blueprints.launchpad.net/nova/+spec/libvirt-default-machine-type

问题描述¶

QEMU 的“机器类型”概念可以被认为是一种虚拟芯片组，它提供了一些默认设备（例如 PCIe 显卡、以太网控制器、SATA 控制器等）。QEMU 支持 x86 主机的两种主要“机器类型”变体：（a）pc，对应于 Intel 的 I440FX 芯片组，截至撰写本文时已有二十二年历史；以及（b）q35，对应于 Intel 的 82Q35 芯片组（发布于 2007 年；相对较新的芯片组）。对于 AArch64 主机，机器类型称为：virt。

pc 机器类型被认为是“遗留”的，不支持一些现代功能。尽管在撰写本文时，上游 QEMU 尚未达成协议以删除 pc 机器类型的最新版本变体，但一些长期稳定的 Linux 发行版（CentOS、RHEL，可能还有其他发行版）正在迁移到仅支持 q35。

libvirt virt 驱动程序长期以来一直支持配置每个计算主机的默认机器类型，通过 [libvirt]/hw_machine_type 可配置项，供基于 QEMU 和 KVM 的实例使用。此可配置项为每个主机架构提供默认机器类型，当实例没有提供相应的 hw_machine_type 镜像属性时使用。

当未定义此可配置项时，libvirt 驱动程序依赖于以下硬编码字典，其中包含每个架构的默认机器类型

default_mtypes = {
    obj_fields.Architecture.ARMV7: "virt",
    obj_fields.Architecture.AARCH64: "virt",
    obj_fields.Architecture.S390: "s390-ccw-virtio",
    obj_fields.Architecture.S390X: "s390-ccw-virtio",
    obj_fields.Architecture.I686: "pc",
    obj_fields.Architecture.X86_64: "pc",
}

然而，Nova 并未记录实例使用的机器类型。因此，可配置项（如果设置）和 libvirt 驱动程序中的硬编码默认值必须在环境中的主机之间保持一致，并且不能在不更改暴露给客户机的模拟硬件的情况下进行更改，从而破坏实例在硬重启、迁移或重新创建操作后的应用程序二进制接口 (ABI)。

本规范旨在概述我们如何通过始终存储实例的生命周期内的机器类型来避免这种情况。这将允许操作员和开发人员随着时间的推移更改默认机器类型，而不会破坏现有实例。

用例¶

作为 libvirt 驱动程序的开发人员，我希望更新给定主机架构的默认机器类型，以利用较新的模拟硬件模型和 QEMU 的功能。
作为现有 OpenStack 环境的操作员，我希望默认使用新的机器类型，同时不破坏现有实例的 ABI。
作为用户，我希望确保实例的 ABI 在实例的整个生命周期内保持相同，无论操作员或 virt 驱动程序开发人员进行哪些默认可配置项更改。

提议的变更¶

在实例的初始启动期间或计算服务的 init_host 期间，将使用的机器类型存储在实例系统元数据表中，用于所有没有存储 hw_machine_type 的正在运行的实例。
确保在硬重启、迁移或导致域被重新定义（除了实例的完全重建）的任何其他操作期间使用存储的机器类型。
在重建期间取消设置存储的机器类型，从而可以使用新的镜像定义的机器类型或主机配置的默认值。
允许操作员通过新的 get_machine_type nova-manage 命令获取实例的机器类型。
允许操作员通过新的 update_machine_type nova-manage 命令设置或更新 vm_state 为 STOPPED、SHELVED 或 SHELVED_OFFLOADED 的实例的机器类型。

备选方案¶

N/A

数据模型影响¶

机器类型将存储在 Instance 对象下的 system_metadata 字段中，该字段是一个使用键 hw_machine_type 的 DictOfNullableStringsField。

REST API 影响¶

N/A

安全影响¶

N/A

通知影响¶

N/A

其他最终用户影响¶

N/A

性能影响¶

N/A

其他部署者影响¶

部署者现在可以更改给定架构的默认机器类型，而不会更改呈现给现有实例的基础 ABI。

开发人员影响¶

Libvirt 驱动程序开发人员现在可以更改默认机器类型，而不会更改呈现给现有实例的基础 ABI。

升级影响¶

在从 Victoria（或更早版本）升级到 Wallaby 时，libvirt 驱动程序将在启动时尝试记录主机上每个非删除实例的当前机器类型。这包括 STOPPED、PAUSED 和 SHELVED 实例。在可能的情况下，这将直接从底层客户机域查询，但如果未找到，则将从实例镜像元数据属性 hw_machine_type、[libvirt]/hw_machine_type 可配置项或遗留硬编码默认值获取。

对于标记为 SHELVED_OFFLOADED 且因此不驻留在计算主机上的非删除实例，将引入一个新的 update_machine_type nova-manage 命令，该命令允许操作员设置机器类型。如上所述，这将首先依赖于任何存储的镜像属性，但如果没有找到，则需要调用者提供特定的机器类型。

将引入一个 nova-status 命令，以允许操作员确定环境中所有非删除实例是否已记录机器类型。

虽然别名机器类型（例如 q35）将被记录为推荐选择，但管理员和操作员将允许配置每个镜像或给定计算主机上的架构的机器类型版本。

因此，用于设置 SHELVED_OFFLOADED 实例的机器类型的相同的 update_machine_type nova-manage 命令也将能够更新 vm_state 为 STOPPED、SHELVED 或 SHELVED_OFFLOADED 的实例的机器类型。

这将允许操作员在不完全重建实例的情况下，随着时间的推移在这些版本化的机器类型之间迁移实例。

应该注意的是，默认情况下，此命令不允许在实际的机器类型之间更改机器类型，例如从 pc 到 q35 或在机器类型的较新版本和较旧版本之间。

默认情况下，两者仍然需要使用具有关联 hw_machine_type 镜像属性的新的镜像或一旦启动计算主机上的 [libvirt]/hw_machine_type 默认值已更新，对实例进行完全重建。

将包含一个 --force 标志，以允许操作员强制执行这两种情况，并发出警告，该操作可能会在实例重新启动后破坏实例内的 ABI。

实现¶

负责人¶

主要负责人: lyarwood

其他贡献者

功能联络人¶

功能联络人: lyarwood

工作项¶

在实例的初始启动期间或计算服务的 init_host 期间，将使用的机器类型存储在实例 extras 表中，用于所有正在运行的实例。
确保在硬重启、迁移或导致域被重新定义（除了实例的完全重建）的任何其他操作期间使用存储的机器类型。
在重建期间取消设置存储的机器类型，从而可以使用新的镜像定义的机器类型或主机配置的默认值。
引入一个 get_machine_type nova-manage 命令，以允许操作员获取实例的记录机器类型。
引入一个 update_machine_type nova-manage 命令，以允许操作员设置或更新给定实例的记录机器类型，该实例的 vm_state 为 STOPPED、SHELVED 或 SHELVED_OFFLOADED，从而随着时间的推移实现版本化机器类型之间的升级。
引入一个 nova-status 升级检查，以确保环境中给定主机或所有主机上的所有非删除实例的机器类型都已更新。
编写关于上述内容的详细操作员文档。

依赖项¶

N/A

测试¶

将扩展 grenade 作业，以确保在启动计算服务时使用 libvirt 驱动程序时填充 machine_type 字段。

文档影响¶

将编写关于升级影响和可配置项使用的详细操作员文档。

参考资料¶

历史¶

修订版¶
发布名称	描述
Wallaby	引入

libvirt - 存储并允许更改默认机器类型