Following keys like HW_CPU_X86_SVM and HW_CPU_X86_VMX are placed in TRAITS_CPU_MAPPING as part of a tuple instead of being direct keys.
This patch will flaten these tuples.
Closes-Bug: #2043030
Change-Id: Ia600ceb22c5939117095593b97ed94735c8f953c
In nova-live-migration job, evacuation failures are causing
POST_FAILURE.
As per discussion on bug, it looks like 500 is coming from cinder
which is cause of this failure.
Similar to attachment_delete method, this change adds a retry
mechanism in cinder API calls attachment_update method.
Closes-Bug: #1970642
Change-Id: I1da3c8481f7e7a1e8776cf03f5c4cf117b7fabaa
Libvirt has implemented the capability to expose maximum number of
SEV guests and SEV-ES guests in 8.0.0[1][2]. This allows nova to detect
maximum number of memory encrypted guests using that feature.
The detection is not used if the [libvirt] num_memory_encrypted_guests
option is set to preserve the current behavior.
Note that current nova supports only SEV and does not support SEV-ES,
so this implementation only uses the maximum number of SEV guests.
The maximum number of SEV-ES guests will be used in case we implement
support for SEV-ES.
[1] https://gitlab.com/libvirt/libvirt/-/commit/34cb8f6fcd6a56a7bbcef2f7402def1682509e16
[2] https://gitlab.com/libvirt/libvirt/-/commit/7826148a72c97367fc6aaa76397fe92d32169723
Implements: blueprint libvirt-detect-sev-max-guests
Change-Id: I502e1713add7e6a1eb11ecce0cc2b5eb6a14527a
The CPU power management feature of the libvirt driver, enabled with
[libvirt]cpu_power_management, only manages dedicated CPUs and does not
touch share CPUs. Today nova-compute refuses to start if configured
with [libvirt]cpu_power_management=true [compute]cpu_dedicated_set=None.
While this is functionally not limiting it does limit the possibility to
independently enable the power management and define the
cpu_dedicated_set. E.g. there might be a need to enable the former in
the whole cloud in a single step, while not all nodes of the cloud will
have dedicated CPUs configured.
This patch removes the strict config check. The implementation already
handles each PCPU individually, so if there are an empty list of PCPUs
then it does nothing.
Closes-Bug: #2043707
Change-Id: Ib070e1042c0526f5875e34fa4f0d569590ec2514
For live migration the libvirt driver already supports generating the
migration URL based on the compute host hostname if so configured.
However for the non live move operations the driver always used the IP
address of the compute host based on [DEFAULT]my_ip.
Some deployments rely on DNS to abstract the IP address management. In
these environments it is beneficial if nova allows connection between
compute hosts based on the hostname (or FQDN) of the host instead of
trying to configure [DEFAUL]my_ip to an IP address.
This patch introduces a new config option
[libvirt]migration_inbound_addr that is used to determine the address
for incoming move operations (cold migrate, resize, evacuate). This
config is defaulted to [DEFAULT]my_ip to keep the configuration backward
compatible. However it allows an explicit hostname or FQDN to be
specified, or allows to specify '%s' that is then resolved to the
hostname of compute host.
blueprint: libvirt-migrate-with-hostname-instead-of-ip
Change-Id: I6a80b5620f32770a04c751143c4ad07882e9f812
Some of the object unit tests grub Mock object unintentionally, and
that results in failure during initializing an versioned object,
because the Mock object does not present its version correctly.
This fixes that problem
The sqlalchemy-2x job is made non-voting because this job requires
oslo.utils 6.3.0 which is blocked by this problem.
Closes-Bug: #2043116
Related-Bug: #2042886
Change-Id: Id1c1b77c020e2d8f0ac61c2aee86c9f37d388d53
That's one giant hole in our docs. Whoops.
Change-Id: I8ac6f204dd3ebe424dfe4335a491b8c9df7d0cc4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
We recently found a rolling-upgrade bug on rebuild so we need to make
sure that grenade-multinode can verify all our instance actions.
Given we pin the compute RPC API version to the N-1 compute one, we are
sure that all RPC calls continue to behave the previous release.
NOTE : Given the previous cycle was already supporting 6.2 RPC version,
we can't test here the previous problems hence why this is the last
patch from the series.
Change-Id: I1d8deb139922494dd74ff32965fd7dd74d1d768b
Related-Bug: #2040264
By I0d889691de1af6875603a9f0f174590229e7be18 we broke rebuild for Yoga
or older computes.
By I9660d42937ad62d647afc6be965f166cc5631392 we broke rebuild for Zed
computes.
Fixing this by making the parameters optional.
Change-Id: I0ca04045f8ac742e2b50490cbe5efccaee45c5c0
Closed-Bug: #2040264
We forgot that we automatically pin our RPC calls to the RPC version
that the older compute supports, so when rolling-upgrading computes, we
continue to use either Yoga or Zed versions for example when upgrading
to 2023.1.
Since the new parameters aren't optional, we broke the
rebuild_instance() method then for Yoga to Zed and Zed to 2023.1.
Change-Id: Icf340f3d4c5ce0a4b7388003f168e7c479e58eee
Related-Bug: #2040264
The nova-cert service was removed during Pike cycle by 2bcee77e3 and
the upgrade_levels option for this service was formally deprecated
during rocky by f0d2925bc7 . The other upgrade_levels options which
were deprecated at the same time were already removed.
Change-Id: I385dc41a3a69c51d60acced21cfdf6c6dd0cc724
The text alignment for one of the code blocks on the unified limits
admin doc page being off by one causes the rendered code block to be
slightly askew.
This fixes the alignment and also adjusts inconsistencies in code block
text alignment throughout the unified limits docs.
Change-Id: I52b61ad63a9788fe6443284db1a4e9012674aafe
This is being reverted because it's overly strict and complaining
that upgrade-related work has not been done before it should have or
needs to have been done. This may be re-added later when we start
depending on these linkages.
Closes-Bug: #2039597
This reverts commit 27f384b7ac.
Change-Id: Ifa5b82ca3b83d0ba481aa7a062827bd8e838989a
Libvirt's node device driver accumulates and reports information
about host devices. Network capabilities reported by node device
driver for NIC contain information about HW offloads supported
by this NIC.
One of possible features reported by node device driver is
switchdev: a NIC capability to implement VFs similar to actual
HW switch ports (also referred to as SR-IOV OVS hardware offload).
From Neutron perspective, vnic-type should be set to "direct" and
"switchdev" capability should be added to port binding profile to
enable HW offload (there are also configuration steps on compute
hosts to tune NIC config).
This patch was written to automatically translate "switchdev" from
VF network capabilities reported by node device driver to Neutron
port binding profile and allow user to skip manual step that
requires admin privileges.
Other capabilities are also translated: they are not used right
now, but provide visibility and can be utilized later.
Closes-bug: #2020813
Closes-bug: #2008238
Change-Id: I3b17f386325b8f42c0c374f766fb21c520161a59
Zuul