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

GPU PCI passthrough woes.
by Andy Speagle 09 Apr '25

09 Apr '25

Hey Folks, I could use a little assistance getting GPU passthrough working. I had this working already for one flavor of nvidia gpu... and I've added some hosts with a much newer gpu... I've updated the pci_alias and pci_passthrough variables and those seem to be getting set properly in nova.conf passthrough_whitelist = [{"vendor_id":"10de", "product_id":"1b06"},{"vendor_id":"10de", "product_id":"26b9"}] alias = {"name": "gpu", "product_id": "1b06", "vendor_id": "10de"} alias = {"name": "gpu-l40s", "product_id": "26b9", "vendor_id": "10de"} I believe I have all of the iommu stuff configured and have the pci- stub module entries... dmesg output shows that the GPUs are being claimed by the stub module. $ openstack flavor show t1.small_gpu_l40s +----------------------------+--------------------------------------+ | Field | Value | +----------------------------+--------------------------------------+ | OS-FLV-DISABLED:disabled | False | | OS-FLV-EXT-DATA:ephemeral | 0 | | access_project_ids | None | | description | None | | disk | 0 | | id | af70c94e-0026-4a39-bc1e-dfb93b286a54 | | name | t1.small_gpu_l40s | | os-flavor-access:is_public | True | | properties | pci_passthrough:alias='gpu-l40s:1' | | ram | 2048 | | rxtx_factor | 1.0 | | swap | 0 | | vcpus | 1 | +----------------------------+--------------------------------------+ Yet... I can't seem to get an instance to run using that new flavor... keeps complaining about there not being enough hosts available. Fault: code: 500 created: 2024-10-30T02:04:33Z message: "No valid host was found. There are not enough hosts available." details: | Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 1580, in schedule_and_build_instances host_lists = self._schedule_instances(context, request_specs[0], File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 940, in _schedule_instances host_lists = self.query_client.select_destinations( File "/usr/lib/python3/dist- packages/nova/scheduler/client/query.py", line 41, in select_destinations return self.scheduler_rpcapi.select_destinations(context, spec_obj, File "/usr/lib/python3/dist-packages/nova/scheduler/rpcapi.py", line 160, in select_destinations return cctxt.call(ctxt, 'select_destinations', **msg_args) File "/usr/lib/python3/dist- packages/oslo_messaging/rpc/client.py", line 189, in call result = self.transport._send( File "/usr/lib/python3/dist- packages/oslo_messaging/transport.py", line 123, in _send return self._driver.send(target, ctxt, message, File "/usr/lib/python3/dist- packages/oslo_messaging/_drivers/amqpdriver.py", line 689, in send return self._send(target, ctxt, message, wait_for_reply, timeout, File "/usr/lib/python3/dist- packages/oslo_messaging/_drivers/amqpdriver.py", line 681, in _send raise result nova.exception_Remote.NoValidHost_Remote: No valid host was found. There are not enough hosts available. Traceback (most recent call last): File "/usr/lib/python3/dist- packages/oslo_messaging/rpc/server.py", line 241, in inner return func(*args, **kwargs) File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 223, in select_destinations selections = self._select_destinations( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 250, in _select_destinations selections = self._schedule( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 416, in _schedule self._ensure_sufficient_hosts( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 455, in _ensure_sufficient_hosts raise exception.NoValidHost(reason=reason) nova.exception.NoValidHost: No valid host was found. There are not enough hosts available. Any clues on how/where to dig into this more to see what might be missing? Thanks. -- Andy Speagle

3 2

[Devstack] Trying to setup development environment on VM
by Ishan Shanware (ishanwar) 16 Mar '25

16 Mar '25

Hello Everyone, I am currently trying to setup in all-in-one development environment for OpenStack on a Debian VM. The VM has 16 GB RAM and 4 CPUs. However, I face an error while trying to run FORCE=yes ./stack.sh. I get an error that keystone does not start. This causes the entire process to fail. Requesting assistance in solving this issue. I am following the this guide: https://docs.openstack.org/devstack/latest/guides/single-machine.html PFA the error log and error message on the terminal. [Call Trace] ./stack.sh:1126:start_keystone /opt/stack/devstack/lib/keystone:549:die [ERROR] /opt/stack/devstack/lib/keystone:549 keystone did not start Error on exit World dumping... see /opt/stack/logs/worlddump-2024-11-18-150808.txt for details ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory) ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory) Thanks in advance, Ishan

3 5

[all][tc][ptl][qa] Migrating upstream CI/CD jobs to Ubuntu Noble (24.04)
by Ghanshyam Mann 14 Mar '25

14 Mar '25

