Sometimes, some GPU may have a long list of PCI addresses (say a SRIOV
GPU) or operators may have a long list of GPUs. In order to help their
lifes, let's allow device_addresses to be optional.
This means that a valid configuration could be :
[devices]
enabled_mdev_types = nvidia-35, nvidia-36
[mdev_nvidia-35]
[mdev_nvidia-36]
NOTE(sbauza): we have a slight coverage gap for testing what happens
if the groups aren't set, but I'll add it in a next patch
Related-Bug: #2041519
Change-Id: I73762a0295212ee003db2149d6a9cf701023464f
We want to cap a maximum mdevs we can create.
If some type has enough capacity, then other GPUs won't be used and
existing ResourceProviders would be deleted.
Closes-Bug: #2041519
Change-Id: I069879a333152bb849c248b3dcb56357a11d0324
This adds configuration of the default ephemeral encryption format and
sets default encryption attributes in the driver block device mapping
when needed. This includes generation of a secret passphrase when one
has not been provided.
Co-Authored-By: melanie witt <melwittt@gmail.com>
Related to blueprint ephemeral-encryption-libvirt
Change-Id: I052441076c677c0fe76a8d9421af70b0ffa1d400
Ironic in API 1.82 added the option for nodes to be associated with
a specific shard key. This can be used to partition up the nodes within
a single ironic conductor group into smaller sets of nodes that can
each be managed by their own nova-compute ironic service.
We add a new [ironic]shard config option to allow operators to say
which shard each nova-compute process should target.
As such, when the shard is set we ignore the peer_list setting
and always have a hash ring of one.
Also corrects an issue where [ironic]/conductor_group was considered
a mutable configuration; it is not mutable, nor is shards. In any
situation where an operator changes the scope of nodes managed by a
nova compute process, a restart is required.
blueprint ironic-shards
Co-Authored-By: Jay Faulkner <jay@jvf.cc>
Change-Id: Ie0c71f7bc5a62d607ffd3134837299fee952a947
RDP console was only for HyperV driver so removing the
API. As API url stay same (because same used for other
console types API), RDP console API will return 400.
Cleaning up the related config options as well as moving its
API ref to obsolete seciton.
Keeping RPC method to avoid error when old controller is used
with new compute. It can be removed in next RPC version bump.
Change-Id: I8f5755009da4af0d12bda096d7a8e85fd41e1a8c
Nova Hyper-V driver is not tested in OpenStack upstream and no maintianers.
This driver has been marked as deprecated in Antelope release. It has dependency
on the OpenStack Winstacker project which has been retired[1].
As discussed in vPTG[2], removing the HyperV driver, tests, and its config.
[1] https://review.opendev.org/c/openstack/governance/+/886880
[2] https://etherpad.opendev.org/p/nova-caracal-ptg#L301
Change-Id: I568c79bae9b9736a20c367096d748c730ed59f0e
This chnage adds the pre-commit config and
tox targets to run codespell both indepenetly
and via the pep8 target.
This change correct all the final typos in the
codebase as detected by codespell.
Change-Id: Ic4fb5b3a5559bc3c43aca0a39edc0885da58eaa2
This option was deprecated in favor of the HTTPProxyToWSGI middleware
in 26.0.0 release[1].
[1] cf906cdcc2
Related-Bug: #1967686
Change-Id: Iad8880127531dc2788d646f8a05b5c17fd9d0969
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] 34cb8f6fcd
[2] 7826148a72
Implements: blueprint libvirt-detect-sev-max-guests
Change-Id: I502e1713add7e6a1eb11ecce0cc2b5eb6a14527a
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
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
this is the inital patch of applying codespell to nova.
codespell is a programing focused spellchecker that
looks for common typos and corrects them.
i am breaking this into multiple commits to make it simpler
to read and will automate the execution of codespell
at the end of the series.
Change-Id: If24a6c0a890f713545faa2d44b069c352655274e
Ironic in API 1.82 added the option for nodes to be associated with
a specific shard key. This can be used to partition up the nodes within
a single ironic conductor group into smaller sets of nodes that can
each be managed by their own nova-compute ironic service.
We add a new [ironic]shard config option to allow operators to say
which shard each nova-compute process should target.
As such, when the shard is set we ignore the peer_list setting
and always have a hash ring of one.
blueprint ironic-shards
Change-Id: I5c1b5688c96096f4cfecfc5b16ea59d2ee5756d6
As part of the move to using Ironic shards, we document that the best
practice for scaling Ironic and Nova deployments is to shard Ironic
nodes between nova-compute processes, rather than attempting to
user the peer_list.
Currently, we only allow users to do this using conductor groups.
This works well for those wanting a conductor group per L2 network
domain. But in general, conductor groups per nova-compute are
a very poor trade off in terms of ironic deployment complexity.
Futher patches will look to enable the use of ironic shards,
alongside conductor groups, to more easily shard your ironic nodes
between nova-compute processes.
To avoid confusion, we rename the partition_key configuration
value to conductor_group.
blueprint ironic-shards
Change-Id: Ia2e23a59dbd2f13c6f74ca975c249751bebf54b2
This adds documentation for unified limits and signals deprecation of
the nova.quota.DbQuotaDriver.
Related to blueprint unified-limits-nova-tool-and-docs
Change-Id: I3951317111396aa4df36c5700b4d4dd33e721a74
This command aims to help migrate to unified limits quotas by reading
legacy quota limits from the Nova database and calling the Keystone API
to create corresponding unified limits.
Related to blueprint unified-limits-nova-tool-and-docs
Change-Id: I5536010ea1212918e61b3f4f22c2077fadc5ebfe
This change add a global greenpool which is used to manage
the greenthreads created via nova.utils.spawn(_n).
A test fixture is also added to use an isolated greenpool
which will raise an exception if a greenthread is leaked.
the fixture will optionally raise if greenlets are leaked.
This is enabled by unit test by default and is configurable
for functional tests.
This change removes all greenthread leaks from the unit
and functional tests that were detected. 7 functional
tests still leak greenlets but they have no obvious
cause. as such greenlet leaks are not treated as errors
for funtional tests by default. Greenthread leaks
are always treated as errors.
Set NOVA_RAISE_ON_GREENLET_LEAK=1|true|yes when invoking
tox to make greenlet leaks an error for functional tests.
Change-Id: I73b4684744b340bfb80da08537a745167ddea106
The [DEFAULT] enabled_ssl_apis option is supposed to contain the subset
(or the same set) of the [DEFULT] enabled_apis option.
Because we accept only the correct values for enabled_apis, we can do
the same for enabled_ssl_apis. This would allow users to notice any
wrong values which were ignored previously.
Change-Id: Ibba8f3ea307df3e81e18c3a75361e27a0f52701d
Despite having a NumInstancesFilter, we miss a weigher that would classify hosts
based on their instance usage.
Change-Id: Id232c2caf29d3443c61c0329d573a34a7481fd57
Implements-Blueprint: bp/num-instances-weigher
This change remvoes the az filter and always enabled
the placement pre-filter. As part of this removal
the config option to control enabling the pre-filter
is removed as it is now mandatory.
The AZ filter docs and tests are also removed and an upgrade
release note is added.
Depends-On: https://review.opendev.org/c/openstack/devstack/+/886972
Change-Id: Icc8580835beb2b4d40341f81c25eb1f024e70ade
Qemu>=5.0.0 bumped the default tb-cache size to 1GiB(from 32MiB)
and this made it difficult to run multiple guest VMs on systems
running with lower memory. With Libvirt>=8.0.0 it's possible to
configure lower tb-cache size.
Below config option is introduced to allow configure
TB cache size as per environment needs, this only
applies to 'virt_type=qemu':-
[libvirt]tb_cache_size
Also enable this flag in nova-next job.
[1] https://github.com/qemu/qemu/commit/600e17b26
[2] https://gitlab.com/libvirt/libvirt/-/commit/58bf03f85
Closes-Bug: #1949606
Implements: blueprint libvirt-tb-cache-size
Change-Id: I49d2276ff3d3cc5d560a1bd96f13408e798b256a
The following options have minimum values defined, and too small values
are not rounded but rejected by oslo.config.
This change updates the description to explain the actual behavior.
Closes-Bug: #2007532
Change-Id: I8d1533ae4b44d4e8f811dce554196f270e25da3e
By this patch, we now automatically power down or up cores
when an instance is either stopped or started.
Also, by default, we now powersave or offline dedicated cores when
starting the compute service.
Implements: blueprint libvirt-cpu-state-mgmt
Change-Id: Id645fd1ba909683af903f3b8f11c7f06db3401cb
Before going further, we need to somehow return the list of CPUs even offline
if they are power managed by Nova.
Co-Authored-By: Sean Mooney <smooney@redhat.com>
Partially-Implements: blueprint libvirt-cpu-state-mgmt
Change-Id: I5dca10acde0eff554ed139587aefaf2f5fad2ca5
This is the first stage of the power management series.
In order to be able to switch the CPU state or change the
governor, we need a framework to access sysfs.
As some bits can be reused, let's create a nova.filesystem helper module
that will define read-write mechanisms for accessing sysfs-specific commands.
Partially-Implements: blueprint libvirt-cpu-state-mgmt
Change-Id: Icb913ed9be8d508de35e755a9c650ba25e45aca2
In some cases on Arista VXLAN fabrics, VMs are inaccessible via network
after live migration, despite garps being observed on the fabric itself.
This patch builds on the feature
``[workarounds]/enable_qemu_monitor_announce_self`` feature as reported
in `bug 1815989 <https://bugs.launchpad.net/nova/+bug/1815989>`
This patch adds the ability to config the number of times the QEMU
announce_self monitor command is called, and add a new configuration option to
specify a delay between calling the announce_self command multiple times,
as in some cases, multiple announce_self monitor commands are required for
the fabric to honor the garp packets and the VM to become accessible via
the network after live migration.
Closes-Bug: #1996995
Change-Id: I2f5bf7c9de621bb1dc7fae5b3374629a4fcc1f46
In this patch:
- Remove the first compareCPU() call (called via the wrapper
_compare_cpu()) in _check_cpu_compatibility(), and let libvirt
handle it. (QEMU >=2.9 and libvirt >= 4.4.0 are the mininum
required versions, and upstream Nova satisfies them by a good
margin.)
- Validate the user-configured CPU models from
_get_cpu_model_mapping(). And take into account all the CPU flags
before calling _compare_cpu().
(Suggested-by: Sean Mooney -- thanks!)
- Add a workaround to allow skipping the remaining compareCPU() call
in _check_cpu_compatibility() as a potential future-proof (because
we cannot test all possible CPU models and hardware). Unlike the
removed first call, this call takes into account the extra CPU flags
provided by the user into account when evaluating guest CPU model
compatibility.
As a follow up comes the patch[1] that replaces the older libvirt CPU
API with the newer one.
[1] https://review.opendev.org/c/openstack/nova/+/869950 -- libvirt:
Replace usage of compareCPU() with compareHypervisorCPU()
Change-Id: I8ef9db851b37c5249d2efbe09a15a1ddbae8205d
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Sylvain Bauza
yatinkarel