- openstack-discuss - lists.openstack.org

[Zed][Neutron][OVN] Severe VM Network Performance Degradation Compared to Host
by Jeff Yang 05 Aug '25

05 Aug '25

Hi all, I'm running OpenStack Zed with OVN as the Neutron backend. I've encountered a severe VM network performance degradation issue and would appreciate any insights from the community. 🔹 **Environment** - OpenStack version: Zed - Neutron backend: OVN - Two VMs (each 4 vCPUs, 8 GB RAM) launched on two different compute nodes - Multi-queue is enabled on the VM vNICs 🔹 **Issue** The network performance inside the VMs is significantly worse than on the host nodes, with high packet retransmissions observed. 🔹 **Test results** **Host-to-Host (VTEP IPs)** ``` $ iperf3 -c 192.168.152.152 Connecting to host 192.168.152.152, port 5201 [ 5] local 192.168.152.153 port 45352 connected to 192.168.152.152 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.38 GBytes 11.8 Gbits/sec 0 3.10 MBytes [ 5] 1.00-2.00 sec 1.37 GBytes 11.8 Gbits/sec 0 3.10 MBytes [ 5] 2.00-3.00 sec 1.42 GBytes 12.2 Gbits/sec 0 3.10 MBytes [ 5] 3.00-4.00 sec 1.39 GBytes 11.9 Gbits/sec 0 3.10 MBytes [ 5] 4.00-5.00 sec 1.38 GBytes 11.8 Gbits/sec 0 3.10 MBytes [ 5] 5.00-6.00 sec 1.43 GBytes 12.3 Gbits/sec 0 3.10 MBytes [ 5] 6.00-7.00 sec 1.41 GBytes 12.1 Gbits/sec 0 3.10 MBytes [ 5] 7.00-8.00 sec 1.41 GBytes 12.1 Gbits/sec 0 3.10 MBytes [ 5] 8.00-9.00 sec 1.41 GBytes 12.1 Gbits/sec 0 3.10 MBytes [ 5] 9.00-10.00 sec 1.42 GBytes 12.2 Gbits/sec 0 3.10 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 14.0 GBytes 12.0 Gbits/sec 0 sender [ 5] 0.00-10.04 sec 14.0 GBytes 12.0 Gbits/sec receiver iperf Done. ``` **VM-to-VM (through overlay network)** ``` $ iperf3 -c 10.0.6.10 Connecting to host 10.0.6.10, port 5201 [ 5] local 10.0.6.37 port 56710 connected to 10.0.6.10 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 499 MBytes 4.19 Gbits/sec 263 463 KBytes [ 5] 1.00-2.00 sec 483 MBytes 4.05 Gbits/sec 467 367 KBytes [ 5] 2.00-3.00 sec 482 MBytes 4.05 Gbits/sec 491 386 KBytes [ 5] 3.00-4.00 sec 483 MBytes 4.05 Gbits/sec 661 381 KBytes [ 5] 4.00-5.00 sec 472 MBytes 3.95 Gbits/sec 430 391 KBytes [ 5] 5.00-6.00 sec 480 MBytes 4.03 Gbits/sec 474 350 KBytes [ 5] 6.00-7.00 sec 510 MBytes 4.28 Gbits/sec 567 474 KBytes [ 5] 7.00-8.00 sec 521 MBytes 4.37 Gbits/sec 565 387 KBytes [ 5] 8.00-9.00 sec 509 MBytes 4.27 Gbits/sec 632 483 KBytes [ 5] 9.00-10.00 sec 514 MBytes 4.30 Gbits/sec 555 495 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 4.84 GBytes 4.15 Gbits/sec 5105 sender [ 5] 0.00-10.05 sec 4.84 GBytes 4.14 Gbits/sec receiver iperf Done. ``` As you can see, there's a sharp drop in performance inside the VMs (from ~12 Gbps down to ~4 Gbps), with a lot of retransmissions in 10 seconds. Has anyone encountered a similar issue with OVN and VM networking performance? What could be the potential causes? Any suggestions or debugging tips are welcome. Thanks in advance! Best regards,

5 4

[openstack-ansible] Linux bridge support
by Rambo Rambo 05 Aug '25

05 Aug '25

