- openstack-discuss - lists.openstack.org

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

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-18)
by Goutham Pacha Ravi 24 Nov '25

24 Nov '25

Hello Stackers, We're eighteen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Next Thursday is the deadline for project deliverables following the "trailing" [2] release model to ship their final releases for the OpenStack 2025.2 "Flamingo" release. This includes packaging, deployment, configuration, and lifecycle tooling projects that have bundled the goodness of the past release in a consumable way. The rest of the OpenStack project teams are in the thick of the Gazpacho roadmaps they've drawn for themselves. Now is a good time to ensure that any project-specific deadlines are added to the community's release calendar [1], like the Nova and Manila project teams have done. In the past week, the OpenStack Technical Committee did not make any major governance updates. We continued work on bringing the Special Interest Groups under the "openstack/governance" repository so we can provide them with the increased focus, visibility, and oversight that they currently lack. We also made significant progress on the retirement of the Monasca project deliverables; we hope to conclude it soon. === Weekly Meeting === The TC met on OFTC's #openstack-tc channel on November 18, 2025 [3]. This was the second occurrence of our monthly meeting at an APAC-friendly time. We do hope to energize the community into focused discussions in this new, periodic slot. Bear with us while we get past our teething troubles here. The meeting focused on moving several stale volunteer-needed items, such as analyzing the user survey results and reworking FIPS requirements, to the TC tracker due to a lack of current interest or traction. We discussed the Zuul errors on the cleanup patches concerning the Monasca project. We noted that it was past time to get this done, especially since some potential users claimed that their use case was at least a year out. Retiring a project within OpenStack is not the end of the road for the project. Volunteers are welcome to fork the project and continue its development outside OpenStack's governance. We do hope that Monasca continues to be developed outside the aegis of OpenStack's governance, and can return someday when there is interest to drive it within this community. The TC also discussed the proposed oslo.wsgi library and deemed it a good idea and will welcome any governance patches. The health of the gate looks good, with recent Gerrit and Gitea updates proceeding smoothly. The discovery of a new Zuul feature allowing the scheduler to be paused during Gerrit unavailability was identified as a time-saver. The next meeting of the OpenStack Technical Committee is on Tuesday, November 25, 2025, at 1700 UTC. The meeting will be hosted on OFTC's #openstack-tc channel. Please find the agenda on the meeting's wiki page [4]. I hope you'll be able to join us. === Governance Proposals === ==== Open For Review ==== * Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 * [resolution] Retire governance-sigs repository | https://review.opendev.org/c/openstack/governance/+/966645 * Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 * 2025-11-17 Retirement and Handover of the os-net-config Project | https://review.opendev.org/c/openstack/governance/+/967463 === Upcoming Events === * 2025-12-04: 2025.2 release deadline for "cycle-trailing" projects * 2025-12-09: OpenInfra Board meeting: https://board.openinfra.org/ * 2026-01-08: 2026.1 Milestone 2 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenStack release models: https://releases.openstack.org/reference/release_models.html [3] TC Meeting IRC Log, Nov 18, 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-18-17.01.html [4] TC Meeting Agenda, Nov 25 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 1

[qa] devstack & hacking core member updates
by Ghanshyam Maan 24 Nov '25

24 Nov '25

Hello everyone, I would like to propose the following updates to the devstack and hacking project core member list: Devstack: - Adding gibi in devstack core. He has been fixing and helping in devstack for a long time. Hacking: - Adding stephenfin and sean-k-mooney in the hacking core members list. Both have a good understanding of hacking projects and helping there on a need basis. - Frickler and I are part of the hacking core, but via included groups. I will be moving both to the core member list explicitly. Feel free to provide your feedback. If there are no objections by this Friday (21st Nov), I will update the gerrit group. -gmaan

2 2

[tc][horizon]Request for guidance on improving Python PTI doc to include pytest for Horizon plugins testing
by Chandan Kumar 24 Nov '25

24 Nov '25

Hello TC, We are writing to seek your guidance regarding the Python testing standards (PTI) as they relate to Horizon plugins. The current integration tests of the watcher-dashboard project (the Horizon plugin for OpenStack Watcher) are broken due to integration code changes in the Horizon integration suite. We are currently working on rewriting the watcher-dashboard integration tests. We noted that the Horizon project itself has developed a robust set of reusable, pytest-based integration tests, fixtures, tox targets and zuul job[1]. We also see that other plugins, like manila-ui, are already reusing these pytest fixtures.[2]. Several other projects within the OpenStack ecosystem (such as skyline-apiserver, rally, and projects under the Airship and StarlingX namespaces) are already using pytest. This presents a conflict for the Watcher team. The official Python PTI states that tests should be written using the Python stdlib unittest module[3]. The Watcher team advocates for adhering to the Python PTI and using unittest. Our main watcher project uses unittest, and we prefer to maintain this standard for consistency and PTI compliance in watcher-dashboard. This topic came up during watcher PTG discussion[4]. This leaves us with a dilemma: - Follow the Python PTI: This aligns with the PTI and our team's standards but requires us to ignore Horizon's reusable pytest tests and build our own testing framework from scratch, duplicating effort. - Follow the parent project (Horizon) to use pytest to reuse their fixtures. This would be more efficient but appears to violate the Python PTI and creates inconsistency with our main project. - Do we want to improve Python PTI documentation to include pytest usage? We just need guidance on this topic. Links: [1]. https://github.com/openstack/horizon/tree/master/openstack_dashboard/test/s… [2]. https://github.com/openstack/manila-ui/tree/master/manila_ui/tests/selenium [3]. https://github.com/openstack/governance/blob/master/reference/pti/python.rs… [4]. https://etherpad.opendev.org/p/watcher-2026.1-ptg#L404 With Regards, Chandan Kumar

10 22

[kolla] Cancelling weekly meeting on 26th Nov 2025
by Michał Nasiadka 24 Nov '25

24 Nov '25

Hello Koalas, We need to cancel the weekly meeting this week due to unavailability of key participants (including me). See you on the meeting 3rd of Dec. Cheers, Michal

1 0