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

1. 项目概述：为什么在2024年还要亲手装 Nova？

Nova 是 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_PASS@controller是否被正确解析的人，在遇到 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 Administrator（OCOA），或者刚接手一个遗留的 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 第二步：基础服务就位——数据库与消息队列为何必须先于 Nova？

Nova 的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能看到三条有效 endpoint（public,internal,admin），才算真正打通了 Nova 的任督二脉。

3. 核心细节解析与实操要点：配置文件里的魔鬼细节

Nova 的配置看似只是修改nova.conf，实则暗藏数十处影响系统行为的“魔鬼参数”。这些参数不写在官方快速入门指南里，却在生产环境中决定着集群的稳定性与可维护性。下面我将逐个拆解最常被忽略、却又最致命的五个配置项，并说明它们背后的原理与实操选择依据。

3.1[DEFAULT] use_neutron = True：为什么必须显式关闭 Nova-network？

OpenStack 早已废弃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 = mysql+pymysql://nova:NOVA_DBPASS@controller/nova_api：为什么用pymysql而非mysqldb？

Nova 的数据库驱动默认是mysql://，这会调用MySQLdb库。但MySQLdb是 C 扩展，编译依赖python-dev和libmysqlclient-dev，在 Ubuntu 22.04 上安装极其繁琐，且与 Python 3.10 的兼容性极差。而pymysql是纯 Python 实现，pip install pymysql即可，无编译依赖。更重要的是，pymysql支持连接池自动回收、SQL 注入防护、字符集自动协商等高级特性。因此，我强制将数据库连接字符串改为mysql+pymysql://，并在[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 = controller，nova-api启动时会报TypeError: expected string or bytes-like object，因为底层oslo_messaging期望接收一个可迭代对象。更隐蔽的坑是：rabbit_hosts的端口必须显式写出，不能省略。controller默认解析为controller:5672，但rabbitmq服务实际监听的是5672（AMQP）和15672（Management UI），nova只认5672。因此，必须写死controller:5672，而不是controller或controller:15672。这个细节在日志里几乎不体现，只能靠对 RabbitMQ 协议的理解来规避。

3.4[keystone_authtoken] www_authenticate_uri = http://controller:5000：为什么www_authenticate_uri和auth_url必须指向同一地址？

[keystone_authtoken]段有两个关键 URL：www_authenticate_uri（用于生成 WWW-Authenticate 头）和auth_url（用于获取 token）。在单节点部署中，两者都应指向http://controller:5000。但如果www_authenticate_uri错误地指向了https://controller:5000（启用了 HTTPS），而auth_url仍是http://controller:5000，nova-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已被标记为 deprecated，FakeScheduler仅用于单元测试。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 虚拟机（4C8G，50G 磁盘）上实测通过，步骤间有强依赖关系，严禁跳步。我会在每个关键命令后解释其作用、常见报错及验证方法，让你不仅知道“怎么做”，更明白“为什么这么做”。

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 'nova'@'localhost' IDENTIFIED BY 'NOVA_DBPASS'; GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'%' IDENTIFIED BY 'NOVA_DBPASS'; GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY 'NOVA_DBPASS'; GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY 'NOVA_DBPASS'; GRANT ALL PRIVILEGES ON nova_cell0.* TO 'nova'@'localhost' 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 配置

安装并启动 RabbitMQ：

sudo 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应输出/nova；sudo 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 虚拟环境并安装 Nova

python3 -m venv /opt/nova-env source /opt/nova-env/bin/activate pip install --upgrade pip pip install "openstack-nova==25.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_PASS@controller: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 mysql+pymysql://nova:NOVA_DBPASS@controller/nova_api crudini --set /etc/nova/nova.conf database connection mysql+pymysql://nova:NOVA_DBPASS@controller/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应输出大于 50；sudo 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、admin，URL列均为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] Description=OpenStack Compute API Server After=network.target [Service] Type=notify User=nova-installer Environment=PATH="/opt/nova-env/bin:/usr/local/bin:/usr/bin:/bin" ExecStart=/opt/nova-env/bin/nova-api Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target EOF sudo tee /etc/systemd/system/nova-conductor.service << 'EOF' [Unit] Description=OpenStack Compute Conductor Server After=network.target [Service] Type=notify User=nova-installer Environment=PATH="/opt/nova-env/bin:/usr/local/bin:/usr/bin:/bin" ExecStart=/opt/nova-env/bin/nova-conductor Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target EOF

关键说明：Type=notify是为了让nova-api在真正就绪（监听 8774 端口）后才通知 systemd 服务启动完成，避免systemctl start返回成功但服务实际未就绪。User=nova-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 组件交互逻辑的误解。下面我将按发生频率排序，给出精准的定位方法与一击必杀的解决方案。