Hi Team We are currently having openstack-ansible Antelope (2023.1) release and have linux bridge currently. We are planning SLUP upgrades from Antelope to Caracal, and than from Caracal to Epoxy. Please confirm if we can still use linux bridge and continue with the upgrades or we need to mandatory move away from linux bridge as linux bridge is now experimental feature before doing the upgrades. We are planning to move away from linux bridge after upgrading to Epoxy release. Please let me know potential issues that can arise with this plan. Regards Rambo

3 2

[neutron] Bug Deputy Report July 28 - Aug 03
by Yatin Karel 05 Aug '25

05 Aug '25

Hi Neutrinos, Below is the bug deputy report for last week:- High ==== - https://bugs.launchpad.net/neutron/+bug/2119097 - [OVN] The OVN agent "metadata" extension is registering the OVN Metadata agent tags Assigned to Rodolfo Alonso - Fix Released - https://bugs.launchpad.net/neutron/+bug/2119092 - [OVN] The ``SbGlobalUpdateEvent`` event in the OVN agent should implement LP#1991817 Assigned to Rodolfo Alonso - Fix Released - https://bugs.launchpad.net/neutron/+bug/2119453 - [FT][master] test_ovs_and_ovs_events fails randomly Unassigned Medium ====== https://bugs.launchpad.net/neutron/+bug/2119093 - [OVN] The ``OVNExtensionEvent`` class is hardcoded to work only with the "metadata" extension Assigned to Rodolfo Alonso - Fix Released Invalid ===== https://bugs.launchpad.net/neutron/+bug/2119294 - [Caracal][DNSaaS] - dns_domain is empty in port show Was related to mis configurations -- Thanks and Regards Yatin Karel

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-8)
by Goutham Pacha Ravi 05 Aug '25

05 Aug '25

Hello Stackers, We're eight weeks away from wrapping up the 2025.2 "Flamingo" release, and three weeks away from its feature freeze (August 28, 2025) [1]. Over the past week, no new governance changes were merged, but some new changes are undergoing community review. The nomination window for Project Team Leads and for four seats on the OpenStack Technical Committee begins on August 6, 2025 [2]. If you have any questions about the process, please post them on this mailing list or hop into #openstack-tc, #openstack-election, or #openstack-dev on OFTC and let's chat. This week, the TC is also looking to refresh the liaisons for projects governed by the "distributed-project-leadership" model—an opportunity for those teams to switch their governance styles, as well. === Weekly Meeting === The TC's weekly meeting focused on two major topics [3]: finalizing the definition of “affiliation” for TC election candidates and the next steps for retiring Monasca. On the affiliation front, we debated whether to reuse the OpenInfra bylaws language or simplify it for our needs. During the meeting, there was a consensus that the definition should focus on contributor intent and a visible employee-employer relationship without getting bogged down in legal technicalities. It's important to share our biases upfront for the sake of transparency and to strive toward the TC's affiliation diversity requirement. We are moving ahead with retiring the Monasca project. After earlier signals of interest in continuing maintenance, the project team now seems comfortable with retirement. The TC consulted this mailing list [4] to seek any further interest in the project. We'll work with the "unmaintained-core" group to clean up deliverables and code branches. We also touched on CI work to test OpenStack with Debian Bookworm and Trixie, which will help us make progress on the Eventlet removal community goal. Finally, a brief discussion ensued on OpenStack for AI, encouraging folks with architectural insight to join the Foundation's AI working group and its mailing list [5]. We wrapped with a shout out to the i18n interns and mentors for their recent progress [6]. The next weekly meeting of the TC is today, August 5, 2025, at 1700 UTC. This meeting will be hosted simultaneously over Meetpad and IRC. Please find the meeting's agenda and call details in the wiki [7]. I hope you'll be able to join us. === Governance Proposals === ==== Open for review ==== - Define "affiliation" within the context of the TC | https://review.opendev.org/c/openstack/governance/+/956024 - Add series names to runtimes doc | https://review.opendev.org/c/openstack/governance/+/955810 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ - 2025-08-20: Nominations close for OpenStack elections - 2025-08-26: OpenInfra Days, Korea: https://2025.openinfradays.kr/ - 2025-08-28: Feature Freeze deadline, Milestone-3 of the Flamingo release [1] - 2025-08-29: Colombia OpenInfra User Group Meetup: https://www.meetup.com/colombia-openinfra-user-group/events/307096751/ - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] 2026.1 OpenStack Elections: https://governance.openstack.org/election/ [3] TC Meeting IRC Log 2025-07-29: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-29-17.00.html [4] Call for maintainers for Monasca: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] OpenInfra AI WG List: https://lists.openinfra.org/mailman3/lists/ai-openstack-wg.lists.openinfra.… [6] i18n Internship with CMU: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, 2025-08-05: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[qa] Proposing Sean and Tosky to Devstack core
by Ghanshyam Maan 02 Aug '25

