Skip to content

Synchronise 2025.1 with upstream#180

Open
github-actions[bot] wants to merge 10 commits intostackhpc/2025.1from
upstream/2025.1-2026-03-30
Open

Synchronise 2025.1 with upstream#180
github-actions[bot] wants to merge 10 commits intostackhpc/2025.1from
upstream/2025.1-2026-03-30

Conversation

@github-actions
Copy link
Copy Markdown

This PR contains a snapshot of 2025.1 from upstream stable/2025.1.

melwitt and others added 10 commits June 7, 2025 01:45
The _create_ephemeral() method is responsible for creating ephemeral
disks with image type "raw" and formatting them with mkfs. In the case
of [libvirt]images_type "qcow2", _create_ephemeral() will create
backing files.

Currently we are not using a consistent naming convention for choosing
the filesystem label for ephemeral disks. When we create a server for
example, we go through the disks and label them "ephemeral0",
"ephemeral1", "ephemeral2", etc.

When we hard reboot a server, there is a check to create missing
backing files and if so, a new backing file will be created but instead
of being labeled "ephemeralN" the code attempts to label them with the
name of the backing file itself for example "ephemeral_1_40d1d2c". This
will fail if the filesystem used for ephemeral disks has limitations on
the length of filesystem label names (VFAT, XFS, ...). For example:

  mkfs.vfat: Label can be no longer than 11 characters

This adds a helper method for obtaining ephemeral disks filesystem
label names and uses it the same way in the few places fs_label is
specified.

Closes-Bug: #2061701

Change-Id: Id033a5760272e4fb06dee2342414b26aa16ffe24
(cherry picked from commit 82856f9)
This change fixes string format specifier from $ to % for
correct formatting.

Closes-Bug: #2123840
Signed-off-by: Rajesh Tailor <ratailor@redhat.com>
Change-Id: I04f6e1ba3eff443d40a13c6fe2d0b77a78a020e6
(cherry picked from commit ca158f2)
(cherry picked from commit b1da6b5)
This reproduces the bug where an attempt to revert a resize from a
flavor with vTPM to a different flavor with vTPM results in the revert
failing and the instance going into ERROR state when storage is not
shared.

Because of the lack of test coverage of vTPM with non-shared storage,
this change also just adds a subclass to run all of the vTPM functional
tests with the test environment mocked to behave as though storage is
not shared between compute hosts.

A bug fix will follow these functional tests.

Related-Bug: #2125030

Change-Id: I49745a8ba78e1ea6a1b009bccab32a002cb6afb0
Signed-off-by: melanie witt <melwittt@gmail.com>
(cherry picked from commit 650772d)
(cherry picked from commit b4d0692)
Currently, vTPM secrets are deleted from Barbican any time instance
disks are deleted when driver.destroy() is called. This is fine if the
instance is also being deleted but if it's not, such as during a resize
revert, it will fail with the following error:

  nova.exception.Invalid: Refusing to create an emulated TPM with no
    secret!

which will bubble up to the API as a HTTP 500.

This moves deletion of the vTPM secret from Barbican from the libvirt
driver destroy() path to the compute manager _delete_instance() path so
that the vTPM secret is deleted only if the instance is being deleted.

Closes-Bug: #2125030
Change-Id: I1a43dc0502e1e65b4ef0348610f5eddb43dbff02
Signed-off-by: melanie witt <melwittt@gmail.com>
(cherry picked from commit 787d2a1)
(cherry picked from commit a9bcf11)
Without this patch, due to power_on calling _hard_reboot, which in turn
undefines the VM to ensure a clean domain XML, the TPM data is erased by
libvirt.

This is very surprising to users who store persistent data in the TPM,
such as keys required to decrypt the main disk of the VM.

Conflicts:
      nova/virt/libvirt/driver.py

NOTE(nicolairuckel): The conflict is because change I33b8fc0136b4c1783b5c493e8ca9a15110767f6c (Implement sound model extra spec for libvirt.) is not in Epoxy.

Closes-Bug: #2118888

Signed-Off-By: jonas.schaefer@cloudandheat.com
Change-Id: Iefb879428681003d6db604b70353a91913c92461
(cherry picked from commit 2399a29)
(cherry picked from commit 687f2db)
@github-actions github-actions bot added the automated Automated action performed by GitHub Actions label Mar 30, 2026
@github-actions github-actions bot requested a review from a team as a code owner March 30, 2026 06:54
@priteau priteau closed this Mar 30, 2026
@priteau priteau reopened this Mar 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automated Automated action performed by GitHub Actions synchronisation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants