January 2025 - openstack-discuss - lists.openstack.org

[ops][nova] How to make sure that on a hypervisor there is room for a VM with a specific flavor
by Massimo Sgaravatto 07 Jan '25

07 Jan '25

Dear all I have the following use case: I defined a flavor F for VMS with 10 VCPUs, 20 GB of RAM, 30 GB of root disk, 1 GPU XYZ. I use PCI passthrough to manage GPUs. I have only a XYZ GPU on my cluster (on a H hypervisor), so a VM using this flavor F must be "placed" to the compute node H (and this is not a problem: I know how to do that). H is very large: it has a lot of RAM and cores, so it can host other VMs that do not use GPUs. How can I make it so that VMs without GPU can go on H, but there must be room for a VM with flavor F (if it doesn't already exist)? Thanks, and happy new year ! Cheers, Massimo

3 3

ERROR dpif_netlink|INFO|dpif_netlink_meter_transact OVS_METER_CMD_SET failed
by alibasafa18＠gmail.com 07 Jan '25

07 Jan '25

I have set up OpenStack using Kolla Ansible with OVS and OVN. On one compute node, meters are functioning correctly, but on another, I am encountering an issue. Both nodes use the system datapath, have the same kernel version, and run the same version of OVS. Despite this, the problem persists. Has anyone experienced a similar issue? What could be the root cause? For example, I have two compute nodes. One of them does not have any issues, but the other meter did not work . following compute meter does not working: > sudo docker exec -it openvswitch_vswitchd bash (openvswitch-vswitchd)[root@compute1 /]# lsmod | grep open openvswitch 172032 13 nsh 16384 1 openvswitch nf_conncount 24576 1 openvswitch nf_nat 49152 1 openvswitch nf_conntrack 172032 6 nf_nat,nfnetlink_cttimeout,openvswitch,nf_conntrack_netlink,nf_conncount,ip_vs nf_defrag_ipv6 24576 3 nf_conntrack,openvswitch,ip_vs libcrc32c 16384 6 nf_conntrack,nf_nat,openvswitch,btrfs,raid456,ip_vs (openvswitch-vswitchd)[root@compute1 /]# ovs-appctl dpif/show-dp-features br-int Masked set action: Yes Tunnel push pop: No Ufid: Yes Truncate action: Yes Clone action: Yes Sample nesting: 10 Conntrack eventmask: Yes Conntrack clear: Yes Max dp_hash algorithm: 0 Check pkt length action: Yes Conntrack timeout policy: Yes Explicit Drop action: No Optimized Balance TCP mode: No Conntrack all-zero IP SNAT: Yes MPLS Label add: Yes Max VLAN headers: 2 Max MPLS depth: 3 Recirc: Yes CT state: Yes CT zone: Yes CT mark: Yes CT label: Yes CT state NAT: Yes CT orig tuple: Yes CT orig tuple for IPv6: Yes IPv6 ND Extension: No (openvswitch-vswitchd)[root@compute1 /]# ovs-ofctl -OOpenFlow15 meter-features br-int OFPST_METER_FEATURES reply (OF1.5) (xid=0x2): max_meter:0 max_bands:0 max_color:0 band_types: 0 capabilities: 0 (openvswitch-vswitchd)[root@compute1 /]# ovs-vsctl --version ovs-vsctl (Open vSwitch) 3.3.2 DB Schema 8.5.0 (openvswitch-vswitchd)[root@compute1 /]# uname -r 5.15.0-86-generic (openvswitch-vswitchd)[root@compute1 /]# uptime 08:27:39 up 87 days, 19:51, 0 users, load average: 3.36, 4.58, 4.19 ====================== following compute working without issue: > sudo docker exec -it openvswitch_vswitchd bash (openvswitch-vswitchd)[root@compute2 /]# lsmod | grep open openvswitch 172032 23 nsh 16384 1 openvswitch nf_conncount 24576 1 openvswitch nf_nat 49152 1 openvswitch nf_conntrack 172032 6 nf_nat,nfnetlink_cttimeout,openvswitch,nf_conntrack_netlink,nf_conncount,ip_vs nf_defrag_ipv6 24576 3 nf_conntrack,openvswitch,ip_vs libcrc32c 16384 6 nf_conntrack,nf_nat,openvswitch,btrfs,raid456,ip_vs (openvswitch-vswitchd)[root@compute2 /]# ovs-appctl dpif/show-dp-features br-int Masked set action: Yes Tunnel push pop: No Ufid: Yes Truncate action: Yes Clone action: Yes Sample nesting: 10 Conntrack eventmask: Yes Conntrack clear: Yes Max dp_hash algorithm: 0 Check pkt length action: Yes Conntrack timeout policy: Yes Explicit Drop action: No Optimized Balance TCP mode: No Conntrack all-zero IP SNAT: Yes MPLS Label add: Yes Max VLAN headers: 2 Max MPLS depth: 3 Recirc: Yes CT state: Yes CT zone: Yes CT mark: Yes CT label: Yes CT state NAT: Yes CT orig tuple: Yes CT orig tuple for IPv6: Yes IPv6 ND Extension: No (openvswitch-vswitchd)[root@compute27 /]# ovs-ofctl -OOpenFlow15 meter-features br-int OFPST_METER_FEATURES reply (OF1.5) (xid=0x2): max_meter:200000 max_bands:1 max_color:0 band_types: drop capabilities: kbps pktps burst stats (openvswitch-vswitchd)[root@compute2 /]# ovs-vsctl --version ovs-vsctl (Open vSwitch) 3.3.2 DB Schema 8.5.0 (openvswitch-vswitchd)[root@compute2 /]# uname -r 5.15.0-86-generic (openvswitch-vswitchd)[root@compute2 /]# uptime 08:29:47 up 87 days, 19:53, 0 users, load average: 11.23, 13.13, 13.29

1 0

ERROR dpif_netlink|INFO|dpif_netlink_meter_transact OVS_METER_CMD_SET failed
by alibasafa18＠gmail.com 07 Jan '25

07 Jan '25

I have set up OpenStack using Kolla Ansible with OVS and OVN. On one compute node, meters are functioning correctly, but on another, I am encountering an issue. Both nodes use the system datapath, have the same kernel version, and run the same version of OVS. Despite this, the problem persists. Has anyone experienced a similar issue? What could be the root cause? i have both compute for example in the following. following compute node i have issue: > sudo docker exec -it openvswitch_vswitchd bash (openvswitch-vswitchd)[root@si1-compute1 /]# lsmod | grep open openvswitch 172032 13 nsh 16384 1 openvswitch nf_conncount 24576 1 openvswitch nf_nat 49152 1 openvswitch nf_conntrack 172032 6 nf_nat,nfnetlink_cttimeout,openvswitch,nf_conntrack_netlink,nf_conncount,ip_vs nf_defrag_ipv6 24576 3 nf_conntrack,openvswitch,ip_vs libcrc32c 16384 6 nf_conntrack,nf_nat,openvswitch,btrfs,raid456,ip_vs (openvswitch-vswitchd)[root@si1-compute4174 /]# ovs-appctl dpif/show-dp-features br-int Masked set action: Yes Tunnel push pop: No Ufid: Yes Truncate action: Yes Clone action: Yes Sample nesting: 10 Conntrack eventmask: Yes Conntrack clear: Yes Max dp_hash algorithm: 0 Check pkt length action: Yes Conntrack timeout policy: Yes Explicit Drop action: No Optimized Balance TCP mode: No Conntrack all-zero IP SNAT: Yes MPLS Label add: Yes Max VLAN headers: 2 Max MPLS depth: 3 Recirc: Yes CT state: Yes CT zone: Yes CT mark: Yes CT label: Yes CT state NAT: Yes CT orig tuple: Yes CT orig tuple for IPv6: Yes IPv6 ND Extension: No (openvswitch-vswitchd)[root@si1-compute1 /]# ovs-ofctl -OOpenFlow15 meter-features br-int OFPST_METER_FEATURES reply (OF1.5) (xid=0x2): max_meter:0 max_bands:0 max_color:0 band_types: 0 capabilities: 0 (openvswitch-vswitchd)[root@si1-compute1 /]# ovs-vsctl --version ovs-vsctl (Open vSwitch) 3.3.2 DB Schema 8.5.0 (openvswitch-vswitchd)[root@si1-compute1 /]# uname -r 5.15.0-86-generic (openvswitch-vswitchd)[root@si1-compute1 /]# uptime 08:27:39 up 87 days, 19:51, 0 users, load average: 3.36, 4.58, 4.19 ================================= following compute node working correctly: (openvswitch-vswitchd)[root@si1-compute2 /]# lsmod | grep open openvswitch 172032 23 nsh 16384 1 openvswitch nf_conncount 24576 1 openvswitch nf_nat 49152 1 openvswitch nf_conntrack 172032 6 nf_nat,nfnetlink_cttimeout,openvswitch,nf_conntrack_netlink,nf_conncount,ip_vs nf_defrag_ipv6 24576 3 nf_conntrack,openvswitch,ip_vs libcrc32c 16384 6 nf_conntrack,nf_nat,openvswitch,btrfs,raid456,ip_vs (openvswitch-vswitchd)[root@si1-compute2 /]# ovs-appctl dpif/show-dp-features br-int Masked set action: Yes Tunnel push pop: No Ufid: Yes Truncate action: Yes Clone action: Yes Sample nesting: 10 Conntrack eventmask: Yes Conntrack clear: Yes Max dp_hash algorithm: 0 Check pkt length action: Yes Conntrack timeout policy: Yes Explicit Drop action: No Optimized Balance TCP mode: No Conntrack all-zero IP SNAT: Yes MPLS Label add: Yes Max VLAN headers: 2 Max MPLS depth: 3 Recirc: Yes CT state: Yes CT zone: Yes CT mark: Yes CT label: Yes CT state NAT: Yes CT orig tuple: Yes CT orig tuple for IPv6: Yes IPv6 ND Extension: No (openvswitch-vswitchd)[root@si1-compute2 /]# ovs-ofctl -OOpenFlow15 meter-features br-int OFPST_METER_FEATURES reply (OF1.5) (xid=0x2): max_meter:200000 max_bands:1 max_color:0 band_types: drop capabilities: kbps pktps burst stats (openvswitch-vswitchd)[root@si1-compute2 /]# ovs-vsctl --version ovs-vsctl (Open vSwitch) 3.3.2 DB Schema 8.5.0 (openvswitch-vswitchd)[root@si1-compute2 /]# uname -r 5.15.0-86-generic (openvswitch-vswitchd)[root@si1-compute2 /]# uptime 08:29:47 up 87 days, 19:53, 0 users, load average: 11.23, 13.13, 13.29

1 0

[tc][all] OpenStack Technical Committee Weekly Meeting Agenda (2025.1/R-12)
by Goutham Pacha Ravi 06 Jan '25

06 Jan '25

Hello Stackers, Happy New Year! The OpenStack Technical Committee will resume its regular meeting schedule this week. The next weekly meeting is scheduled to take place simultaneously on Video (Zoom) and IRC (OFTC) on January 7, 2024, at 1800 UTC. Please find the meeting agenda and details for joining the meeting on the meeting wiki [1]. On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] TC Meeting Agenda, 2025-01-07: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

