Live migrating to a host with cpu_shared_set configured will now
update the VM's configuration accordingly.
Example: live migrating a VM from source host with cpu_shared_set=0,1
to destination host with cpu_shared_set=2,3 will now update the
VM configuration.
(<vcpu cpuset="0-1"> will be updated to <vcpu cpuset="2-3">).
Related-Bug: #1869804
Change-Id: I7c717503eba58088094fac05cb99b276af9a3460
Previously, live migrations completely ignored CPU power management.
This patch makes sure that we correctly:
* Power up the cores on the destination during pre_live_migration, as
we need them powered up before the instance starts on the
destination.
* If the live migration is successful, power down the vacated cores on
the source.
* In case of a rollback, power down the cores previously powered up on
pre_live_migration.
Closes-bug: 2056613
Change-Id: I787bd7807950370cd865f29b95989d489d4826d0
We want to test power management in our functional tests in multinode
scenarios (ex: live migration).
This was previously impossible because all the methods in
nova.virt.libvirt.cpu.api and were at the module level, meaning both
source and destination libvirt drivers would call the same method to
online and offline cores. This made it impossible to maintain distinct
core power state between source and destination.
This patch inserts a nova.virt.libvirt.cpu.api.API class, and gives
the libvirt driver a cpu_api attribute with an instance of that
class. Along with the tiny API.core() helper, this allows new
functional tests in the subsequent patches to stub out the core
"model" code with distinct objects on the source and destination
libvirt drivers, and enables a whole bunch of testing (and fixes!)
around live migration.
Related-bug: 2056613
Change-Id: I052535249b9a3e144bb68b8c588b5995eb345b97
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
With Libvirt v8.7.0+, the <maxphysaddr> sub-element
of the <cpu> element specifies the number of vCPU
physical address bits [1].
[1] https://libvirt.org/news.html#v8-7-0-2022-09-01
New flavor extra_specs and image properties are added to
control the physical address bits of vCPUs in Libvirt guests.
The nova-scheduler requests COMPUTE_ADDRESS_SPACE_* traits
based on them. The traits are already defined in os-traits
v2.10.0. Also numerical comparisons are performed at
both compute capabilities filter and image props filter.
blueprint: libvirt-maxphysaddr-support-caracal
Change-Id: I98968f6ef1621c9fb4f682c119038e26d62ce381
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Right now we're logging this as an unexpected failure, complete with
full traceback. However, this is expected if an image is deleted
mid-snapshot, as is the case in one of our tempest tests.
Change-Id: I6eb76c0500c7940778b7a15ac5202659ef92a82a
The destination lookups at the src mdev types and returns its own
mdevs using the same type. We also reserve them by an internal dict
and we make sure we can cleanup this dict if the live-migration aborts.
Partially-Implements: blueprint libvirt-mdev-live-migrate
Change-Id: I4a7e5292dd3df63943bd9f01803fa933e0466014
This enables use of ephemeral encryption for swap disks.
The 'encrypted' attribute is intended to be read-only, so we will raise
an error if something attempts to save it later.
DriverImageBlockDevice and DriverEphemeralBlockDevice are already not
saving updates to their 'encrypted' attributes, so the same error
checking is added to them as well for consistency.
Related to blueprint ephemeral-encryption-libvirt
Change-Id: Id30577699928180eff6a5b78390ce9e3efa28b16
Now that the source knows that both the computes support the right
libvirt version, it passes to the destination the list of mdevs it has
for the instance. By this change, we'll verify if the types of those
mdevs are actually supported by the destination.
On the next change, we'll pass the destination mdevs back to the
source.
Partially-Implements: blueprint libvirt-mdev-live-migrate
Change-Id: Icb52fa5eb0adc0aa6106a90d87149456b39e79c2
Since only qemu 8.1 and libvirt 8.6.0 supports mdev live-migration,
we need to verify the values of the hypervisor for both the source
and the destination.
If one of them are older, the conductor raises an exception that will
eventually fact the API to return an HTTP500.
Change-Id: I17f170143c58401b8b0a5a93e83355b1f7178ab5
Partially-Implements: blueprint libvirt-mdev-live-migrate
When deleting an instance, always send VIR_DOMAIN_UNDEFINE_NVRAM to
delete the NVRAM file, regardless of whether the image is of type UEFI.
This prevents a bug when rebuilding an instance from an UEFI image to a
non-UEFI image.
Closes-Bug: #1997352
Change-Id: I24648f5b7895bf5d093f222b6c6e364becbb531f
Signed-off-by: Simon Hensel <simon.hensel@inovex.de>
The 'reenlightenment' hyperv enlightenment will cause
instances live-migration to fail (KVM currently doesn’t
fully support reenlightenment notifications, see
www.qemu.org/docs/master/system/i386/hyperv.html),
so don't enable it now.
Change-Id: I6821819450bc96e4304125ea3b76a0e462e6e33f
Closes-Bug: #2046549
Related-Bug: #2009280
Live migration of paused instance fails when VIR_MIGRATE_POSTCOPY
flag is set. In this patch, the flag is unset to permit live migration
of paused instance.
Change-Id: Ib5cbc948cb953e35a22bcbb859976f0afddcb662
Closes-Bug: #1671011
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 bumps the version of flake8 and resolves some erroneous failures in
f-strings. A number of new E721 (do not compare types) class errors are
picked up, which are all addressed.
Change-Id: I7a1937b107ff3af8d1e5fe23fc32b120ef4697f7
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
In I008841988547573878c4e06e82f0fa55084e51b5 we started enabling a
bunch of libvirt enlightenments for Windows unconditionally. Turns
out, the `evmcs` enlightenment only works on Intel hosts, and we broke
the ability to run Windows guests on AMD machines. Until we become
smarter about conditionally enabling evmcs (with something like traits
for host CPU features), just stop enabling it at all.
Change-Id: I2ff4fdecd9dc69de283f0e52e07df1aeaf0a9048
Closes-bug: 2009280
Even when having specified a single mdev type,
operator still might want to expose only one
of available mdev-capable PCI devices to users,
or use a custom resource class for it.
NOTE(sbauza): That patch isn't changing the current behaviour (you
can see the tests) but it just removes a weird limitation (that I
wrote, sorry folks !)
Co-Authored-By: Sylvain Bauza <sbauza@redhat.com>
Change-Id: I9f42410e407902b2f562adaa506f14cbc69898d4
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
This makes us attempt to first look up a disk device by alias using
the volume_uuid, before falling back to the old method of using the
guest target device name.
Related to blueprint libvirt-dev-alias
Change-Id: I1dfe4ad3df81bc810835af9b09cfc6c06e9a5388
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 minimum required version of QEMU is now 5.2.0, and of libvirt is
7.0.0.
The below version constants get removed:
- MIN_LIBVIRT_VIOMMU_AW_BITS
- MIN_LIBVIRT_VDPA
- MIN_QEMU_VDPA
- MIN_LIBVIRT_AARCH64_CPU_COMPARE
Adjust the related unit tests accordingly.
Change-Id: Ie805eb7fa59f9f7728da27fddbd6e968e971a2e4
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Based on the Libvirt and QEMU versions, two traits,
COMPUTE_ADDRESS_SPACE_PASSTHROUGH and COMPUTE_ADDRESS_SPACE_EMULATED,
are controlled. Since the two are supported from the same version on
the Libvirt and QEMU, Nova handles them in the same way.
Blueprint: libvirt-maxphysaddr-support
Depends-On: https://review.opendev.org/c/openstack/os-traits/+/871226
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Change-Id: If6c7169b7b8f43ad15a8992831824fb546e85aab
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
For the "C" release (2024), the NEXT_MIN_{LIBVIRT,QEMU} to be the
following:
NEXT_MIN_LIBVIRT_VERSION = (8, 0, 0)
NEXT_MIN_QEMU_VERSION = (6, 2, 0)
The above NEXT_MIN version is picked based on Ubuntu "Jammy" (22.04).
It is the lowest common denominotor among Debian 11 ("Bullseye"), Ubuntu
22.04 ("Jammy"), and CentOS 9 Stream.
- Ubuntu 22.04 (Jammy):
- libvirt-daemon: 8.0.0-1ubuntu7.5
- qemu-system-x86: 6.2+dfsg-2ubuntu6.11
- Debian 11 (Bullseye):
- libvirt: 7.0.0-3+deb11u2
- qemu: 5.2+dfsg-11+deb11u2
- CentOS Stream 9:
- libvirt-daemon-kvm-9.3.0-2.el9.x86_64.rpm
- qemu-kvm-8.0.0-4.el9.x86_64.rpm
Change-Id: I1b6fcffbfaf940d094957e95fee0f4b624dd0832
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
The 'force' parameter of os-brick's disconnect_volume() method allows
callers to ignore flushing errors and ensure that devices are being
removed from the host.
We should use force=True when we are going to delete an instance to
avoid leaving leftover devices connected to the compute host which
could then potentially be reused to map to volumes to an instance that
should not have access to those volumes.
We can use force=True even when disconnecting a volume that will not be
deleted on termination because os-brick will always attempt to flush
and disconnect gracefully before forcefully removing devices.
Closes-Bug: #2004555
Change-Id: I3629b84d3255a8fe9d8a7cea8c6131d7c40899e8
Hacking has bumped the version of flake8 that it's using to 5.0 in its
6.0.1 release. This turns up quite a few pep8 errors lurking in our
code. Fix them.
Needed-by: https://review.opendev.org/c/openstack/hacking/+/874516
Change-Id: I3b9c7f9f5de757f818ec358c992ffb0e5f3e310f
René Ribaud
yatinkarel