02 Aug '25

Hello Everyone, I would like to propose adding sean-k-mooney and tosky to Devstack core team. Both have shown great knowledge and have been engaged with Devstack for a long time. Having them in the core group would help us to continue maintaining Devstack. Feel free to provide your thoughts. If there are no objections by next week, I plan to add them to the Gerrit group by Friday, August 8th. -gmaan

2 1

[Cinder] Cinder NetApp driver not working as expected on NVMe over TCP
by Vincent Godin 01 Aug '25

01 Aug '25

Hello, We have NetApp C800 arrays for our OpenStack. We have set up the Cinder configuration to use the "NVMe over TCP" protocol. We are currently seeing the following issue: - the volumes (namespaces) are correctly mounted on the hypervisors - the multipath (native) configuration is correctly handled by Cinder (this can be seen in the logs) - the volumes are only attached by a single path Looking at the NetApp driver code, and more specifically at the *nvme_library.py* file and the *initialize_connection* function, we find on line 724: portal = (target_portals[0], self.NVME_PORT, self.NVME_TRANSPORT) data = { "target_nqn": str(target_nqn), "host_nqn": host_nqn, "portals": [portal], "vol_uuid": namespace_uuid } conn_info = {"driver_volume_type": "nvmeof", "data": data} If we look at the values of the target_portals[ ], the array does indeed have all the paths available for the targeted subsystem. However, the function only returns the first path : target_portals[0] I'm not a developer, so I can't guarantee that this is the cause of the problems encountered. What is certain is that manually connecting the namespace with the nvme command does indeed yield all four paths. I'll leave the existing discussion thread that led me to this observation open. Thank you. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Vincent Godin <vince.mlist(a)gmail.com> 29 juil. 2025 15:53 (il y a 3 jours) À Rajat, Sean, openstack-discuss Hello, Here are some of the results on the host. An instance is launched by Openstack on the compute nvme list Node Generic SN Model Namespace Usage Format FW Rev --------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- -------- /dev/nvme0n1 /dev/ng0n1 81O3QJXiLzBDAAAAAAAH NetApp ONTAP Controller 0x2 16.11 GB / 16.11 GB 4 KiB + 0 B FFFFFFFF if we have a look in the subsystem nvme list-subsys nvme-subsys0 - NQN=nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 hostnqn=nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 iopolicy=round-robin \ +- nvme0 tcp traddr=10.10.184.3,trsvcid=4420,src_addr=10.10.184.33 live I have only one path I disconnect the subsystem manually nvme disconnect -n nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 NQN:nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 disconnected 1 controller(s) I reconnect to the subsystem with a manual command nvme connect-all -t tcp -a 10.10.186.3 nvme list Node Generic SN Model Namespace Usage Format FW Rev --------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- -------- /dev/nvme0n2 /dev/ng0n2 81O3QJXiLzBDAAAAAAAH NetApp ONTAP Controller 0x2 16.11 GB / 16.11 GB 4 KiB + 0 B FFFFFFFF And if we look at the subsystem nvme list-subsys nvme-subsys0 - NQN=nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 hostnqn=nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 iopolicy=round-robin \ +- nvme5 tcp traddr=10.10.184.3,trsvcid=4420,src_addr=10.10.184.33 live +- nvme4 tcp traddr=10.10.186.3,trsvcid=4420,src_addr=10.10.186.33 live +- nvme3 tcp traddr=10.10.184.4,trsvcid=4420,src_addr=10.10.184.33 live +- nvme2 tcp traddr=10.10.186.4,trsvcid=4420,src_addr=10.10.186.33 live As you can see, i have four paths Configuration details about multipath : - in nova.conf [libvirt] volume_use_multipath = True - in cinder.conf [DEFAULT] target_protocol = nvmet_tcp ... [netapp-backend] use_multipath_for_image_xfer = True netapp_storage_protocol = nvme ... /sys/module/nvme_core/parameters/multipath cat /sys/module/nvme_core/parameters/multipath Y nova-compute.log grep -i get_connector_properties /var/log/kolla/nova/nova-compute.log 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - default default] LIGHTOS: finally hostnqn: nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 dsc: get_connector_properties /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:115 2025-07-29 14:09:51.553 7 DEBUG os_brick.utils [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - default default] <== get_connector_properties: return (30ms) {'platform': 'x86_64', 'os_type': 'linux', 'ip': '10.10.52.161', 'host': 'pkc-dcp-cpt-03', *'multipath': True, 'enforce_multipath': True*, 'initiator': 'iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1', 'do_local_attach': False, 'nvme_hostid': '5ca8b6d2-aa7d-42d8-bf74-c18484fab68c', 'system uuid': '31343550-3939-5a43-4a44-305930304c48', 'nqn': 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', *'nvme_native_multipath': True*, 'found_dsc': '', 'host_ips': ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', 'fe80::4c20:48ff:fe0f:2660']} trace_logging_wrapper /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:204 multipathd systemctl status multipathd.service ○ multipathd.service Loaded: masked (Reason: Unit multipathd.service is masked.) Active: inactive (dead) If you can see some reason to explain why openstack connect to the subsystem only with one path !!! Thanks ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Rajat Dhasmana 30 juil. 2025 12:37 (il y a 2 jours) À moi, Sean, openstack-discuss On Wed, Jul 30, 2025 at 3:15 PM Vincent Godin <vince.mlist(a)gmail.com> wrote: > Hello guys, > > Some more informations found in the nova-compute.log : > > -try iscsi > > 2025-07-29 14:09:51.523 1222 DEBUG oslo_concurrency.processutils [-] > Running cmd (subprocess): cat /etc/iscsi/initiatorname.iscsi execute > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:349 > 2025-07-29 14:09:51.528 1222 DEBUG oslo_concurrency.processutils [-] CMD > "cat /etc/iscsi/initiatorname.iscsi" returned: 0 in 0.005s execute > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:372 > 2025-07-29 14:09:51.528 1222 DEBUG oslo.privsep.daemon [-] privsep: > reply[90a51cdb-5701-4339-b059-fefb0b79b7a5]: (4, ('## DO NOT EDIT OR REMOVE > THIS FILE!\n## If you remove this file, the iSCSI daemon will not > start.\n## If you change the InitiatorName, existing access control > lists\n## may reject this initiator. The InitiatorName must be unique\n## > for each iSCSI initiator. Do NOT duplicate iSCSI > InitiatorNames.\nInitiatorName=iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1\n', > '')) _call_back > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_privsep/daemon.py:503 > > -try lightos ??? > > 2025-07-29 14:09:51.552 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: [Errno 111] ECONNREFUSED find_dsc > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:135 > 2025-07-29 14:09:51.553 7 INFO os_brick.initiator.connectors.lightos [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] Current host hostNQN > nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 and > IP(s) are ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', > '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', > 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', > 'fe80::4c20:48ff:fe0f:2660'] > 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: did not find dsc, continuing anyway. > get_connector_properties > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:112 > 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: finally hostnqn: > nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 dsc: > get_connector_properties > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:115 > > -then > > 2025-07-29 14:09:51.553 7 DEBUG os_brick.utils [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] <== > get_connector_properties: return (30ms) {'platform': 'x86_64', 'os_type': > 'linux', 'ip': '10.10.52.161', 'host': 'pkc-dcp-cpt-03', 'multipath': True, > 'enforce_multipath': True, 'initiator': > 'iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1', 'do_local_attach': False, > 'nvme_hostid': '5ca8b6d2-aa7d-42d8-bf74-c18484fab68c', 'system uuid': > '31343550-3939-5a43-4a44-305930304c48', 'nqn': > 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', > 'nvme_native_multipath': True, 'found_dsc': '', 'host_ips': > ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', > '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', > 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', > 'fe80::4c20:48ff:fe0f:2660']} trace_logging_wrapper > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:204 > 'multipath': True, 'enforce_multipath': True This shows that multipath configuration is set correctly. It would be good to search for this log entry[1] in cinder-volume logs and see the *portals *field to verify how many portals does the netapp nvme driver returns *Initialize connection info:* https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netap… > 2025-07-29 14:09:51.554 7 DEBUG nova.virt.block_device [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] [instance: > 3fcb3e36-1890-44f7-9c3c-283c05e91910] Updating existing volume attachment > record: b81aea6e-f2ae-4781-8c2e-3b7f1606ba0d _volume_attach > /var/lib/kolla/venv/lib/python3.12/site-packages/nova/virt/block_device.py:666 > 2025-07-29 14:09:53.680 7 DEBUG os_brick.initiator.connectors.nvmeof [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] ==> connect_volume: > call "{'self': <os_brick.initiator.connectors.nvmeof.NVMeOFConnector object > at 0x7cf65c576090>, 'connection_properties': {'target_nqn': > 'nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5', > 'host_nqn': > 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', > 'portals': [['10.10.184.3', 4420, 'tcp']], 'vol_uuid': > '69da9918-7e84-4ee4-b7bb-9b50e3e6d739', 'qos_specs': None, 'access_mode': > 'rw', 'encrypted': False, 'cacheable': False, 'enforce_multipath': True}}" > trace_logging_wrapper > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:177 > 'portals': [['10.10.184.3', 4420, 'tcp']] Here we can see that there is only one portal returned by the netapp driver