custom playbook for nova
by engineer2024 06 Jan '25

06 Jan '25

can anyone guide me what are the tasks required for configuring nova service in OSA, so that I want to execute only those tasks and db steps , skipping the package installation steps. So I need to run nova playbook just to configure the nova like nova.conf, populating it with relevant options, do nova db migrate and then just restart the services. Is there a way to do it ? Thanks elinux

2 2

yoga to antelope upgrade path
by Satish Patel 05 Jan '25

05 Jan '25

Folks, I am running yoga in production with ovn driver and planning to upgrade to the 2023.1 release. Are there any issues to directly go to 2023.1 before intermediate release? Or anything critical I should be aware of?

3 3

[neutron][ovn] ovn database backup and restore
by Satish Patel 04 Jan '25

04 Jan '25

Folks, I have OVN running on 3 node controllers with a RAFT clustering. What is the best way to take backup of all the databases of nb_db and sb_db and how to restore them during a full disaster situation? Is the following the correct way to take backup? ovsdb-client backup unix:///run/ovn/ovnnb_db.sock OVN_Northbound > nb-snap-$(date +%s).txt ovsdb-client backup unix:///run/ovn/ovnsb_db.sock OVN_Southbound > sb-snap-$(date +%s).txt During restore on what node we should restore and does restore work on fresh cluster or existing cluster? How do other folks handle disaster scenarios where all 3 nodes are down or required migration?

3 6

Failing at TASK [glance : Copy over multiple ceph configs for Glance]
by Karera Tony 04 Jan '25

04 Jan '25

Hello Team, I am deploying Openstack release 2024.02 with External Ceph. However I am encountering the error below. But it is failing here TASK [glance : Copy over multiple ceph configs for Glance] Please assist Regards Tony Karera

2 1

[release] Release countdown for week R-12
by Thierry Carrez 03 Jan '25

03 Jan '25

Development Focus ----------------- The epoxy-2 milestone is next week, on January 9th, 2025! Epoxy-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/epoxy/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library that has not been otherwise released since milestone 1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new 2025.1 Epoxy deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables and need to have done a release by milestone-2. Changes proposing those deliverables for inclusion in 2025.1 Epoxy have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in 2025.1 Epoxy, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Epoxy-2 Milestone: January 9th, 2025 2025.1 Epoxy final release: April 2nd, 2025 -- Thierry Carrez (ttx)

1 0