Introduce the new Host.supports_mem_encryption which tells whether
the host supports memory encryption. This allows us to centralize
and generalize the check logic for additional mechanisms such as
Arm CCA, planned to be added in the future.
Implements: blueprint generalize-sev-code
Change-Id: If020c71bd4962c6ca96e042592854e57d9a7dcce
Signed-off-by: Taketani Ryo <taketani.ryo@fujitsu.com>
Without this, we won't notice errors raised in the operation thread.
Before 1cd1c472bd the unit test actually
forced such errors to be raised even if in the real code it would
never be raised. But that patch fixed the unit test fixture to be more
realistic without realizing that such fixture error also means that we
might have wrong assumptions about the code under test.
Now we know that exception from the live migration thread was
never raised back to the monitor thread. To improve logging we added a
future.result() call after the main monitoring code finished.
Also the code had complex way to signal the monitoring thread that the
migration thread returned early by registering a callback on the
migration thread and setting an event. This can be simplified to just
check the status of the future of the migration thread. So the event and
the callback is removed.
All this was found because commit 25fbf32f22
missed to add the new parallel arg to the mock of guest.migrate()
on master, but the exception was never propagated to the unit test on
master. Backporting that change showed that in the old unit test env
there is a valid exception.
Co-authored-by: Dan Smith <dms@danplanet.com>
Change-Id: I22683ad5118796c6406f80d8726053afa84fff56
Signed-off-by: Dan Smith <dansmith@redhat.com>
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
This was missed in commit 25fbf32f22
because of a bug in our _live_migration_operation() post-eventlet
handling.
Change-Id: I39a7d6ebd72d9938bcb60143dfc50bd6a9c994b0
Signed-off-by: Dan Smith <dansmith@redhat.com>
This has not been supported for some time.
Change-Id: Ic7073740deb0bf9670eebe77f0f8b0daca100a5c
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Make sure that the consistent program name is always set,so that
the same config sub-directory ( /etc/{project}/{prog}.conf.d ) is used
regardless of the way api service is run.
Closes-Bug: #2098514
Change-Id: Ib5c6d431176b83eefafddc1b35589015db6dfd04
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
When running in eventlet mode we keep the original eventlet.tpool usage
but when running in threading mode we call the functions directly on the
thread of the caller.
The original tpool_execute() call made the upload call running in a
native tread as it has parts that are blocking and therefore running
them in the current greenthread would make the other greenthreads
starved.
After this patch we preserve the same effect but with different syntax.
We use tpool_wrap to wrap the function into a tpool.Proxy object and
then call the proxy object. That proxy ensures that any call on the
proxy object is run in a native thread.
This change is useful for us in native threaded mode. There the
tpool_wrap returns the function unchanged. So upload is executed in the
caller's native thread. This is OK as in native threaded mode any
concurrent tasks are also in native threads and native threads are
preempted when needed. So other tasks will not be starved.
Change-Id: Iddb8b317b7a883c6fd144a93aca862a792fcd1af
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
When running in eventlet mode we keep the original eventlet.tpool usage
but when running in threading mode we call the functions directly on the
thread of the caller.
Change-Id: I779374814a8ed8b2146bea226afe1250dea63079
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
When running in eventlet mode we keep the original eventlet.tpool usage
but when running in threading mode we call the functions directly on the
thread of the caller.
The patch_tpool_proxy() logic is removed from the libvirt driver as it
was only needed for python old style classes which is not in use any
more in python3 and the issue is not reproducible any more with
virConnect even without the patching.
❯ python3
Python 3.12.10 (main, Apr 9 2025, 04:44:59) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import eventlet
>>> eventlet.monkey_patch()
>>> from nova.virt.libvirt import host
>>> h = host.Host(uri="qemu:///system")
>>> h.get_connection()
libvirt: error : internal error: could not initialize domain event timer
URI qemu:///system does not support events: internal error: could not initialize domain event timer
<libvirt.virConnect object at 0x7f829e94c170>
>>> c = h.get_connection()
>>> str(c)
'<libvirt.virConnect object at 0x7f829e94c170>'
>>>
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Change-Id: Ic60ab78cec2a9f9ba177568b69e738425e56cae1
When running in eventlet mode we keep the original eventlet.tpool usage
but when running in threading mode we call the functions directly on the
thread of the caller.
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Change-Id: I08f257d49c87d0d8a87127f61157b1b0b5ca7b3c
States were added to the Ironic API to enable the node servicing
feature, which can be performed on nodes provisioned with Nova
instances. Current nova, if asked to delete these instances, will only
remove the instance metadata and not tear them down.
This change has two parts:
- I have added the new, relevant states to _UNPROVISION_STATES in
driver.py, which now allows Nova to know that SERVIC* states and
DEPLOYHOLD are safe to unprovision from.
- I have added all existing ironic states to ironic_states.py and the
PROVISION_STATE_LIST constant and check the state against it -- in a
case where a completely unknown state is returned, we should attempt
an unprovision.
This fix needs to be backported as far as possible, as this bug has
existed since Antelope / 2023.1 (DEPLOYHOLD) or Bobcat / 2023.3
(SERVIC*).
Assisted-by: Claude Code
Closes-bug: #2131960
Change-Id: I31c70d35b0e6e9f8d2252bfb2f0bdec477cc6cc7
Signed-off-by: Jay Faulkner <jay@jvf.cc>
With the NFS, FC, and iSCSI Cinder volume backends, Nova explicitly
sets AIO mode ``io=native`` in the Libvirt guest XML. Operators may set
this option to True in order to defer AIO mode selection to QEMU if
forcing ``io=native`` is not desired.
Closes-Bug: #2129788
Change-Id: I6e51706b5cb8be5becebbafe9108df1ba9e0f69f
Signed-off-by: melanie witt <melwittt@gmail.com>
The change Ife39b55eb40c9cb8e61f1b2295b6d42cefe3a680 migrated mypy
configuration files from setup.cfg to pyproject.toml file, but a
comment in .pre-commit-config.yaml says to keep is in sync with
setup.cfg, which is incorrect.
This change updates comment in the .pre-commit-config.yaml file to
reflect the change.
Signed-off-by: Rajesh Tailor <ratailor@redhat.com>
Change-Id: I4d35b989e8c90b629bcb15438ad82f60f7ca8957
Start supporting booting instances with the `host` TPM secret
security. This means setting the `ephemeral` and `private` attributes
on the Libvirt secret correctly, and not undefining the secret once
the instance has spawned. The Libvirt fixture's Secret support is
extended to be able to test all that in a functional test.
For functional testing, we need to:
* Extend our libvirt fixture's Secret object to properly set the usage
id (which is just the instance UUID) when parsing vTPM secret XML.
Related to blueprint vtpm-live-migration
Change-Id: I5a38a0de76a78b28a205a8d19f2374830054e1ab
Signed-off-by: melanie witt <melwittt@gmail.com>
The `user` secret security policy is just existing behavior. No
changes are necessary in the mechanics, so this patch just adds a
scheduler prefilter and tests. The functional tests add some
groundwork to make future tests easier as well by making the helper
methods more flexible.
For functional testing, we need to:
* Have our libvirt fixture keep track of undefined secrets. Secrets
are undefined as soon as the VM that uses them successfully boots
(as mentioned previously, VM creation follows this pattern), but our
tests would still like to assert that the secret had been created on
a host. Just add a _removed_secrets dict that _remove_secret()
populates.
Related to blueprint vtpm-live-migration
Change-Id: Ib449dc2f1c4a9af9d423252594261947e811452e
Signed-off-by: melanie witt <melwittt@gmail.com>
Key manager service secret ownership can be a challenge when dealing
vTPM instances. Some instance actions require access to the secret and
will fail if there is a mismatch.
In preparation for vTPM live migration changes which will involve
different users accessing secrets (user|admin|Nova service user), this
removes ADMIN_ONLY from the functional tests class and adds checking of
RequestContext user_id in the FakeKeyManager.
Change-Id: I2790cd274a4776ab306b39df1e591e8304b63f96
Signed-off-by: melanie witt <melwittt@gmail.com>
If a host has multiple instance with the same shared
multi attach volume and you delete them in parallel
nova need to correctly clean up the volume connection on
the host when the last instance is removed.
currently we do not have a volume level lock to guard the
critical section that determins if the current disconnect is
removing the final usage of the volume.
This can lead to leaking the volume or other issues as
noted in bug: #2048837
This change introduces a FairLockGuard to ensure we acquire
and release the locks in a fair and orderd manner.
The FairLockGuard is used to lock the server delete with
one lock per multi attach volume.
This will ensure that disconnects of diffrent volumes can happen
in parallel but if we are disconnecting the same volume in multiple
greenthread concurrently they will be serialised.
Assisted-By: Cursor Auto
Closes-Bug: #2048837
Change-Id: I67e10cace451259127a5d7da8fbdf7739afe3e51
Signed-off-by: Sean Mooney <work@seanmooney.info>
Taketani Ryo