1 0

[Neutron] - General thoughts on tenancy network MTU
by Karl Kloppenborg 01 Aug '25

01 Aug '25

Hi Neutrinos, I was discussing with a colleague about our MTU settings within our Openstack regions, generally speaking we have a physnet_global_mtu of 1550 with tenancy networks automatically provisioned as 1500 VXLAN. This ends up with VM’s receiving DHCP MTU settings of 1500 which is fine, however reading about yesterday’s discussion on OVN performance, Nguyen’s recommendation was to enable Jumboframes. This got me thinking, what do you set your tenancy and phynet MTU’s to? Very interested to hear about your experiences with running 9k MTU’s on the VM networks etc, what impact this has on OVS/OVN routers and northbound connectivity being 1500. Thanks, Karl. Karl Kloppenborg Chief Technology Officer m: +61 437 239 565 resetdata.com<https://resetdata.com/> [cid:reset_69557fc2-1d63-4932-b5fd-93bd4f39ca7b.png] ResetData supports Mandatory Client Related Financial Disclosures – Scope 3 Emissions Reporting For more information on the phasing of these requirements for business please visit; https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…<https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…> This email transmission is intended only for the addressee / person responsible for delivery of the message to such person and may contain confidential or privileged information. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. Whilst this email has been checked for viruses, the sender does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments. If you received this e-mail in error please delete it and any attachments and kindly notify us by immediately sending an email to contact(a)resetdata.com.au<mailto:contact@resetdata.com.au>

