openstack/nova
Code Issues Proposed changes

docs: Clarify host-model, host-passthrough differences

Browse Source 
Based on review feedback from kashyap.

Change-Id: Ief5debad29c10a0903f70d68d5bee21b4c1424b0
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This commit is contained in:
Stephen Finucane
2021-03-23 10:52:28 +00:00
parent ee1443bb3f
commit be03ca7be7
1 changed files with 41 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

62
doc/source/admin/cpu-models.rst
View File

@@ -44,21 +44,38 @@ Host model
~~~~~~~~~~ ~~~~~~~~~~
If :oslo.config:option:`cpu_mode=host-model <libvirt.cpu_mode>`, the CPU model If :oslo.config:option:`cpu_mode=host-model <libvirt.cpu_mode>`, the CPU model
in ``/usr/share/libvirt/cpu_map/*.xml`` that most closely matches the host, and in ``/usr/share/libvirt/cpu_map/*.xml`` that most closely matches the host and
requests additional CPU flags to complete the match. This configuration requests additional CPU flags to complete the match. This CPU model has a
provides the maximum functionality and performance and maintains good number of advantages:
reliability.
With regard to enabling and facilitating live migration between * It provides almost all of the host CPU features to the guest, thus providing
compute nodes, you should assess whether ``host-model`` is suitable close to the maximum functionality and performance possible.
for your compute architecture. In general, using ``host-model`` is a
safe choice if your compute node CPUs are largely identical. However, * It auto-adds critical guest CPU flags for mitigation from certain security
if your compute nodes span multiple processor generations, you may be flaws, *provided* the CPU microcode, kernel, QEMU, and libvirt are all
better advised to select a ``custom`` CPU model. updated.
* It computes live migration compatibility, with the caveat that live migration
in both directions is not always possible.
In general, using ``host-model`` is a safe choice if your compute node CPUs are
largely identical. However, if your compute nodes span multiple processor
generations, you may be better advised to select a ``custom`` CPU model.
The ``host-model`` CPU model is the default for the KVM & QEMU hypervisors The ``host-model`` CPU model is the default for the KVM & QEMU hypervisors
(:oslo.config:option:`libvirt.virt_type`\ =``kvm``/``qemu``) (:oslo.config:option:`libvirt.virt_type`\ =``kvm``/``qemu``)
.. note::
As noted above, live migration is not always possible in both directions
when using ``host-model``. During live migration, the source CPU model
definition is transferred to the destination host as-is. This results in the
migrated guest on the destination seeing exactly the same CPU model as on
source even if the destination compute host is capable of providing more CPU
features. However, shutting down and restarting the guest on the may present
different hardware to the guest, as per the new capabilities of the
destination compute.
Host passthrough Host passthrough
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
@@ -69,19 +86,22 @@ every last detail of the host CPU is matched. This gives the best performance,
and can be important to some apps which check low level CPU details, but it and can be important to some apps which check low level CPU details, but it
comes at a cost with respect to migration. comes at a cost with respect to migration.
In ``host-passthrough`` mode, the guest can only be live-migrated to a In ``host-passthrough`` mode, the guest can only be live-migrated to a target
target host that matches the source host extremely closely. This host that matches the source host extremely closely. This includes the physical
definitely includes the physical CPU model and running microcode, and CPU model and running microcode, and may even include the running kernel. Use
may even include the running kernel. Use this mode only if: this mode only if your compute nodes have a very large degree of homogeneity
(i.e. substantially all of your compute nodes use the exact same CPU generation
and model), and you make sure to only live-migrate between hosts with exactly
matching kernel versions. Failure to do so will result in an inability to
support any form of live migration.
* Your compute nodes have a very large degree of homogeneity .. note::
(i.e. substantially all of your compute nodes use the exact same CPU
generation and model), and you make sure to only live-migrate
between hosts with exactly matching kernel versions, *or*
* You decide, for some reason and against established best practices, The reason for that it is necessary for the CPU microcode versions to match
that your compute infrastructure should not support any live is that hardware performance counters are exposed to an instance and it is
migration at all. likely that they may vary between different CPU models. There may also be
other reasons due to security fixes for some hardware security flaws being
included in CPU microcode.
Custom Custom
~~~~~~ ~~~~~~