November 2025 - openstack-discuss

[nova] migration status update too long
by Nguyễn Hữu Khôi 28 Nov '25

28 Nov '25

Hello. I am working on instance migration. After I complete the migration, when I run *openstack server migration list* to check its status, it still shows as *running*. It takes around *12 minutes* before it updates to *completed * status. My OPS: 2025.1 Thank you. Nguyen Huu Khoi

3 12

[openstack-ansible][rabbitmq] Repository change from ppa1 to deb1 for Ubuntu/Debian
by Dmitriy Rabotyagov 28 Nov '25

28 Nov '25

Hi folks, Recently RabbitMQ has changed a repository URL for RabbitMQ and Erlang packages for Ubuntu and Debian. We were using ppa1.rabbitmq.com for all our stable branches, which used to work nicely until recently. With that being said, all existing users need to update their configuration, to use a new repository. For that: * Download GPG key to your deploy host (the one referenced on https://www.rabbitmq.com/docs/install-debian) curl -1sLf https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73… -o /etc/openstack_deploy/pki/rabbitmq.gpg * Create /etc/openstack_deploy/group_vars/rabbitmq_all.yml with content: rabbitmq_repo_url: https://deb1.rabbitmq.com/rabbitmq-server/{{ ansible_facts['distribution'] | lower }}/{{ ansible_facts['distribution_release'] | lower }} rabbitmq_erlang_repo_url: https://deb1.rabbitmq.com/rabbitmq-erlang/{{ ansible_facts['distribution'] | lower }}/{{ ansible_facts['distribution_release'] | lower }} rabbitmq_gpg_keys: - file: /etc/openstack_deploy/pki/rabbitmq.gpg This should fix all existing deployments, while we are proposing and backporting patches for all maintained branches. So a proper fix is expected with the next bugfix release.

2 2

[barbican] Review Request: Fix rewrap_pkek with SoftHSMv2 and CKM_AES_KEY_WRAP_PAD key wrap mechanism (I965443)
by Kaoru Watanabe 27 Nov '25

27 Nov '25

Hi OpenStack Barbican Community, This is my first time submitting a patch to OpenStack, and I am sending this email to kindly request a review. I have great respect for the work you all do in this community. I submitted a patch to address a critical issue we found. This issue occurs when performing key rewrap (barbican-manage hsm rewrap_pkek) using SoftHSMv2 and the CKM_AES_KEY_WRAP_PAD key wrap mechanism. This specific configuration is essential for our production environment, making this fix highly critical for us. We would be grateful if this patch could be merged. Here are the details: Bug Report: https://bugs.launchpad.net/barbican/+bug/2130214 Gerrit Change: https://review.opendev.org/c/openstack/barbican/+/965443 (I965443) The change has been posted for almost a month now. Could you please take a moment to review change I965443? Your feedback is greatly appreciated as we look to move this forward. Thank you very much for your time and collaboration. Best regards, kaoru

1 0

[barbican] Review Request: Fix rewrap_pkek with SoftHSMv2 and CKM_AES_KEY_WRAP_PAD key wrap mechanism (I965443)
by kaoru watanabe 27 Nov '25

27 Nov '25

Hi Openstack Barbican Community, This is my first time submitting a patch to OpenStack, and I am sending this email to kindly request a review. I have great respect for the work you all do in this community. I submitted a patch to address a critical issue we found when performing key rewrap (barbican-manage hsm rewrap_pkek) using SoftHSMv2 and the CKM_AES_KEY_WRAP_PAD key wrap mechanism. Bug Report: https://bugs.launchpad.net/barbican/+bug/2130214 Gerrit Change: https://review.opendev.org/c/openstack/barbican/+/965443 (I965443) This specific configuration (SoftHSMv2 with CKM_AES_KEY_WRAP_PAD) is essential for our production environment, making this fix highly critical for us. We would be grateful if this patch could be merged. The change has been posted for almost a month now. Could you please take a moment to review change I965443? Your feedback is greatly appreciated as we look to move this forward. Thank you very much for your time and collaboration. Best regards, kaoru

1 0

Arbitrary qemu args in nova-compute
by Nathan Harper 27 Nov '25

27 Nov '25

Prompted by Sean’s comment on a different thread: * nova has a policy of not allowign any use of raw qemu args I’ve seen this come up a number of times, but I don’t recall seeing the justification for this policy. We are looking at a scenario where we (as an operator) want to add some specific additional qemu flags to some VMs, but we’re now having to run a local Nova patch to achieve this (experiments with libvirt-hooks haven’t proven fruitful. I can see why we wouldn’t want users to add arbitrary flags, but an unsupported YMMV option in Nova would be helpful -- Regards, Nathan Harper Principal Engineer – Cloud Development Platform Engineering nathanh(a)graphcore.ai<mailto:nathanh@graphcore.ai> www.graphcore.ai →<http://www.graphcore.ai/> ** We have updated our privacy policy, which contains important information about how we collect and process your personal data. To read the policy, please click here<http://www.graphcore.ai/privacy> ** This email and its attachments are intended solely for the addressed recipients and may contain confidential or legally privileged information. If you are not the intended recipient you must not copy, distribute or disseminate this email in any way; to do so may be unlawful. Any personal data/special category personal data herein are processed in accordance with UK data protection legislation. All associated feasible security measures are in place. Further details are available from the Privacy Notice on the website and/or from the Company. Graphcore Limited (registered in England and Wales with registration number 10185006) is registered at, 1 Maple Road, Bramhall, Stockport, Cheshire, UK, SK7 2DH. This message was scanned for viruses upon transmission. However Graphcore accepts no liability for any such transmission.

2 2

[nova][keystone] Machine identities
by Ricardo Cano 27 Nov '25

27 Nov '25

Hey guys, I was wondering if openstack had an equivalent to Azure's managed identities or AWS's IAM roles for ec2 to give vm's the ability to interact with the api. Are there any existing patterns that people are using for this? Thanks!

5 4

Q35 UEFI machine cannot fully load pci device "cannot find enough free resources (Code 12)”
by Joel McLean 27 Nov '25

27 Nov '25

G'day OpenStackers. I've got a fun one for the nova gurus among us. It could be that there exists documentation that answers this specific problem, but I am yet to come across it. Recently we've been playing around with GPU PCI Passthrough, using a couple of SMX4 NVIDIA A100s. We don't intend on slicing these up with MIG as they're small cards, and so have just been trying to get passthrough working. Following the documentation [0] , we've got it working in Ubuntu VMs after some troubleshooting, which I will share below in case it helps anyone else; we ran into problems with the default QEMU q35 hole size, and worked around the problem by modifying the grub config. However, we're not yet able to make it work with Windows. For reference, this is on a Caracal 2024.1 deployment of OpenStack. Essentially for the ubuntu 24 VM the description of the problem was: # Problem - on Ubuntu ## Replication Steps: 1. Create new instance from image with properties "hw_machine_type=q35" and "hw_firmware_type=uefi", and OS as Ubuntu 24, using flavor with a100-40g attached 2. Log into instance and install nvidia-drivers-580 ## Bug conditions: lspci shows that gpu is present drivers are able to be installed nvidia-smi command fails with error message unable to connect to drivers dmesg | grep pci - shows error message for pci device: [ 1.180865] pci 0000:05:00.0: BAR 0 [mem 0xff000000-0xffffffff]: can't claim; no compatible bridge window [ 1.182544] pci 0000:05:00.0: BAR 1 [mem 0xfffffff000000000-0xffffffffffffffff 64bit pref]: can't claim; no compatible bridge window [ 1.184541] pci 0000:05:00.0: BAR 3 [mem 0xfffffffffe000000-0xffffffffffffffff 64bit pref]: can't claim; no compatible bridge window [ 1.416571] pci 0000:05:00.0: BAR 1 [mem size 0x1000000000 64bit pref]: can't assign; no space [ 1.418209] pci 0000:05:00.0: BAR 1 [mem 0xfffffff000000000-0xffffffffffffffff 64bit pref]: failed to assign [ 1.420057] pci 0000:05:00.0: BAR 3 [mem size 0x02000000 64bit pref]: can't assign; no space [ 1.423133] pci 0000:05:00.0: BAR 3 [mem 0xfffffffffe000000-0xffffffffffffffff 64bit pref]: failed to assign [ 1.424987] pci 0000:05:00.0: BAR 0 [mem 0x80000000-0x80ffffff]: assigned [ 1.545824] pci_bus 0000:00: Some PCI device resources are unassigned, try booting with pci=realloc lspci -v shows memory BAR0 as disabled, does not show BAR1 or BAR3 at all: root@test-gpu-2:~# lspci -v -s 05:00.0 05:00.0 3D controller: NVIDIA Corporation GA100 [A100 SXM4 40GB] (rev a1) Subsystem: NVIDIA Corporation GA100 [A100 SXM4 40GB] Physical Slot: 0-4 Flags: fast devsel, IRQ 255 Memory at 80000000 (32-bit, non-prefetchable) [disabled] [size=16M] ## Solution: Modify and append the grub configuration with: GRUB_CMDLINE_LINUX="pci=realloc pci=nocrs" Then save and update-grub, and reboot. The nvidia-smi command now works, all 3 memory BARs show up, everything works, no more error messages. This means we're able to have GPU-capable linux images by having this modification baked into the image, or if appropriate, the cloudinit. # Problem - but on Windows However, on Windows (tested on server 2022 and server 2025), we run into the same problem : Windows seemingly cannot allocate enough memory to properly load the device; it appears in device manager, appears to be recognised, but stalls indefinitely during driver installation. Microsoft's available logging isn't as nice or as usable as Ubuntu, but the vibe of the logs is the same: Windows throws an error “This device cannot find enough free resources (Code 12)”. ## Possible Solutions We found that we could pass qemu arguments to the VM that would resolve the issue, but this is not viable in OpenStack as we can't pass the qemu arguments from the flavor or image meta-data. This solution gets thrown around on PVE forums or lxc/libvirt only areas, as it's not really openstack/nova friendly. The arguments (where VMID is the ID of the instance) to make it work were: qm set {VMID} -args '-global q35-pcihost.pci-hole64-size=256G' (run on the nova_libvirt container that controls the instance) As a note, I just could not find any documentation specifically (e.g. on qemu.org's documentation portal) that talks about q35-pcihost features, or specifically how pci-hole64-size interacts with the system. As you can imagine, setting arguments directly in the libvirt container isn't viable, as making modifications to libvirt outside of nova is against the whole cloud-native idea of Nova. It's just not meant to work that way. Alternatively, we've been able to get it working on an i440fx BIOS, as opposed to a q35 in UEFI, but that doesn't really feel like the right way to approach this problem. Any ideas on a good, cloud-native way to either modify our nova.conf, create a flavor, or update an image/image metadata so that a modern q35/UEFI machine running Windows can load the device properly? Thanks in advance. [0] ( https://docs.openstack.org/nova/latest/admin/pci-passthrough.html ) Kind Regards, Joel McLean Cyber Security and Product Development Manager Australia’s First Tier IV Data Centre https://www.micron21.com/ 1300 769 972 03 9751 7618 0407 888 429 joel.mclean(a)micron21.com Follow us on Twitter and https://m21status.com for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

2 1

[tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)
by Artem Goncharov 26 Nov '25

26 Nov '25

Hey, I took a stab for the first actions, which I added to the wiki page [1] by dropping the dependencies which are clearly not used or not necessary today. For that I proposed removing passlib [2], scrypt [3], and python-gnupg [4] from requirements completely. I do not know whether we have a proper mechanism of forbidding certain libs from being used to protect us from somebody accidentally re-starting using them (denylist is in the requirements, but I am not sure it was created for such purpose). ## Passlib it is abandoned. It was used in Keystone, but we got rid of it a few releases ago. Now there are few projects that install passlib (Kolla, OpenStack-Ansible, etc) but not themselves needing it. Those show drop it as well, but maintainers should be aware by now already ## scrypt Keystone was the only project using it. In the context of passlib replacement corresponding functionality was used from the cryptography library. Standalone use of scrypt should not be necessary ## python-gnupg Codesearch does not show any project using that. Regards, Artem [1] https://wiki.openstack.org/wiki/Post_quantum_openstack#Action_points [2] https://review.opendev.org/c/openstack/requirements/+/968443 [3] https://review.opendev.org/c/openstack/requirements/+/968444 [4] https://review.opendev.org/c/openstack/requirements/+/968445

1 0

[neutron] Drivers meeting canceled Friday, November 28th
by Brian Haley 25 Nov '25

25 Nov '25

Hello Neutrinos: I am going to cancel Friday's Drivers meeting as I will be out the rest of the week. Just a reminder that our open spec list at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[ironic] Team meeting cancelled for December 22nd and 29th
by Julia Kreger 25 Nov '25

25 Nov '25

Greetings Ironic community members! During our weekly meeting on November 24th[0], I raised the question if we should skip our weekly meeting on December 22nd and 29th due to the end of year. We reached consensus to go ahead and cancel those meetings as we expect the bulk of contributors to be taking time off during those weeks. As a result, the last formal Ironic team meeting of 2025 will be on December 15th, and the weekly meeting shall resume on January 5th, 2026. Thanks, -Julia [0] https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-11-24-15.02.l…

1 0