openstack/nova
Code Issues Proposed changes
de7a8f9e44
nova/doc/source/admin/adv-config.rst
Stephen Finucane 9999bce00f Fail to live migration if instance has a NUMA topology 
Live migration is currently totally broken if a NUMA topology is
present. This affects everything that's been regrettably stuffed in with
NUMA topology including CPU pinning, hugepage support and emulator
thread support. Side effects can range from simple unexpected
performance hits (due to instances running on the same cores) to
complete failures (due to instance cores or huge pages being mapped to
CPUs/NUMA nodes that don't exist on the destination host).

Until such a time as we resolve these issues, we should alert users to
the fact that such issues exist. A workaround option is provided for
operators that _really_ need the broken behavior, but it's defaulted to
False to highlight the brokenness of this feature to unsuspecting
operators.

Conflicts:
	nova/conf/workarounds.py
	nova/tests/unit/api/openstack/compute/admin_only_action_common.py
	nova/tests/unit/api/openstack/compute/test_migrate_server.py
	nova/tests/unit/conductor/tasks/test_live_migrate.py

NOTE(stephenfin): stable/rocky conflicts due to removal of
'report_ironic_standard_resource_class_inventory' option and addition of
change Iaea1cb4ed93bb98f451de4f993106d7891ca3682 on master.

NOTE(stephenfin): stable/queens conflicts due to presence of
the 'enable_consoleauth' configuration option and change
I83b473e9ba557545b5c186f979e068e442de2424 (Mox to mock) in stable/rocky.
A hyperlink is removed from the config option help text as the version
of 'oslo.config' used here does not parse help text as rST (bug 1755783).

Change-Id: I217fba9138132b107e9d62895d699d238392e761
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Related-bug: #1289064
(cherry picked from commit ae2e5650d1)
(cherry picked from commit 52b8973442)
2019-07-02 14:25:26 +00:00

1.4 KiB
Raw Blame History

Advanced configuration

OpenStack clouds run on platforms that differ greatly in the capabilities that they provide. By default, the Compute service seeks to abstract the underlying hardware that it runs on, rather than exposing specifics about the underlying host platforms. This abstraction manifests itself in many ways. For example, rather than exposing the types and topologies of CPUs running on hosts, the service exposes a number of generic CPUs (virtual CPUs, or vCPUs) and allows for overcommitting of these. In a similar manner, rather than exposing the individual types of network devices available on hosts, generic software-powered network ports are provided. These features are designed to allow high resource utilization and allows the service to provide a generic cost-effective and highly scalable cloud upon which to build applications.

This abstraction is beneficial for most workloads. However, there are some workloads where determinism and per-instance performance are important, if not vital. In these cases, instances can be expected to deliver near-native performance. The Compute service provides features to improve individual instance for these kind of workloads.

pci-passthrough cpu-topologies huge-pages virtual-gpu