Hello Everyone, As per the 2025.2 cycle testing runtime, we need to run upstream CI/CD jobs on Ubuntu Noble (24.04) [1]. For better tracking and speeding up this work, it is the community-wide goal for this cycle[2]. This is the etherpad which has the migration plan and will be used for the tracking: - https://etherpad.opendev.org/p/migrate-to-noble I have prepared the change(WIP) for base jobs migration on Noble (openstack tox jobs, devstack, and tempest) which will migrate most of the projects jobs. Tempest change[3] include dependency on openstack tox, devstack base jobs changes so testing project gate using the the tempest change will test the complete set. Refer to the etherpad for the complete migration plan/steps. * Deadline: Nov 29th 2024 (R18) is the deadline to test/fix the projects jobs and to merge the base jobs running on Noble (openstck tox, devstack, and tempest). [1] https://governance.openstack.org/tc/reference/runtimes/2025.1.html [2] https://governance.openstack.org/tc/goals/selected/migrate-ci-jobs-to-ubunt… [3] https://review.opendev.org/c/openstack/tempest/+/932156 -gmann

2 9

[kolla] [nova] API flags ignored in Wallaby
by Albert Braden 12 Mar '25

12 Mar '25

After rebuilding our Train clusters on Wallaby we are seeing some API issues. It appears that flags that work in Train are still documented in Wallaby, but are ignored. Do we have something setup wrong, or are we encountering bugs? The first thing is the “locked” list: Train: openstack server list --all-projects --locked --os-compute-api-version 2.73 <empty list because nothing is locked> openstack server list --all-projects --unlocked --os-compute-api-version 2.73 <list of every VM in the cluster> Wallaby (locked flag is ignored): openstack server list --all-projects --locked --os-compute-api-version 2.73 <list of every VM in the cluster> openstack server list --all-projects --unlocked --os-compute-api-version 2.73 <list of every VM in the cluster> The second problem is the hypervisor list. We can’t get “long” output in Wallaby: Train: openstack hypervisor list --long | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | vCPUs Used | vCPUs | Memory MB Used | Memory MB | Wallaby (long flag is ignored): openstack hypervisor list --long | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State |

6 14

[nova]Intel RDT CAT Support Missing from OpenStack
by Junya Noguchi (Fujitsu) 24 Feb '25

24 Feb '25

To whom it may concern I have a question regarding the lack of Intel RDT CAT implementation in OpenStack We are planning to commit Resource Monitoring functionality to Openstack for ARM, and are exploring the implementation of Intel RDT on Openstack. We found the following blueprint for the Intel RDT CAT implementation in nova. https://blueprints.launchpad.net/nova/+spec/cat-support However, the Intel RDT CAT feature is not currently implemented in OpenStack. Has the implementation of Intel RDT CAT functionality in Openstack been rejected? Or is it just a development delay? Best regards, Junya Noguchi.

5 9

[tc][all][monasca ] Retiring the Monasca project
by Ghanshyam Mann 16 Feb '25

16 Feb '25

Hello everyone, As you might know, the Monasca project is not active and was marked 'inactive' since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next step is to retire the project. I'm sending this email to propose the Monasca retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

6 17

[nova] How to gain approval for a new feature on unavailable hardware
by taketani.ryo＠fujitsu.com 13 Feb '25

13 Feb '25