2 1

(Ceilometer) Openstack - Kolla-Ansible deployment - Ceilometer (Central & compute) Docker Containers are unhealthy
by TRB PREM KUMAR 01 Aug '25

01 Aug '25

Hi, We have deployed an all-in-one OpenStack server for billing. Now ceilometer containers are unhealthy. Please help us to resolve this issue. Reference Output for reference: trb1@openstack-aio-01:~$ docker ps | grep ceil c53fc69ba42b quay.io/openstack.kolla/ceilometer-compute:2024.2-rocky-9 "dumb-init --single-…" About a minute ago Up About a minute *(unhealthy) * ceilometer_compute 9337af646e0f quay.io/openstack.kolla/ceilometer-central:2024.2-rocky-9 "dumb-init --single-…" 30 minutes ago Up About a minute ( *unhealthy)* ceilometer_central 554c4b8ccd86 quay.io/openstack.kolla/ceilometer-notification:2024.2-rocky-9 "dumb-init --single-…" 4 days ago Up About a minute (healthy) ceilometer_notification *** Logs files are attached for reference. Regards, TRB.

3 6

[neutron] Drivers meeting canceled Friday, August 1st
by Brian Haley 01 Aug '25

01 Aug '25

Hello Neutrinos: I am going to cancel tomorrow's Drivers meetings as there is no agenda. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[scientific-sig][help] Research about private cloud
by Winicius Allan 01 Aug '25

01 Aug '25

Hi all! I'm about to write my final paper, and I want to research something related to OpenStack and private clouds. If someone wants to take the time to discuss the problems in your environment, I'd be very glad!What I had on my mind is: - There is something that could improve utilization and performance when the user is not charged about their use on a private cloud. - There is any process scheduling algorithm that could be used on specific workloads instead of Linux default scheduler that can improve application performance? I was thinking about using eBPF here. Best regards.

2 1