LibvirtXMLCPUModel

Essex 及更早版本的 libvirt 驱动程序在生成虚拟机 XML 时使用 Cheetah 模板系统。虽然这种方法有很多缺点（参见 https://wiki.openstack.org/LibvirtXMLConfigAPIs），但有一个积极的方面，那就是部署 Nova 的最终用户可以自定义 XML 以添加官方不支持的功能。其中一个最重要的缺失功能是配置暴露给 KVM 虚拟机的 CPU 模型。指定 CPU 模型的原因有几个

• 为了通过暴露主机 CPU 的新功能来最大限度地提高虚拟机的性能
• 为了确保所有机器上一致的默认 CPU，消除对可变 QEMU 默认值的依赖。

在 libvirt 中，CPU 通过提供基本的 CPU 模型名称（这是特征标志的简写）、一组额外的特征标志以及拓扑（套接字/核心/线程）来指定。libvirt KVM 驱动程序提供许多标准的 CPU 模型名称（定义在 /usr/share/libvirt/cpu_map.xml 中）

• "486", "pentium", "pentium2", "pentiumpro", "coreduo", "n270", "pentiumpro", "qemu32", "kvm32", "cpu64-rhel5", "cpu64-rhel5", "kvm64", "pentiumpro", "Conroe" "Penryn", "Nehalem", "Westmere", "pentiumpro", "cpu64-rhel5", "cpu64-rhel5", "Opteron_G1", "Opteron_G2", "Opteron_G3, "Opteron_G4"

也可以通过两种方式请求主机 CPU 模型

• "host-model" - 这将导致 libvirt 识别上述列表中与主机 CPU 最匹配的命名 CPU 模型，然后请求额外的 CPU 标志以完成匹配。这应该提供接近最大功能/性能，同时保持良好的可靠性/兼容性，如果虚拟机迁移到具有略微不同主机 CPU 的另一个主机。注意，由于 libvirt 检测主机 CPU 的方式，使用 host-model 创建的 CPU 配置可能无法按预期工作。客体 CPU 可能会通过使用 CPU 功能和其他参数（如 CPUID 级别）的组合来混淆客体操作系统（例如，甚至可能导致内核崩溃），而这些功能和参数无法正常工作。

• "host-passthrough" - 这将导致 libvirt 告诉 KVM 以未经修改的方式传递主机 CPU。与 host-model 不同，host-model 不仅匹配特征标志，而是匹配主机 CPU 的每一个细节。这提供了绝对的最佳性能，并且对于某些检查低级 CPU 细节的应用程序来说非常重要，但它会牺牲迁移性。虚拟机只能迁移到完全匹配的主机 CPU。

libvirt 在 CPU 模型方面的功能范围非常广泛，并在 http://berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-qemukvm/ 中进行了描述。nova.virt.libvirt.connection 中的 'cpu_compare' 方法已经处理了检查主机之间的 CPU 兼容性，以允许调度器在迁移期间确保正确放置虚拟机。因此，Nova 的主要缺失功能仅仅是配置虚拟机 CPU 模式 + 模型的能力

在大多数情况下，主机管理员指定虚拟机 CPU 配置在每个主机的配置文件 (/etc/nova/nova.conf) 中就足够了。这将通过引入两个新的配置参数来实现

• libvirt_cpu_mode = custom|host-model|host-passthrough
• libvirt_cpu_model = .../usr/share/libvirt/cpu_map.xml 中的命名模型之一... (此参数仅在 libvirt_cpu_mode=custom 时有效)

eg1

 libvirt_cpu_mode = host-model

eg2

 libvirt_cpu_mode = custom
 libvirt_cpu_model = Opteron_G3

未来，可能需要将 CPU 模型配置参数添加到实例类型中

一个复杂之处在于，libvirt 0.9.10 之前的版本不支持 host-model CPU 模式。相反，应用程序需要将模型从主机 capabilities XML 复制到虚拟机 XML 中。由于 Nova 支持最低 libvirt 版本为 0.9.7，因此需要向后兼容的代码。