The /os-hypervisors/detail API endpoint was experiencing significant
performance issues in environments with many compute nodes when using
microversion 2.88 or higher, as it made sequential RPC calls to gather
uptime information from each compute node.
This change optimizes uptime retrieval by:
* Adding uptime to periodic resource updates sent by nova-compute to the
database, eliminating synchronous RPC calls during API requests
* Restricting RPC-based uptime retrieval to hypervisor types that support
it (libvirt and z/VM), avoiding unnecessary calls that would always fail
* Preferring cached database uptime data over RPC calls when available
Closes-Bug: #2122036
Assisted-By: Claude <noreply@anthropic.com>
Change-Id: I5723320f578192f7e0beead7d5df5d7e47d54d2b
Co-Authored-By: Sylvain Bauza <sbauza@redhat.com>
Signed-off-by: Sean Mooney <work@seanmooney.info>
This changes the PCI Placement translator edge case handling logic to
resolve a bug preventing VM deletion.
If a device is allocated but removed from the dev_spec then we need to
keep the device in Placement otherwise the Placement update will be
rejected as we are trying to delete an RP that has allocations. This
prevent the deletion of a VM that is using this removed device.
The alternative would be to not allow the nova-compute service to
start if it detects this situation. However this situation can
happen in at least two very different cases:
1. The admin removed a dev_spec. In this case adding the dev_spec back,
removing the VM, then removing the dev_spec is the right course of
action and nova-compute failing to start would be OK to enforce this.
2. A device disappeared as the HW is died. In this case not allowing the
nova-compute to start up would prevent the admin to migrate the
other VMs away from the host before doing a HW replacement.
Note that this is fairly complex change due to the fact that based on
purely the PciDevice object we cannot differentiate between the two
cases:
1. A PciDevice object is being removed as the related device spec is
removed from the configuration or the device is disappeared from
the hypervisor.
2. A PciDevice object was held back for a while as the device spec is
removed (or the device disappeared from the hypervisor) while the
device was allocated to a VM. And now that VM is undergoing deletion.
In both case the PCI in Placement logic sees a PciDevice object in
dev.status.REMOVED and dev.instance_uuid = None. However the two cases
require different handling.
1. The related inventory can be removed from Placement
2. The related inventory cannot be removed from Placement as it is still
being allocated to the VM that is undergoing deletion.
The second case is due to the sequence of events during a VM deletion
being:
* We destroy the VM on the hypervisor
* We update the PCI tracker to free the device. As the device was held back
the tracker not just frees the device but removes it as well as it is
not configured any more in the dev_spec so it should not go to
AVAILABLE state.
* When the PCI tracker is updated it calls the PCI in Placement logic
to update Placement inventories as well. At this point the VM deletion
still in progress and the VM's allocation hasn't been deleted in
Placement, so the Placement inventory cannot be removed as it is still
allocated.
* After the resource tracker update is finished the compute manager
deletes the VM's allocation in Placement.
So in this edge case we temporarily keep the Placement inventory and
only remove that in a subsequent periodic run where we are sure the
VM's allocation is gone. This means there is a time window when
the Placement inventory shows an extra resource even though that
resource has already been removed from the PCI tracker. During this
window the scheduler might select a host based on this ghost inventory
and the compute resource tracker will reject the boot request forcing
a normal re-schedule.
Closes-Bug: #2115905
Change-Id: Ie9d311ea9f59ff49593003e3773b690dd36fdeb2
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
The PCI tracker handles the case when a device spec is removed from
the configuration while a device is still being allocated. It keeps the
device until the VM is deleted to avoid inconsistencies.
However the full removal of such a device needs not just the VM deletion,
but also a nova-compute restart. The device tracker just frees the
device during VM deletion but does not removed them until the next
nova-compute startup. This allows the device to be re-allocated by
another VM even though the device is not allowed by a device_spec.
This change adds yet another in memory dict to the pci tracker to track
these devices that are only kept until they are freed. Then during
free() this list is consulted and if the device is in the list then the
device is marked for removal as well.
This kills two birds with one stone:
* We prevent the re-allocation of the device as the state of the device
will be set to REMOVED not AVAILABLE during VM deletion.
* As PCI in Placement relies on the state of the device to decide what
to track in placement, this change makes sure that a device that
needs to be removed, is now removed from placement too. Note that we have
another bug that prevents this removal for now. But at least the
reproducers of that bug now starts to behave the same regardless of
how many device belongs to the same RP in placement.
Related-Bug: #2115905
Change-Id: I63c8fb2669a3c6b3adb77d210c0f9b39d3657c80
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
Both the PCI tracker and the PCI in Placement logic handles the case
when a device spec is removed from the configuration while a device
is still being allocated.
However there are edge cases in PCI in Placement that it not handled
well. Namely that if the VM with this allocation is deleted, then
depending on the amount of VFs the PF had originally, the logic might
try to delete the RP before the allocation is removed. That is
rejected by Placement. This prevent the deletion of such a VM and
therefore prevents one of the ways the original inconsistency can be
Note that with this patch we see two additional behaviors worth
mentioning:
* When the VM is successfully deleted (in a single VF or PF case) the
PCI tracker still keeps the now free device in the DB and therefore PCI
in Placement also keeps the RP. This keeps the non whitelisted device
available for allocations until the next nova-compute restart.
* The PCI in Placement logic is different between the case where
the last device is removed from an RP and the case where there
are other devices on the RP, some that can be removed and some that
cannot due to allocation.
Related-Bug: #2115905
Change-Id: Ib3febb77299da65ada24ed49849c04cbf3c41af1
Signed-off-by: Balazs Gibizer <gibi@redhat.com>
This patch fixes an ambiguous regexp prevent using device_filename like
'mkwinimage-cdrom'.
The schema in Ib8857d9f725e277f27ccfab83335142b05e2cdf1 mistakenly
included r, which caused _-r to be interpreted as a range of items
from - to r.
The intent was to align the schema with what is allowed in
block_device.pyi -> validate_device_name()[1].
Since this brings the schema in line with existing validation logic, it
can be treated as a bug fix and does not require a microversion bump.
[1] https://github.com/openstack/nova/blob/73724fef9a66c4df3d018e7368067f883b1ed9e2/nova/block_device.py#L378
Closes-Bug: #2114951
Change-Id: Ie852e6dbd005ce46b41a486d3121d4d34d1fc1a2
Signed-off-by: René Ribaud <rribaud@redhat.com>
Ambiguous regexp prevent using device_filename like 'mkwinimage-cdrom'.
The regexp matches a single character in the range between _ (index 94)
and r (index 114) (case sensitive)
Related-Bug: #2114951
Change-Id: I5c7ce18eb635a75d5aadc889e730ed77c9a10dc3
Signed-off-by: René Ribaud <rribaud@redhat.com>
We agreed by I2dd906f34118da02783bb7755e0d6c2a2b88eb5d on the support
envelope.
Pre-RC1, we need to add a service version in the object.
Post-RC1, depending on whether it's SLURP or not SLURP, we need to bump
the minimum version or not.
This patch only focuses on pre-RC1 stage.
Given Gazpacho won't be skippable, we won't need a post-RC1 patch for updating the min
that will continue to support Epoxy.
HTH.
Signed-off-by: René Ribaud <rribaud@redhat.com>
Change-Id: I5bf6ad1077fe62e6ff628d211b745857167280fb
This change fixes duplicate consecutive words from docs
as well as code.
Signed-off-by: Rajesh Tailor <ratailor@redhat.com>
Change-Id: I236ff41fccf831023b6f85840097148a30e84743
As of now, if operator wants to set traits using 'nova-manage
image_property set' command, it fails with below error, because
in ImageMetaProps traits are not stored as individual fields, but
stored in 'traits_required' field which is of type list.
'Invalid image property name trait:CUSTOM_XYZ'
The setting of traits are handled by _set_attr_from_trait_names
method here [1].
This change handles the issue by continue the loop, if the
property startswith 'traits' string.
[1] https://opendev.org/openstack/nova/src/commit/725a307693806e6e32834198e23be75f771bebc1/nova/objects/image_meta.py#L708-L714
Closes-Bug: #2096341
Change-Id: Ifc20894801f723627726e3c9bed7076144542660
Signed-off-by: Rajesh Tailor <ratailor@redhat.com>
Ubuntu Jammy is no longer supported since 2025.2 . Replace it by
Ubuntu Noble which is used in the other jobs.
Change-Id: I790fb06ede2c41cb80b3d2e8ff7faa7315c84016
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
When VMCoreInfo device is enabled, the QEMU fw_cfg device in guest OS
requires DMA between host OS and guest OS through the device. However
DMA is prohibited when guest memory is encrypted using SEV, and
the attempt results in kernel crash.
Do not add VMCoreInfo when memory encryption is enabled.
Closes-Bug: #2117170
Change-Id: I05c7b1ae46ccd8d9aa42456b493ac6ee7ddd8bae
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
We also tackle the server security group and security group rules
controllers at the same time since they are so similar.
Change-Id: I7a039cdc172de59392215e9d6a9a24d03144cb85
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Address a few improvements we agreed to cover in follow-ups.
Also fix a few problems detected during the code update.
- Fix SEV-ES rp not purged when SEV and SEV-ES are disabled at
the same time. The previous logic requires 2 cycles which is
not necessary.
- Fix the lack of NOKS policy in SEV-ES.
Change-Id: I59866d39fcc6720e338c6736dffab4fd56b853da
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>
Sean Mooney