October 2025 - openstack-discuss - lists.openstack.org

[manila] PTG schedule + cross project sessions with Nova and Horizon
by Carlos Silva 23 Oct '25

23 Oct '25

Hello zorillas and interested stackers, I would like to share with you the schedule for next week's PTG [1] which is also the official PTG etherpad. In case you would like to request schedule changes, please let me know as soon as possible. We will also have two cross project sessions: Cross project with Horizon - Manila UI testing - Icehouse room, Tuesday, 15:00 UTC (to be confirmed) Coss project with Nova - All things VirtioFS - Grizzly room, Wednesday 17:00 UTC [1] https://etherpad.opendev.org/p/gazpacho-ptg-manila Looking forward to a productive PTG! Regards, carloss

1 0

[osa][kolla][openstack-helm][puppet] Cross-deployment-projects PTG session
by Michał Nasiadka 23 Oct '25

23 Oct '25

Hello, Me and Dmitriy (noonedeadpunk) have an idea of making a cross-deployment-projects PTG session - where we could discuss some common problems and topics. I’ve created an etherpad [1] for collaboration purposes. We’re reaching out to OpenStack-Helm and Puppet projects if they would be interested in joining and discussing things we could improve together in OpenStack ecosystem. Please also put possible timeslots from your side in the etherpad. [1]: https://etherpad.opendev.org/p/oct2025-ptg-cross-deploy Cheers, Michal

1 0

[nova] Persistent PXE boot for VMs
by Eugen Block 22 Oct '25

22 Oct '25

Good morning, we have the requirement to let a subset of VMs always boot in PXE mode. They're managed by a Uyuni server that controls whether a VM has to be (re)installed or if it should boot from local disk. I've been searching and testing, but to no avail yet, except for modifying the xml file which will not persist [0]. Is there a known history why this isn't possible (yet) or has this already been discussed and the decision was to not implement such a feature? We're thinking about implementing a solution for us, but would be also interested if a PR would have a chance to be accepted. If anyone has some insights/ideas/recommendations, I'd appreciate it. Thanks! Eugen [0] https://blog.dachary.org/2012/10/08/network-boot-an-openstack-instance/

4 13

[telemetry][TC] Stepping down from Telemetry PTL
by Matthias Runge 22 Oct '25

22 Oct '25

Hi there, due to other time commitments, I would need to step down from Telemetry PTL and proposed Juan Larriba -- the previous PTL -- to take over[1]. I won't be far, but I also believe the project is in better hands of a person who is nearer to the code these days. Matthias [1] https://review.opendev.org/c/openstack/governance/+/964516

2 1

[oslo][messaging] Container fix of QManager breaks it for containers
by Dmitriy Rabotyagov 22 Oct '25

22 Oct '25

Hey folks, I wanted to raise attention to a relatively old issue, which has had a patch around since January [1]. Basically a regression [2] was introduced and backported to 2024.1 as part of an attempt to fix QManager execution in containers. However, it does not account for the possibility of os.getpgrp() returning 0 in some edge cases, which makes, for instance, impossible to sync database for Nova during upgrades, if QManager is used. Thus I'm asking to kindly review the [1] as it appears to be a blocker for some upgrades involving affected versions of oslo.messaging. I have not spotted this patch right away, so I proposed an alternative [3], but I'm happy to abandon it in favor of [1]. Thanks in advance for upcoming reviews :) [1] https://review.opendev.org/c/openstack/oslo.messaging/+/939540 [2] https://review.opendev.org/c/openstack/oslo.messaging/+/928034 [3] https://review.opendev.org/c/openstack/oslo.messaging/+/958528

2 3

[nova] [nova-scheduler] Performance Issue with CPU Pinning Scheduling and Duplicate IPs
by İzzettin Erdem 22 Oct '25

22 Oct '25

Hi, In our environment (Kolla-Ansible Ussuri, 1200+ hypervisors), we are experiencing performance issues during bulk VM deployments. When launching around 100 VMs, the operation takes approximately *15 minutes*. During this time, the *nova-scheduler* spends over *15 minutes calculating available pinned CPUs*. However, in our Yoga production deployment, the same operation is about *10 times faster* — around *1–2 minutes* for 100 VMs. Additionally, after the 100 VMs are created, we have observed that some instances could not be created and some of the rest receive *multiple (2–3) IP addresses* from Neutron instead of one. Our nova services are running in a *NUMA-aware, CPU-pinning* configuration, and other settings are almost identical to the default configuration. Below is an excerpt from the nova-scheduler logs during VM creation (this message is repeated thousands of times within 15 minutes): Computed NUMA topology CPU pinning: usable pCPUs: [[26, 90], [89, 25], [24, 88], [27, 91], [29, 93], [10, 74], [86, 22], [28, 92], [73, 9], [23, 87], [8, 72], [18, 82], [94, 30], [81, 17], [31, 95]], vCPUs mapping: [(0, 26), (1, 90), (2, 89), (3, 25), (4, 24), (5, 88), (6, 27), (7, 91), (8, 29), (9, 93), (10, 10), (11, 74), (12, 86), (13, 22), (14, 28)] Do you have any suggestions on what might be causing: 1. The scheduler to spend so much time calculating pinned CPUs in Yoga, and 2. Some VMs to get multiple IPs from Neutron after creation? Any guidance would be greatly appreciated. Best regards, İzzettin

