Port latest bobcat patches - #651
Open
leust wants to merge 13 commits into
Open
Conversation
After KVM go-live, customers are already trying to resize their VMWare VMs to KVM VMs. This isn't supported yet, so customers end up with VMs in broken states. This detects and disallows cross-hv resizes. Co-authored-by: Jakob Karge <jakob.karge@sap.com> Co-authored-by: Fabian Koller <fabian.koller@sap.com> Change-Id: I85d7a20bc26e1911e5859783de94681f5618bdda (cherry picked from commit 0a070dc)
We introduced the setting [libvirt]/always_allocate_memory_immediately in I6fc6e7df9bcbd5e7b3e3e151d044dc25e88af4a5 but forgot to support it in live-migrations. This lead to live-migrated VMs not having the preallocated memory anymore and thus performance degradations. We now support transporting the destination host's setting to the source host via migrate data, so the source host can build the expected XML for the migration. Change-Id: I215cde9e36dac198185133d1b167bec77957d429 Fixup-for: I6fc6e7df9bcbd5e7b3e3e151d044dc25e88af4a5 (cherry picked from commit 26a5e39)
When querying ComputeNode objects for pagination in the API, we now filter in the DB for ComputeNodes having deleted services. The filter is also active later in the API's code, but filtering there breaks pagination. We thought about re-querying the DB when we encounter the filter in the API, but since we plan to optimize the hypervisor listing by reducing the queries anyways, going through the DB seemed the right choice. Change-Id: I0e8d0e270919d62c3767b6479477219ed089856b (cherry picked from commit 404354a)
We cannot increase or decrease the queues during live-migration and CH does not keep them automatically, but uses what Nova puts into libvirt. Therefore, we read the current queues for each interface and, if set, put them into the new VM's config. Change-Id: Ida83f7aaa544351d8688fe661d9eb3f239bb2580 (cherry picked from commit 45ef23c)
Problem Cross-HV resize sanitizes VMware image properties before scheduling, but revert needs the original values in both the RequestSpec and instance system_metadata. Solution Add the RequestSpec sanitizer and MigrationContext.old_image_properties journal. Preserve that journal when MoveClaim rebuilds the migration context, then use it to restore RequestSpec image properties and system_metadata image_* keys during revert. Introduce the field as MigrationContext VERSION 1.2.1 to avoid colliding with a future upstream 1.3. Change-Id: I56271a118ec3785eb5ba81a6f648e58d18169e73 (cherry picked from commit 2e27fff)
Allow VMware vCenter Server to CH resize for running BFV instances only. Add shared cross-hypervisor resize detection and API/conductor guardrails so unsupported directions are rejected before scheduling. The conductor sanitizes image properties and writes cross-HV system_metadata intent markers before dispatching resize work. Co-authored-by: Jakob Karge <jakob.karge@sap.com> Co-authored-by: Fabian Koller <github@kthxbye.cyou> Change-Id: I50dedca220e70f51811c0f9b9327ca3ae7ea9e12 (cherry picked from commit 28973f6)
Problem The VMware driver needs source-side shell handling for cross-HV BFV resize. The source VM must stay available as a recoverable shell so confirm and revert can complete safely. Solution Add cross-HV branches to migrate_disk_and_power_off, confirm_migration, and finish_revert_migration. The source VM is powered off, volumes and NICs are detached, instanceUuid is swapped to migration.uuid, and the shell is retained for confirm or revert. Use the shared supported-transition helper for detection, mark source preparation only after shell creation completes, and keep rollback UUID-aware when the VM has already been renamed to migration.uuid. Change-Id: I3db51a7dc0cb1dfc1592959d9823250a93fd3358 (cherry picked from commit 4af4b40)
Problem Cross-HV resize depends on every service in the resize path understanding the new MigrationContext journal and driver state. During rolling upgrades, activating the feature before all services are updated can cause RPC object backport timeouts. Solution Add [workarounds] enable_cross_hv_resize, defaulting to False, and reject cross-HV resize at the API/conductor validation boundary until operators explicitly enable it after rollout. Change-Id: I2ec2513dbad1caeea7e6d99368bd4789f1ecb388 (cherry picked from commit 0f38bc1)
Problem VMware reports volume BDM device names as sd*, while KVM/CH presents virtio disks as vd*. After cross-HV resize, BDMs and instance.root_device_name otherwise keep the VMware-era names, and Cinder receives stale mountpoints during attachment update. Solution When cross_hv_resize is set, translate BDM device_name values and instance.root_device_name from sd* to vd* in _finish_resize before _update_volume_attachments. Translate back from vd* to sd* in _finish_revert_resize before the same attachment update path. This keeps Cinder mountpoints synchronized without extra Cinder calls. Change-Id: I66742bfac43541cdafe8f43bde751394 (cherry picked from commit 8ebc484)
When optimizing listing hypervisors, we falsely changed a test instead of the code. Since then, showing hypervisors with servers is broken (raises an HTTP 500 out of a ValuError). Change-Id: I1481b4a1674bfdf3c741e7aa27876ad429e438fa Fixup-for: Ie4deaa84de1a6fb3006c46d36c82f49475b48d88 (cherry picked from commit 12df5bd)
…names After a VMware-to-CH resize, libvirt derives disk_bus=virtio from the translated device_name=/dev/vd* and persists it back to the BDM. On revert, _sanitize_cross_hv_bdms translated /dev/vd* back to /dev/sd* but left disk_bus=virtio in place. vmops._attach_volumes uses bdm.disk_bus as the adapter type when attaching FCD volumes; 'virtio' is not a valid VMware SCSI adapter type and caused InvalidDeviceSpec on the second attached volume. The fix adds a disk_bus argument to _sanitize_cross_hv_bdms. The original disk_bus per BDM is journaled in instance.system_metadata under cross_hv_orig_bdm_disk_bus_<volume_id> during the forward pass and restored on revert. None is stored as the sentinel '__NONE__' since system_metadata values are strings. The journal write is idempotent so retries do not overwrite the original. When no journal entry exists the fallback is None (correct for all current SAP-compliant images where BDM disk_bus is always None at VMware spawn). Journal keys share the cross_hv_ prefix and are cleaned up by the existing marker cleanup on confirm/revert. Both call sites are gated on cross_hv_resize == 'true', so same-HV resize/revert paths are not affected. Change-Id: If898b330c8fcf73cbde194f0064927edbd886db8 (cherry picked from commit 3be05cc)
When a non-BFV VMware instance is resized to a CH flavor (which has root_gb=0), the generic zero-disk flavor guard fires first, producing a misleading error: 'Resize to zero disk flavor is not allowed.' The expected error for this scenario is: 'Cross-hypervisor resize not allowed: Instance must be Boot-from-Volume (BFV)' Fix by moving the existing cross-hypervisor resize check ahead of the zero-disk guard so the more specific precondition error wins. The RequestSpec the check needs is fetched inside the cross-HV branch, leaving the existing guards (and the later fetch used for scheduling) untouched, so error ordering for non-cross-HV resizes is unchanged. Also improves customer-facing error messages: - Expand 'BFV' to 'Boot-from-Volume (BFV)' in precondition reason - Change 'precondition not met' to 'not allowed' in exception template Fixup-for: I50dedca220e70f51811c0f9b9327ca3ae7ea9e12 Change-Id: I41826646cff336595fe34ebeb2eb7c1d09d6792a (cherry picked from commit 27eb1f0)
The websocket proxy mutates the CONF host list with the Host header from the request, which would then poison future requests and/or lead to a slow resource exhaustion attack. Simply making a copy before mutation avoids the issue. Conflicts: nova/console/websocketproxy.py Generated-By: Claude Opus 4.6 Closes-Bug: #2158919 Change-Id: Ib13e479337f9b1c8b16952089d1d5f6979976b86 Signed-off-by: Dan Smith <dansmith@redhat.com> (cherry picked from commit 0612fed) (cherry picked from commit e488194) (cherry picked from commit 5fe20b9) (cherry picked from commit 9067376)
joker-at-work
approved these changes
Jul 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.