Select CPU model from a list of CPU models¶
In the libvirt driver, currently we use
cpu_mode is set to
custom) to specify the CPU model the
instance should use on this host. This could have implications on
availability of compute nodes for live migration.
If the instance lands on a compute node which uses an “advanced” CPU model, then it may only live-migrate to a few of the cluster’s compute nodes or fail to live-migrate.
The admin can configure all compute nodes use the same CPU model. But some users may request “advanced” CPU flags for some special application (such as video edit and scientific compute).
As an admin, I would like to live-migrate instances among all compute nodes even if there are different CPU models in the the cluster.
As a user, I would like to boot an instance on a host supporting specific CPU features and for the instance to be live-migratable to as many other hosts as possible that also support the instance.
cpu_model config attribute with
cpu_models, which is
an ordered list of CPU models the host supports. It is expected that the
list is ordered so that the more common and less advanced CPU models are
listed earlier. The reported CPU feature traits will be the union of features
of all the CPU models. Mark
cpu_model is deprecated, so existing confs
will continue to work, but will log a warning.
Note that this is not add a new config attribute, this is rename exist config
attribute and extend it from singular to plural variants. Mark
deprecated is to maintain capatibility with the old confs. Otherwise,
supporting both the singular and plural variants at the same time (or even
after we deprecate
cpu_model) could lead to confusion and avoidable typos.
End users specify CPU features they require through traits . If the
cpu_mode is set to
custom, the libvirt driver will select the first
CPU model in the
cpu_models (combined with
cpu_model_extra_flags if it is specified) that can provide the
required feature traits. This would make it more likely that the
instance could be live-migrated later on. If no CPU feature traits are
specified then the instance will be configured with the first CPU model
in the list.
For example, if the end user specifies CPU features
openstack flavor set 1 --property trait:HW_CPU_X86_AVX=required --property trait:HW_CPU_X86_AVX2=required
cpu_models is configured like this:
[libvirt] cpu_mode = custom cpu_models = SandyBridge,IvyBridge,Haswell,Broadwell
Haswell, the first CPU model supporting both
avx2, will be chosen by libvirt.
cpu_models specified, it should be checked
against each configured items to make sure they are compatible with host CPU.
Any incompatibility should prevent the compute service from starting and force
the user to correct the configuration.
A few related points:
cpu_modelwill be ignored.
Typically, data centers only have a handful of CPU generations deployed, so the
cpu_modelsis expected to contain not as many CPUs as shown in the contrived example earlier.
The value in the option
cpu_modelswill be made case-insensitive.
Data model impact¶
REST API impact¶
Other end user impact¶
Other deployer impact¶
Add some information in the config option help text indicating that the operator should be careful to only specify models which can be fully supported in hardware. If they specify models with CPU features that are emulated by QEMU it could result in performance degradation.
Virt driver changes.
Add/modify unit tests.
Add unit tests.
Update release note for introducing
-  Stein iteration of this spec:
-  The work in progresss spec to add more “hypervisor-literate” CPU
APIs to Nova – https://review.openstack.org/#/c/645814/ (“CPU selection with hypervisor consideration”)