OpenStack Nova手动安装：从零配置nova-api与nova-conductor

1. 项目概述为什么在2024年还要亲手装 NovaNova 是 OpenStack 的心脏——它不负责界面、不处理存储、也不管网络调度但它决定了每一台虚拟机能不能真正“活”起来。你点下“创建实例”按钮的那一刻背后是 Nova 在协调调度器、计算节点、数据库、消息队列和底层 Hypervisor 的精密协作。今天市面上绝大多数 OpenStack 部署工具比如 DevStack、Kolla、OpenStack-Ansible都把 Nova 当作一个“默认启用的黑盒模块”一键拉起、自动注册、日志埋点全包。但正因如此当生产环境里出现“实例卡在 spawning 状态”“调度器反复拒绝请求”“conductor 服务莫名掉线”这类问题时90% 的运维人员第一反应是翻日志、查配置、重启服务却很少有人能准确说出nova-scheduler启动时到底读了哪几个配置段nova-conductor连接数据库用的是哪个连接池参数nova-api的 WSGI 超时阈值在api-paste.ini还是nova.conf里生效这就是本项目存在的真实价值不是为了替代自动化部署而是为了重建对 Nova 控制平面的“肌肉记忆”。我带过三届 OpenStack 实训班发现一个规律能手敲openstack user create --domain default --password-prompt nova并理解每个参数含义的人排查keystoneauth认证失败的速度比只会复制粘贴admin-openrc的人快至少5倍能手动配置rabbitmqctl add_user nova RABBIT_PASS并验证nova.conf中transport_url rabbit://nova:RABBIT_PASScontroller是否被正确解析的人在遇到 AMQP 连接超时问题时根本不会去怀疑防火墙——因为他在安装阶段就亲手测过telnet controller 5672。关键词里高频出现的openstack-nova-api和openstack-nova-conductor不是两个孤立服务而是一组强耦合的控制平面组件nova-api是对外接口层所有 REST 请求首先进入这里做鉴权与路由nova-conductor则是内部事务协调者它把nova-compute节点上无法直接访问数据库的操作比如更新实例状态收归到控制节点执行避免计算节点直连 DB 带来的安全与性能风险。这种设计思想恰恰是理解整个 OpenStack 分布式架构的钥匙。所以本项目不叫“Nova 自动化部署”而叫“Nova 手动安装与配置”——手动是为了让每一个systemctl enable、每一行crudini --set、每一次openstack endpoint create都成为一次对 OpenStack 架构的深度触摸。适合谁来实操如果你正在备考 OpenStack Certified AdministratorOCOA或者刚接手一个遗留的 OpenStack 集群需要做故障复现又或者你是高校教师要给学生讲清楚“为什么 Nova 需要 conductor 层”那么这个项目就是为你量身定制的。它不要求你提前掌握 Kolla 或 TripleO但要求你熟悉 Linux 基础命令、能看懂 ini 文件结构、知道systemd服务管理的基本逻辑。接下来的内容我会以一台 Ubuntu 22.04 虚拟机为蓝本从零开始还原 Nova 控制节点的手动部署全过程所有命令、配置、参数选择都基于 OpenStack Yoga 版本2022.2 LTS的官方文档实践并结合我在金融行业私有云中踩过的坑进行针对性补全。2. 整体设计与思路拆解为什么必须分四步走Nova 手动安装绝不是“下载包→解压→启动”这么简单。它的核心难点在于依赖链长、权限层级深、组件交互隐晦。我见过太多人卡在第一步apt install openstack-nova-api后发现nova-api服务起不来journalctl -u nova-api显示ImportError: No module named keystoneauth1——这其实暴露了一个关键认知盲区OpenStack 组件不是独立二进制而是 Python 包它们的依赖关系由pip管理而apt安装的只是打包好的.deb其内部依赖可能与系统已有的python3-keystoneauth1版本冲突。因此我的整体设计严格遵循“环境隔离→基础服务就位→Nova 核心组件部署→跨组件联调验证”四步法每一步都解决一类特定风险。2.1 第一步环境隔离——为什么不用 root 直接装很多人图省事直接用sudo su -切到 root 用户操作。但 Nova 的nova用户、nova数据库用户、novaRabbitMQ 用户三者权限必须严格分离。如果全程用 root 操作很容易在/var/lib/nova/下误留 root 权限文件导致后续nova-compute启动时因权限不足无法写入instances/目录。我的做法是创建专用系统用户nova-installer所有安装操作在此用户下完成仅在必要时用sudo提权执行systemctl或mysql命令。这样做的好处是所有生成的配置文件、日志路径、临时目录的属主都是nova-installer后续切换到nova用户运行服务时权限继承清晰避免“权限地狱”。提示nova-installer用户不需要sudo全权限只需在/etc/sudoers中添加一行nova-installer ALL(root) NOPASSWD: /bin/systemctl, /usr/bin/mysql, /usr/bin/rabbitmqctl即可。这是最小权限原则的落地也是生产环境审计的基本要求。2.2 第二步基础服务就位——数据库与消息队列为何必须先于 NovaNova 的nova-api服务启动时会立即尝试连接 MySQL 数据库并查询services表nova-conductor启动后会立刻向 RabbitMQ 声明nova队列并监听nova交换机。如果数据库或消息队列未就绪nova-api会陷入无限重试systemctl status nova-api显示activating (start)状态长达数分钟最终超时失败。更隐蔽的问题是nova-api默认的数据库连接超时是 30 秒而nova-conductor的 AMQP 连接超时是 60 秒两者不同步会导致服务启动顺序错乱。因此我强制要求MySQL 必须完成nova数据库创建、用户授权、字符集设置三步RabbitMQ 必须完成novavhost 创建、nova用户添加、nova用户权限绑定三步且每一步都要用mysql -u root -p -e SHOW DATABASES;和rabbitmqctl list_vhosts实时验证。这不是多此一举而是为后续 Nova 组件的稳定启动建立确定性基线。2.3 第三步Nova 核心组件部署——为什么nova-api和nova-conductor必须同节点部署OpenStack 官方文档允许将nova-api和nova-conductor部署在不同节点但在实训场景下这种分离毫无必要反而引入额外复杂度。nova-conductor的核心职责是作为nova-compute与数据库之间的“代理”它本身不处理外部请求只响应nova-compute发来的 RPC 调用。如果把它单独部署就需要额外配置rpc_backend、rpc_response_timeout、oslo_messaging_rabbit等十余个参数且一旦网络抖动nova-compute就会报RPC timeout错误。而将两者共存于控制节点rpc_backend可直接设为rabbit所有通信走本地环回延迟低于 1ms稳定性远超跨节点方案。这也是为什么本项目标题强调“手动安装与配置”而非“高可用部署”——我们要先掌握单点稳定运行的全部细节再谈横向扩展。2.4 第四步跨组件联调验证——为什么openstack endpoint create是最关键的临门一脚很多学员做完前三步systemctl status nova-api显示active (running)就以为大功告成。但此时 Nova 还只是“活着”并未真正“接入 OpenStack 生态”。openstack endpoint create命令的作用是将nova-api的服务地址如http://controller:8774/v2.1注册到 Keystone 服务目录中。没有这一步openstack server list命令发出的请求Keystone 根本不知道该转发给谁会直接返回No endpoint found错误。更关键的是endpoint create会触发nova-api内部的keystoneauth插件重新加载服务目录缓存这是 Nova 与其他 OpenStack 服务Glance、Neutron建立信任链的起点。因此我把这一步放在最后作为整个安装流程的“验收闸门”只有openstack endpoint list | grep nova能看到三条有效 endpointpublic,internal,admin才算真正打通了 Nova 的任督二脉。3. 核心细节解析与实操要点配置文件里的魔鬼细节Nova 的配置看似只是修改nova.conf实则暗藏数十处影响系统行为的“魔鬼参数”。这些参数不写在官方快速入门指南里却在生产环境中决定着集群的稳定性与可维护性。下面我将逐个拆解最常被忽略、却又最致命的五个配置项并说明它们背后的原理与实操选择依据。3.1[DEFAULT] use_neutron True为什么必须显式关闭 Nova-networkOpenStack 早已废弃nova-network但nova.conf的默认值仍是use_neutron False。如果忘记修改nova-api启动时会尝试加载nova.network.manager.FlatManager而该模块在 Yoga 版本中已被彻底移除直接导致服务启动失败报错信息却是模糊的ImportError: cannot import name FlatManager from nova.network。这个问题的根源在于nova-network的代码路径与 Neutron 的 API 路径存在命名空间冲突use_neutron False会强制 Nova 加载一套已不存在的旧网络栈。因此必须在nova.conf的[DEFAULT]段显式写入use_neutron True且该参数必须位于[neutron]段之前。这是个典型的“默认值陷阱”新手极易中招。注意use_neutron True并不意味着 Nova 会自动帮你配好 Neutron它只是告诉 Nova“请使用 Neutron 的 API 来处理网络请求”。后续仍需在[neutron]段配置url、auth_url、project_domain_name等认证参数否则 Nova 会因无法连接 Neutron 而在创建实例时抛出NetworkNotFound异常。3.2[api_database] connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova_api为什么用pymysql而非mysqldbNova 的数据库驱动默认是mysql://这会调用MySQLdb库。但MySQLdb是 C 扩展编译依赖python-dev和libmysqlclient-dev在 Ubuntu 22.04 上安装极其繁琐且与 Python 3.10 的兼容性极差。而pymysql是纯 Python 实现pip install pymysql即可无编译依赖。更重要的是pymysql支持连接池自动回收、SQL 注入防护、字符集自动协商等高级特性。因此我强制将数据库连接字符串改为mysqlpymysql://并在[database]段添加max_retries 10和retry_interval 2。这两个参数的意义是当 MySQL 主库短暂不可用时nova-conductor不会立即崩溃而是每 2 秒重试一次最多重试 10 次即 20 秒这为数据库故障自愈争取了宝贵时间。3.3[oslo_messaging_rabbit] rabbit_hosts controller:5672为什么rabbit_hosts必须是列表格式官方文档示例中常写rabbit_host controller但这已是过时写法。Yoga 版本起rabbit_host参数已被弃用必须使用rabbit_hosts复数形式且其值必须是逗号分隔的字符串如controller:5672。如果错误地写成rabbit_hosts controllernova-api启动时会报TypeError: expected string or bytes-like object因为底层oslo_messaging期望接收一个可迭代对象。更隐蔽的坑是rabbit_hosts的端口必须显式写出不能省略。controller默认解析为controller:5672但rabbitmq服务实际监听的是5672AMQP和15672Management UInova只认5672。因此必须写死controller:5672而不是controller或controller:15672。这个细节在日志里几乎不体现只能靠对 RabbitMQ 协议的理解来规避。3.4[keystone_authtoken] www_authenticate_uri http://controller:5000为什么www_authenticate_uri和auth_url必须指向同一地址[keystone_authtoken]段有两个关键 URLwww_authenticate_uri用于生成 WWW-Authenticate 头和auth_url用于获取 token。在单节点部署中两者都应指向http://controller:5000。但如果www_authenticate_uri错误地指向了https://controller:5000启用了 HTTPS而auth_url仍是http://controller:5000nova-api在处理认证请求时会因协议不一致而失败报错keystoneauth1.exceptions.auth_plugins.MissingAuthPlugin: auth_plugin is None。这是因为www_authenticate_uri仅用于构造 HTTP 响应头而auth_url才是实际发起 token 获取请求的地址两者必须协议、域名、端口完全一致。我的实操心得是在实训环境中统一使用http://controller:5000禁用 HTTPS避免证书配置带来的额外复杂度。等 Nova 稳定运行后再通过 Nginx 反向代理统一加 HTTPS。3.5[scheduler] driver nova.scheduler.filter_scheduler.FilterScheduler为什么过滤器调度器是唯一合理选择Nova 提供三种调度器ChanceScheduler随机、FilterScheduler过滤权重、FakeScheduler测试用。ChanceScheduler已被标记为 deprecatedFakeScheduler仅用于单元测试。FilterScheduler是生产环境唯一可行的选择它通过两阶段筛选第一阶段filter过滤剔除不满足条件的主机如内存不足、CPU 不足、磁盘空间不够第二阶段weight权重对剩余主机打分如 CPU 使用率越低得分越高最终选择得分最高的主机。但关键细节在于FilterScheduler的默认过滤器列表是空的如果不手动配置[filter_scheduler] enabled_filters它会跳过所有过滤退化为随机调度。因此必须在nova.conf中添加[filter_scheduler]段并显式写入enabled_filters RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter。这个列表是我从生产集群中精简而来去掉了NUMATopologyFilter需要硬件支持和AggregateInstanceExtraSpecsFilter需要提前配置聚合确保在普通虚拟机上也能稳定运行。4. 实操过程与核心环节实现从零开始的完整部署流水线现在进入真正的动手环节。以下所有命令均在 Ubuntu 22.04 虚拟机4C8G50G 磁盘上实测通过步骤间有强依赖关系严禁跳步。我会在每个关键命令后解释其作用、常见报错及验证方法让你不仅知道“怎么做”更明白“为什么这么做”。4.1 环境准备创建专用用户与基础依赖安装首先创建nova-installer用户并赋予最小必要权限sudo useradd -m -s /bin/bash nova-installer sudo passwd nova-installer # 输入密码例如nova123 echo nova-installer ALL(root) NOPASSWD: /bin/systemctl, /usr/bin/mysql, /usr/bin/rabbitmqctl | sudo tee /etc/sudoers.d/nova-installer sudo chmod 0440 /etc/sudoers.d/nova-installer切换到新用户并更新系统su - nova-installer sudo apt update sudo apt upgrade -y安装基础依赖。注意这里不安装openstack-nova-*的 apt 包而是采用pip方式安装以精确控制版本sudo apt install -y python3-pip python3-venv python3-dev libffi-dev libssl-dev build-essential pip3 install --upgrade pip实操心得libffi-dev和libssl-dev是编译cryptography库的必需依赖如果缺失pip install openstack-nova会卡在Building wheel for cryptography步骤长达数分钟最终因内存不足失败。我曾因此在 2G 内存的虚拟机上反复重装三次直到发现这个依赖项。4.2 数据库与消息队列就绪MySQL 与 RabbitMQ 的精准配置4.2.1 MySQL 配置启动 MySQL 服务并登录sudo systemctl enable mysql sudo systemctl start mysql sudo mysql -u root -p # 输入 MySQL root 密码在 MySQL shell 中执行以下 SQL逐行输入注意分号CREATE DATABASE nova_api; CREATE DATABASE nova; CREATE DATABASE nova_cell0; GRANT ALL PRIVILEGES ON nova_api.* TO novalocalhost IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova_api.* TO nova% IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova.* TO novalocalhost IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova.* TO nova% IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova_cell0.* TO novalocalhost IDENTIFIED BY NOVA_DBPASS; GRANT ALL PRIVILEGES ON nova_cell0.* TO nova% IDENTIFIED BY NOVA_DBPASS; FLUSH PRIVILEGES; EXIT;关键说明nova_api、nova、nova_cell0是三个独立数据库。nova_api存储 API 相关元数据如 flavor、image 映射nova存储实例、主机、服务等核心状态nova_cell0是 Nova Cells V2 架构的根 cell 数据库即使单 cell 部署也必须存在。GRANT语句中%是为了允许nova-api服务从任意 IP 连接实训环境方便生产环境应限定为controller。4.2.2 RabbitMQ 配置安装并启动 RabbitMQsudo apt install -y rabbitmq-server sudo systemctl enable rabbitmq-server sudo systemctl start rabbitmq-server添加nova用户并配置权限sudo rabbitmqctl add_user nova RABBIT_PASS sudo rabbitmqctl add_vhost /nova sudo rabbitmqctl set_permissions -p /nova nova .* .* .*验证命令sudo rabbitmqctl list_vhosts应输出/novasudo rabbitmqctl list_users应显示nova用户sudo rabbitmqctl list_permissions -p /nova应显示nova对/novavhost 有全部权限。这三个验证缺一不可少一个都会导致nova-conductor启动失败。4.3 Nova 核心服务安装与配置nova-api与nova-conductor的协同部署4.3.1 创建 Python 虚拟环境并安装 Novapython3 -m venv /opt/nova-env source /opt/nova-env/bin/activate pip install --upgrade pip pip install openstack-nova25.2.0 # Yoga 版本对应 25.2.0为什么指定版本pip install openstack-nova默认安装最新版Zed 或 Antelope其配置文件结构与 Yoga 不兼容。25.2.0是 Yoga 的最后一个稳定版本号可通过pip index versions openstack-nova查询确认。4.3.2 生成并编辑nova.conf创建配置目录并生成初始配置sudo mkdir -p /etc/nova sudo chown -R nova-installer:nova-installer /etc/nova sudo cp /opt/nova-env/lib/python3.10/site-packages/nova/etc/nova/nova.conf /etc/nova/使用crudini工具比手动编辑更可靠批量修改配置# 安装 crudini sudo apt install -y crudini # 设置全局参数 crudini --set /etc/nova/nova.conf DEFAULT transport_url rabbit://nova:RABBIT_PASScontroller:5672 crudini --set /etc/nova/nova.conf DEFAULT my_ip 10.0.0.11 # 替换为你的 controller IP crudini --set /etc/nova/nova.conf DEFAULT use_neutron True crudini --set /etc/nova/nova.conf DEFAULT firewall_driver nova.virt.firewall.NoopFirewallDriver # 设置数据库参数 crudini --set /etc/nova/nova.conf api_database connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova_api crudini --set /etc/nova/nova.conf database connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova crudini --set /etc/nova/nova.conf database max_retries 10 crudini --set /etc/nova/nova.conf database retry_interval 2 # 设置 Keystone 认证 crudini --set /etc/nova/nova.conf keystone_authtoken www_authenticate_uri http://controller:5000 crudini --set /etc/nova/nova.conf keystone_authtoken auth_url http://controller:5000 crudini --set /etc/nova/nova.conf keystone_authtoken memcached_servers controller:11211 crudini --set /etc/nova/nova.conf keystone_authtoken auth_type password crudini --set /etc/nova/nova.conf keystone_authtoken project_domain_name Default crudini --set /etc/nova/nova.conf keystone_authtoken user_domain_name Default crudini --set /etc/nova/nova.conf keystone_authtoken project_name service crudini --set /etc/nova/nova.conf keystone_authtoken username nova crudini --set /etc/nova/nova.conf keystone_authtoken password NOVA_PASS # 设置 Glance 集成 crudini --set /etc/nova/nova.conf glance api_servers http://controller:9292 # 设置 Neutron 集成 crudini --set /etc/nova/nova.conf neutron url http://controller:9696 crudini --set /etc/nova/nova.conf neutron auth_url http://controller:5000 crudini --set /etc/nova/nova.conf neutron project_domain_name Default crudini --set /etc/nova/nova.conf neutron user_domain_name Default crudini --set /etc/nova/nova.conf neutron region_name RegionOne crudini --set /etc/nova/nova.conf neutron project_name service crudini --set /etc/nova/nova.conf neutron username neutron crudini --set /etc/nova/nova.conf neutron password NEUTRON_PASS # 设置 Scheduler crudini --set /etc/nova/nova.conf scheduler driver nova.scheduler.filter_scheduler.FilterScheduler crudini --set /etc/nova/nova.conf filter_scheduler enabled_filters RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter # 设置 oslo_messaging_rabbit crudini --set /etc/nova/nova.conf oslo_messaging_rabbit rabbit_hosts controller:5672 crudini --set /etc/nova/nova.conf oslo_messaging_rabbit rabbit_userid nova crudini --set /etc/nova/nova.conf oslo_messaging_rabbit rabbit_password RABBIT_PASS crudini --set /etc/nova/nova.conf oslo_messaging_rabbit rabbit_virtual_host /nova实操心得crudini是 OpenStack 社区推荐的配置工具它能自动处理 ini 文件的段落嵌套和引号转义。手动用vi编辑nova.conf时极易因多了一个空格或少了一个引号导致nova-api启动失败且错误日志不明确。用crudini可以 100% 避免此类低级错误。4.3.3 初始化数据库与创建服务凭证激活虚拟环境并初始化数据库source /opt/nova-env/bin/activate nova-manage api_db sync nova-manage db sync验证sudo mysql -u nova -pNOVA_DBPASS nova_api -e SHOW TABLES; | wc -l应输出大于 50sudo mysql -u nova -pNOVA_DBPASS nova -e SHOW TABLES; | wc -l应输出大于 80。数字过小说明sync未成功。创建 Nova 服务用户与 endpoint# 加载 admin-openrc source ~/admin-openrc openstack user create --domain default --password-prompt nova # 输入密码NOVA_PASS openstack role add --project service --user nova admin openstack service create --name nova --description OpenStack Compute compute openstack endpoint create --region RegionOne compute public http://controller:8774/v2.1 openstack endpoint create --region RegionOne compute internal http://controller:8774/v2.1 openstack endpoint create --region RegionOne compute admin http://controller:8774/v2.1验证openstack endpoint list | grep nova应输出三行Interface列分别为public、internal、adminURL列均为http://controller:8774/v2.1。这是 Nova 接入 OpenStack 生态的最终确认。4.4 服务启动与状态验证从systemctl到openstack命令的全链路检查4.4.1 创建 systemd 服务文件为nova-api和nova-conductor创建 systemd 服务文件sudo tee /etc/systemd/system/nova-api.service EOF [Unit] DescriptionOpenStack Compute API Server Afternetwork.target [Service] Typenotify Usernova-installer EnvironmentPATH/opt/nova-env/bin:/usr/local/bin:/usr/bin:/bin ExecStart/opt/nova-env/bin/nova-api Restarton-failure RestartSec10 [Install] WantedBymulti-user.target EOF sudo tee /etc/systemd/system/nova-conductor.service EOF [Unit] DescriptionOpenStack Compute Conductor Server Afternetwork.target [Service] Typenotify Usernova-installer EnvironmentPATH/opt/nova-env/bin:/usr/local/bin:/usr/bin:/bin ExecStart/opt/nova-env/bin/nova-conductor Restarton-failure RestartSec10 [Install] WantedBymulti-user.target EOF关键说明Typenotify是为了让nova-api在真正就绪监听 8774 端口后才通知 systemd 服务启动完成避免systemctl start返回成功但服务实际未就绪。Usernova-installer确保服务以非 root 用户运行符合最小权限原则。4.4.2 启动服务并验证重载 systemd 配置并启动服务sudo systemctl daemon-reload sudo systemctl enable nova-api nova-conductor sudo systemctl start nova-api nova-conductor检查服务状态sudo systemctl status nova-api sudo systemctl status nova-conductor正常输出应为active (running)且Loaded行显示loaded (/etc/systemd/system/nova-api.service; enabled; vendor preset: enabled)。如果显示failed立即执行sudo journalctl -u nova-api -f查看实时日志。验证 API 可达性curl -H X-Auth-Token: $(openstack token issue -f value -c id) http://controller:8774/v2.1/os-services # 应返回 JSON 格式的 services 列表包含 binary: nova-scheduler, status: enabled 等字段最终验证openstack compute service list应输出nova-scheduler、nova-conductor、nova-consoleauth等服务状态均为up。至此Nova 控制节点的手动安装宣告完成。5. 常见问题与排查技巧实录那些文档里不会写的坑在多次带领学员实操 Nova 手动安装的过程中我整理出一份“高频问题速查表”。这些问题大多源于配置细节的微小偏差或是对 OpenStack 组件交互逻辑的误解。下面我将按发生频率排序给出精准的定位方法与一击必杀的解决方案。问题现象根本原因快速定位命令一击必杀方案我的实操心得nova-api启动后立即退出journalctl -u nova-api显示ImportError: No module named keystoneauth1pip install openstack-nova未自动安装keystoneauth1依赖或版本不匹配source /opt/nova-env/bin/activate python3 -c import keystoneauth1; print(keystoneauth1.__version__)pip install keystoneauth14.4.0,5.0.0Yoga 兼容版本永远不要相信 pip 的自动依赖解析。Nova 的setup.py中keystoneauth1是4.0.0但 Ubuntu 22.04 的apt源里python3-keystoneauth1是 4.2.0与 Nova 25.2.0 的keystoneauth14.4.0 不兼容必须手动指定范围。openstack compute service list返回空或只显示nova-schedulernova-conductor服务未启动或启动后因数据库连接失败而静默退出sudo systemctl status nova-conductorsudo journalctl -u nova-conductor | grep -A 5 -B 5 ERROR检查/etc/nova/nova.conf中[database]段的connection字符串确认NOVA_DBPASS与 MySQL 创建用户时的密码完全一致包括大小写、特殊字符密码中的符号是最大陷阱。如果NOVA_DBPASS是Pass123connection字符串必须写成mysqlpymysql://nova:Pass%40123controller/nova_api必须 URL 编码为%40否则pymysql会把当作用户名与主机名的分隔符导致连接controller/nova_api失败。nova-api启动后curl http://controller:8774/v2.1返回503 Service Unavailablenova-api成功启动但keystoneauth1插件无法连接 Keystone导致认证失败source /opt/nova-env/bin/activate nova-manage api_db sync看是否报keystoneauth1错误检查/etc/nova/nova.conf中[keystone_authtoken]段的www_authenticate_uri和auth_url是否都为http://controller:5000且memcached_servers地址正确Keystone 的www_authenticate_uri是个“假 URL”。它只用于构造 HTTP 响应头不发起真实请求因此可以是任何合法 URL。但auth_url是真实发起 token 获取请求的地址两者协议、域名、端口必须完全一致否则keystoneauth1会因auth_plugin is None报错。openstack endpoint create报错HTTP 401 Unauthorizedadmin-openrc中的OS_PASSWORD与 Keystone 中admin用户密码不一致或OS_AUTH_URL指向了错误的 Keystone 地址source ~/admin-openrc openstack token issue重新执行openstack user set --password NEW_PASS admin然后更新admin-openrc中的OS_PASSWORDadmin-openrc是一把双刃剑。它极大简化了命令行操作但也掩盖了认证失败的真实原因。当openstack命令报 401 时90% 的情况是admin-openrc配置错误而不是 Nova 本身的问题。建议在实训中先用 curl -X POST http://controller:5000/v3/auth/tokens -H Content-Type