1 0

[kolla-ansible] [nova] Database connection points to nova cell db
by İzzettin Erdem 22 Oct '25

22 Oct '25

Hi, In Kolla-Ansible deployments, the connection parameter under the [database] section in the nova.conf template points to the *nova_cell* database [1] <https://opendev.org/openstack/kolla-ansible/src/commit/4e3208b16c452d1cf2cd…>. As far as I understand, the *nova_cell* database is primarily used to store failed operations. I was wondering: if we are not using a multi-cell architecture, should the connection instead point directly to the *nova* database rather than *nova_cell*? There was an open bug related to this issue almost a year ago, but it has not received any updates yet [2] <https://bugs.launchpad.net/kolla-ansible/+bug/2088264>. Could you please confirm whether the current configuration is correct? We have deployed OpenStack using the existing configuration and it is currently running in production. If we change the database connection in the running environment, would that cause any issues? Thank you for your time and assistance. Best regards, İzzettin

2 1

[publiccloud-sig] Public Cloud SIG meeting d.d. 22 October
by Kees Meijs | Nefos 21 Oct '25

21 Oct '25

Hello Stackers, For whom I've met at the summit: it was great to be there and meet you all! Tomorrow (that's 22 October) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 07:00 hrs UTC (09:00 hrs CEST) and on here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 1

[nova] Memory performance issue while using property "hw:numa_nodes='2'" in flavors
by brijesh.mishra＠five9.com 21 Oct '25

21 Oct '25

Hi Team We have use Kolla ansible for openstack Caracal 2024.1 deployment. Having 2 production sites, we have observer that the Nova scheduler is allocating virtual machines (VMs) only on a single NUMA socket of the compute host. Since the flavor does not include the property hw:numa_nodes='2', vCPUs spread on two NUMA nodes scheduling is not enabled. As a result, all vCPUs and memory for a VM are placed on a single NUMA node, while the other NUMA socket(s) remain underutilized. So we tested this property in our test flavor and found that now scheduler is able to spread vcpu/vm across two numa sockets but performance on memory side is degraded for about 20% to 30%. So we are looking for suggestions on this if there is better way to accommodate more VMs or spread vcpu on two numa socket without having performance issues on memory or cpu side, or something which have less impact? Regards Brijesh

2 1

[Caracal]Optimizing Nova NUMA Scheduling Behavior (Single vs Dual NUMA Socket Allocation)
by Vish Mudemela 21 Oct '25

21 Oct '25

Hi Team, We are using Kolla Ansible for our OpenStack Caracal (2024.1) deployment across two production sites. We have observed that the Nova scheduler is currently allocating virtual machines (VMs) only on a single NUMA socket of the compute host. Since our flavors do not include the property hw:numa_nodes='2', the scheduler places all vCPUs and memory for a VM on a single NUMA node, leaving the other NUMA socket(s) underutilized. In our testing, we added the hw:numa_nodes='2' property to the flavor and confirmed that the scheduler can now distribute vCPUs across both NUMA sockets. However, this configuration led to 20–30% memory performance degradation, likely due to cross-NUMA memory access. We also noticed that once this property is set, the scheduler always attempts to spread vCPUs across two NUMA sockets — even when there are sufficient resources available on a single NUMA node. We are looking for a way to achieve conditional NUMA placement — ideally: - If a single NUMA node has enough capacity, schedule the VM entirely on that node. - Otherwise, allow the scheduler to spread the VM across multiple NUMA nodes. We would appreciate any suggestions or best practices to: Improve NUMA-aware scheduling efficiency,Better utilize both NUMA sockets without significant memory performance penalties, andAvoid forcing cross-NUMA allocation unless necessary. Has anyone in the community implemented or tuned Nova in a way that balances these requirements effectively? Thanks in advance for your insights and recommendations. Thanks

2 1