To Whom It May Concern, We are considering to propose and develop a new feature on OpenStack Nova for building Arm Confidential Computing Architecture (Arm CCA)-encrypted instances. I have some questions for doing it. * While specification of Arm CCA is already open(https://developer.arm.com/documentation/den0125/0300/Overview), No Arm CCA-enabled hardware is currently available to our knowledge. Therefore, we plan to conduct testing in an internal environment. * Would a proposal for a feature utilizing publicly unavailable hardware be acceptable to OpenStack? Alternatively, in this case, what steps or preparations are required for approval? * Should the blueprint and specification be submitted simultaneously? * The specification is currently incomplete. Building Arm CCA instances requires libvirt APIs, similar to AMD SEV instances(https://blueprints.launchpad.net/nova/+spec/amd-sev-libvirt-suppo…, but specification of these are not yet determined publicly. We are considering submitting the blueprint first to inform the community of our ongoing development efforts. Regards

3 6

openstack instances unable to reach the internet
by collinl＠churchofjesuschrist.org 11 Feb '25

11 Feb '25

I have been banging my head on this issue for quite some time now. I am hoping that somebody can help me see what I have misconfigured. Here is the situation. I have tried setting up several openstack installs, and in none of them am I able to reach the internet from the instances running inside of openstack. All of them are on Rocky Linux 9.5, running the dalmatian version of openstack, installed using packstack. (I have tried an all-in-one, with everything on a single node, and a cluster with the controller/networking on one node, and the compute running on separate nodes). I can get the cirros instances running on the backend network within openstack, and can ssh to them via the floating ip from the host without issues. The cirros instance can ping other cirros instances in the openstack controlled network (both on the backend network(subnet is in the 192.168.100.0/24 range, or on the external public network(subnet is in the 172.24.4.024 range) Even trying the simplest configuration, where everything is all on a single node (compute/networking/controller/etc), Everything from instance creation to VM migration/etc all seems to work just fine. However, the cirros instances cannot ping anything on the internet -- for example, I am unable to ping 8.8.8.8 or even the gateway that the host can reach (The host has an ip used to reach horizon on the 10.61.157.0/24 subnet on our internal lan) I can ping all interfaces from the cirros interface through the backend_network (192.168.100.0/24) through the public interface (172.24.4.0/24), and can even ping the host ip address (10.61.157.59) . . .However, I can't ping anything beyond that (i.e. the 10.61.147.1 gateway does not ping from the cirros instance) From the host commandline, it is able to reach everything external just fine (i.e. it can ping it's gateway 10.61.147.1 and 8.8.8.8 or anything else external) Here is the ip addr output from the host: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 00:1d:d8:b7:1e:df brd ff:ff:ff:ff:ff:ff inet6 fe80::21d:d8ff:feb7:1edf/64 scope link valid_lft forever preferred_lft forever 3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 56:d8:51:53:10:b0 brd ff:ff:ff:ff:ff:ff 4: br-int: <BROADCAST,MULTICAST> mtu 1442 qdisc noop state DOWN group default qlen 1000 link/ether 62:8c:b0:c2:3e:5a brd ff:ff:ff:ff:ff:ff 5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 00:1d:d8:b7:1e:df brd ff:ff:ff:ff:ff:ff inet 10.61.157.59/24 brd 10.61.157.255 scope global br-ex valid_lft forever preferred_lft forever inet 172.24.4.1/24 brd 172.24.4.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fe80::2446:29ff:fe58:6541/64 scope link valid_lft forever preferred_lft forever 6: tapeffe7cc1-56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue master ovs-system state UNKNOWN group default qlen 1000 link/ether fe:16:3e:e2:66:5d brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fee2:665d/64 scope link valid_lft forever preferred_lft forever 7: tap65170f1f-e0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000 link/ether 3a:26:09:cf:3d:4f brd ff:ff:ff:ff:ff:ff link-netns ovnmeta-65170f1f-e837-4b5e-a471-13e783e6b48e inet6 fe80::3826:9ff:fecf:3d4f/64 scope link valid_lft forever preferred_lft forever And the output from the ovs-vsctl show command: 46294eda-8a39-4775-875d-ef6ec9929346 Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-int fail_mode: secure datapath_type: system Port tap65170f1f-e0 Interface tap65170f1f-e0 Port patch-br-int-to-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24 Interface patch-br-int-to-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24 type: patch options: {peer=patch-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24-to-br-int} Port tapeffe7cc1-56 Interface tapeffe7cc1-56 Port br-int Interface br-int type: internal Bridge br-ex fail_mode: standalone Port patch-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24-to-br-int Interface patch-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24-to-br-int type: patch options: {peer=patch-br-int-to-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24} Port br-ex Interface br-ex type: internal Port eth0 Interface eth0 ovs_version: "3.3.1" Here is the info for the networks/subnets currently configured: From "openstack network list --long" +------------------------+-----------------+--------+------------------------+-------+--------+------------------------+--------------+-------------+--------------------+------+ | ID | Name | Status | Project | State | Shared | Subnets | Network Type | Router Type | Availability Zones | Tags | +------------------------+-----------------+--------+------------------------+-------+--------+------------------------+--------------+-------------+--------------------+------+ | 65170f1f-e837-4b5e-a47 | backend_network | ACTIVE | c5f408c4daed4fb2afefa4 | UP | False | b1e5aef4-77da-4b0b-9b9 | geneve | Internal | | | | 1-13e783e6b48e | | | 4fa039fe26 | | | 4-5aaf395484e0 | | | | | | b8e7a305-65f0-44ea-93a | public | ACTIVE | c5f408c4daed4fb2afefa4 | UP | False | 6cff8f70-9dc8-4f17-b78 | flat | External | | | | a-cc6ec741d408 | | | 4fa039fe26 | | | 0-32cf2aedb017 | | | | | | c0c67da4-22bf-4dd2-b4c | private | ACTIVE | 2967b1fe70794fa88cbb3d | UP | False | caed16ae-22ff-427a-a37 | geneve | Internal | | | | 2-2edcb41ffb97 | | | e7227cec77 | | | 0-6b891755bfa7 | | | | | +------------------------+-----------------+--------+------------------------+-------+--------+------------------------+--------------+-------------+--------------------+------+ From "openstack subnet list --long" +---------------+---------------+---------------+---------------+---------------+-------+--------------+------------------+-------------+------------+---------------+---------------+------+ | ID | Name | Network | Subnet | Project | DHCP | Name Servers | Allocation Pools | Host Routes | IP Version | Gateway | Service Types | Tags | +---------------+---------------+---------------+---------------+---------------+-------+--------------+------------------+-------------+------------+---------------+---------------+------+ | 6cff8f70-9dc8 | public_subnet | b8e7a305-65f0 | 172.24.4.0/24 | c5f408c4daed4 | False | | 172.24.4.2-172.2 | | 4 | 172.24.4.1 | | | | -4f17-b780-32 | | -44ea-93aa- | | fb2afefa44fa0 | | | 4.4.254 | | | | | | | cf2aedb017 | | cc6ec741d408 | | 39fe26 | | | | | | | | | | b1e5aef4-77da | backend_subne | 65170f1f-e837 | 192.168.100.0 | c5f408c4daed4 | True | | 192.168.100.100- | | 4 | 192.168.100.1 | | | | -4b0b-9b94-5a | t | -4b5e-a471-13 | /24 | fb2afefa44fa0 | | | 192.168.100.250 | | | | | | | af395484e0 | | e783e6b48e | | 39fe26 | | | | | | | | | | caed16ae-22ff | private_subne | c0c67da4-22bf | 10.0.0.0/24 | 2967b1fe70794 | True | | 10.0.0.2-10.0.0. | | 4 | 10.0.0.1 | | | | -427a-a370-6b | t | -4dd2-b4c2-2e | | fa88cbb3de722 | | | 254 | | | | | | | 891755bfa7 | | dcb41ffb97 | | 7cec77 | | | | | | | | | +---------------+---------------+---------------+---------------+---------------+-------+--------------+------------------+-------------+------------+---------------+---------------+------+ From "openstack floating ip list" +------------------------------------+---------------------+------------------+------------------------------------+------------------------------------+----------------------------------+ | ID | Floating IP Address | Fixed IP Address | Port | Floating Network | Project | +------------------------------------+---------------------+------------------+------------------------------------+------------------------------------+----------------------------------+ | 61d98a1c-f19a-451f-9353-6cb8305a0c | 172.24.4.175 | 192.168.100.128 | effe7cc1-566d-4574-b4e3-d9f440b776 | b8e7a305-65f0-44ea-93aa- | c5f408c4daed4fb2afefa44fa039fe26 | | 2f | | | 5e | cc6ec741d408 | | +------------------------------------+---------------------+------------------+------------------------------------+------------------------------------+----------------------------------+ From "openstack server list" +--------------------------------------+-------+--------+-----------------------------------------------+--------------------------+---------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------+--------+-----------------------------------------------+--------------------------+---------+ | e42372d2-946d-4c90-bf2d-1e36cda80e2f | test3 | ACTIVE | backend_network=172.24.4.175, 192.168.100.128 | N/A (booted from volume) | m1.tiny | +--------------------------------------+-------+--------+-----------------------------------------------+--------------------------+---------+ Any assistance in helping me figure out what I am missing to get external access would be greatly appreciated. Thank you!

4 14

[openstack][manila][cephfs]About access rule
by Nguyễn Hữu Khôi 10 Feb '25

10 Feb '25

Hello. I setup Manila with Cephfs driver-CephFS NFS shares and I use NFS-Ganesha based “ceph nfs” service. I can create a share and can mount after creating access rule: openstack share access create cephnfsshare ip 10.10.11.76 But I can mount my share from any ip. Is it a bug, or do I understand it wrong? My env: Openstack 2024 with Kolla-Ansible deployment Ceph Quincy Thank you. Regards Nguyen Huu Khoi

2 12

[freezer] Moving project bug tracker to launchpad
by Dmitriy Rabotyagov 05 Feb '25

05 Feb '25

Hey there, In order to simplify and align with most OpenStack projects on bug tracker I aim to move Freezer from different Storyboard [1] projects back to unified Launchpad [2] tracker. However, historically the OpenStack Administrators [3] group was not added as Freezer project administrator/owner on Launchpad, which means that no current maintainer of the project has the necessary rights to manage the mentioned Launchpad project. I've added all current Launchpad admins for Freezer project to CC of this email, to either of you to add "openstack-admins" [3] to the Freezer Drivers [4] team, so that OpenStack Infra team could assist with further recovering/managing access to the Launchpad project. That will be very nice if some of you could spend couple of minutes on making this change and help us avoid cumbersome process of recovering access to the project Thanks in advance! [1] https://storyboard.openstack.org/#!/project/list?q=freezer [2] https://launchpad.net/freezer [3] https://launchpad.net/~openstack-admins [4] https://launchpad.net/~freezer-drivers

4 3