1. Nova 是什么？先别急着装，搞清它在技术栈里的真实位置

很多人看到“Nova 的手动安装与配置”这个标题，第一反应是：又一个要配环境的工具？点开就搜“Nova 安装包下载”，然后一路 next、next、finish，最后发现命令行敲nova --version报错，或者nova list返回Unauthorized，再翻文档发现满屏都是 OpenStack、Keystone、Glance……一头雾水。这不怪你——问题出在起点就错了：你根本没确认自己要装的 Nova 到底是哪一个。

Nova 这个名字，在当前技术生态里至少对应三个完全不兼容的实体：

• OpenStack Nova：这是最正统、最重量级的 Nova，是 OpenStack 云计算平台的核心计算服务组件，负责虚拟机生命周期管理（创建、调度、销毁）、与 Hypervisor（如 KVM、Xen）交互、对接网络和存储后端。它不是独立运行的“软件”，而是一套由数十个 Python 服务进程（nova-api、nova-scheduler、nova-compute 等）组成的分布式系统，依赖完整的 OpenStack 基础设施（MySQL/PostgreSQL、RabbitMQ/Kafka、Keystone 认证、Glance 镜像服务、Neutron 网络服务）。它的安装不是“装一个程序”，而是部署一个云操作系统的核心引擎。

• Nova CLI（或 Nova Client）：这是 OpenStack 官方提供的命令行客户端工具，功能单一，只负责向已存在的 OpenStack Nova API 发送 REST 请求。它本身不包含任何业务逻辑，不依赖数据库或消息队列，就是一个 Python 包（python-openstackclient或旧版python-novaclient），通过pip install python-openstackclient即可完成安装。它的配置文件（clouds.yaml或openrc.sh）里填的是你所在 OpenStack 云的地址、项目名、用户名和密码——它自己不提供服务，只消费服务。

• 第三方同名工具（如某些前端构建工具、CLI 工具链中的 Nova 模块）：搜索热词里混入了大量无关内容（codex安装、claude code安装、ccswitch windows 安装），说明很多用户其实是被搜索引擎误导，把其他项目的关键词和 Nova 错配了。比如某款叫 Nova 的 VS Code 主题、某个内部代号为 Nova 的私有 DevOps 脚本、甚至某家公司的内部 API 网关代号，都可能被简称为 “Nova”。它们和 OpenStack 毫无关系，安装方式也千差万别。

提示：如果你是在公司内网看到“请安装 Nova”这条指令，但没人给你提供 OpenStack 环境地址、租户信息或管理员权限，请立刻确认——你大概率需要的只是nova client，而不是去部署一整套 OpenStack 云平台。后者动辄需要 3 台以上物理服务器、数小时配置时间、以及对 Linux 网络、SELinux、Python 包管理的深度理解。而前者，5 分钟就能搞定。

我第一次接触 Nova 是在一家做私有云交付的公司，客户要求“在测试环境装 Nova”。我们团队按 OpenStack 官方文档从头部署，搭完 nova-api、nova-scheduler、nova-conductor，结果发现客户真正想要的，只是让运维同事能用命令行查一下他们已有的虚拟机列表。我们白干了两天，最后删掉所有服务，只留一个pip install python-openstackclient和一份openrc.sh就解决了问题。这个教训让我明白：“安装 Nova” 这个动作本身没有意义，关键是你想用它来解决什么问题、对接哪个系统、扮演什么角色。

所以，本文接下来的所有操作，将严格基于一个前提：你明确知道自己需要的是OpenStack Nova 服务端（即计算节点核心服务）的手动部署与配置，并且你已具备以下基础条件：

• 一台运行 Ubuntu 22.04 或 CentOS Stream 9 的物理机或虚拟机（推荐最小 4C8G，磁盘 100GB+）；
• 该机器已接入一个可用的 OpenStack 环境（至少已部署好 Keystone、Glance、Neutron 控制节点）；
• 你拥有该 OpenStack 环境的管理员凭据（用于注册 nova 服务、创建 endpoint）；
• 你熟悉 Linux 基础命令（systemctl、journalctl、grep、vim）、Python 包管理（pip、venv）及 MySQL 基本操作。

如果你的需求是“只想用命令行管理 OpenStack 虚拟机”，那么请直接跳到本文末尾的“附录：仅安装 Nova Client 的极简路径”，那里有 3 行命令就能跑通的方案。本文主体，只服务于真正要亲手把 Nova 服务跑起来的工程师。

2. 手动安装的本质：为什么不用 DevStack 或 Packstack？

在 OpenStack 社区，“手动安装”这个词本身就带着一种近乎悲壮的仪式感。因为绝大多数人根本不会手动装——DevStack（一键脚本）5 分钟拉起全组件；Packstack（RDO 项目）用 Puppet 自动化部署；MicroStack（Canonical）甚至提供了 snap 包，snap install microstack就能本地跑通。那为什么还要手动？

答案很现实：可控性、可调试性、可复现性，三者缺一不可。

我参与过三个不同规模的 OpenStack 项目交付，每一次手动安装 Nova 都不是为了“炫技”，而是为了解决自动化工具无法覆盖的硬需求：

• 定制化日志与监控埋点：某金融客户要求所有 nova-api 请求必须打上业务线标签，并写入自研的 ELK 日志平台。DevStack 默认的日志格式和输出路径无法满足，必须修改nova.conf中的[DEFAULT] log_config_append指向自定义 logging.conf，并在代码中 patchnova/api/openstack/wsgi.py注入 header 解析逻辑。这种深度定制，只有手动解压源码、修改配置、重新打包才能实现。

• 内核模块与驱动适配：某边缘计算场景使用 ARM64 架构的国产服务器，其 GPU 直通（PCIe Passthrough）需要特定版本的 vfio-pci 内核模块和自定义 IOMMU 分组策略。Packstack 默认安装的 nova-compute 会因内核模块加载失败而崩溃，我们必须手动编译匹配的内核、禁用默认的modprobe vfio-pci服务、编写 systemd drop-in 文件强制加载顺序，再启动 nova-compute。

• 安全合规审计要求：某政务云项目要求所有 Python 依赖必须来自内部 PyPI 镜像，且每个包需提供 SBOM（Software Bill of Materials）清单。DevStack 使用pip install -e git+https://opendev.org/openstack/nova#egg=nova直接从 Git 拉取，无法满足离线审计。我们必须手动 clone 源码、用pip-tools生成requirements.txt、逐个pip wheel下载 wheel 包、校验 SHA256、上传至内部仓库，最后用pip install --find-links file:///internal/pypi --trusted-host internal.pypi --no-index nova完成安装。

手动安装的“手动”，本质是把每一个隐式依赖、每一处默认配置、每一次自动决策，都暴露在你的眼皮底下，让你能精确控制每一个字节的流向。它不是反自动化，而是自动化之前的必经之路——就像学开车先练手动挡，不是为了永远不开自动挡，而是为了真正理解动力如何传递。

因此，本文的“手动安装”，将严格遵循 OpenStack 官方源码发布流程，不依赖任何封装脚本。我们将：

1. 从 OpenStack 官方 Git 仓库（https://opendev.org/openstack/nova）拉取指定稳定版本（以 Yoga 版本为例，tagstable/yoga）；
2. 在干净的 Python venv 中，用pip install -e .方式进行开发模式安装（-e即 editable mode，便于后续调试和 patch）；
3. 所有配置文件（nova.conf、policy.json）全部手写，不拷贝模板，每个参数都解释其作用与取值逻辑；
4. 所有 systemd 服务单元文件（nova-api.service、nova-compute.service）全部手写，明确声明依赖关系、启动顺序、资源限制。

这不是最省事的路，但它是唯一能让你在生产环境出问题时，不靠 Google、不靠 StackOverflow，自己看日志、改代码、半小时内定位根因的路。

3. 从零开始：环境准备与依赖解析的硬核细节

手动安装 Nova 的第一步，不是下载代码，而是把地基夯得比混凝土还硬。很多人的安装失败，90% 都卡在这一步——不是 Nova 本身的问题，而是底层环境的“隐形坑”没填平。下面是我踩过、修过、验证过的完整清单，按执行顺序排列，每一步都附带“为什么必须这样”的原理说明。

3.1 操作系统与内核：Ubuntu 22.04 LTS 是当前最稳选择

我们选择 Ubuntu 22.04（代号 Jammy），而非更新的 24.04 或更老的 20.04，原因如下：

• Python 版本兼容性：Nova Yoga 版本官方支持 Python 3.8–3.10。Ubuntu 22.04 自带 Python 3.10.6，完美匹配。Ubuntu 24.04 自带 Python 3.12，而 Nova Yoga 尚未通过 3.12 全面测试（部分单元测试会因 asyncio 行为变更而失败）；Ubuntu 20.04 自带 Python 3.8.10，虽可用，但其 OpenSSL 版本（1.1.1f）已不被现代 TLS 1.3 服务端完全信任，可能导致 nova-api 与 Keystone 通信异常。

• 内核稳定性：Ubuntu 22.04 默认内核为 5.15.x，这是一个长期支持（LTS）内核，对 KVM、VFIO、cgroups v2 的支持成熟稳定。我们曾在线上环境用过 6.1.x 内核，结果 nova-compute 在高并发创建虚拟机时出现qemu-kvm: unable to map guest memory错误，回退到 5.15.0-107-generic 后问题消失。这不是 Nova 的 bug，而是新内核中 mm 子系统的一次优化引入了竞态条件，需要上游补丁。

• 包管理一致性：Ubuntu 的apt仓库对 OpenStack 依赖包（如 libvirt、qemu-kvm、dnsmasq）的版本锁定非常严格。例如，libvirt-daemon-system在 22.04 中固定为 8.0.0，而该版本与 Nova Yoga 的nova.virt.libvirt.driver模块经过充分互测。若强行升级到 9.x，则libvirt.open的 API 签名变更会导致 nova-compute 启动即崩溃。

注意：执行前请确保系统已更新至最新状态：

sudo apt update && sudo apt full-upgrade -y sudo reboot

这一步不能省。我见过太多因为linux-image-generic内核未更新，导致vfio-pci模块无法加载的案例。

3.2 Python 环境：必须用 venv，且必须指定 --system-site-packages

Nova 是一个典型的 Python 大型项目，依赖超过 200 个第三方包（pipdeptree | wc -l实测为 217）。如果直接pip install nova，会污染系统 Python 环境，且与系统包（如python3-keystoneclient）产生版本冲突。正确做法是创建隔离的 venv：

sudo apt install python3-venv python3-dev libffi-dev libssl-dev -y python3 -m venv /opt/stack/nova-venv source /opt/stack/nova-venv/bin/activate

但这里有个关键细节：必须启用--system-site-packages。为什么？

因为 Nova 的底层驱动（尤其是nova.virt.libvirt）严重依赖系统级 C 库，如libvirt.so、libxml2.so、libcurl.so。这些库的 Python 绑定（libvirt-python、lxml、pycurl）如果只从 PyPI 安装纯 Python 版本，性能会断崖式下跌（XML 解析慢 5 倍，libvirt 连接建立耗时增加 300ms）。Ubuntu 的apt包python3-libvirt、python3-lxml、python3-pycurl是编译链接到系统库的二进制包，性能最优。

所以，我们创建 venv 时要带上这个 flag：

python3 -m venv --system-site-packages /opt/stack/nova-venv

然后，在激活 venv 后，先pip install --upgrade pip setuptools wheel，再安装 Nova。这样，pip会优先使用系统已安装的高性能二进制包，只从 PyPI 下载那些没有系统包替代的纯 Python 依赖（如oslo.config、keystoneauth1）。

3.3 数据库与消息队列：MySQL 8.0 + RabbitMQ 3.11 是黄金组合

Nova 需要两个外部服务：

• 数据库：存储虚拟机元数据、配额、实例状态等。官方支持 MySQL、PostgreSQL、SQLite（仅测试用）。生产环境必须用 MySQL 或 PostgreSQL。我们选 MySQL 8.0，因为：

  • Ubuntu 22.04 的mysql-server包默认就是 8.0.33，无需额外源；
  • MySQL 8.0 的原子 DDL（Atomic DDL）能避免 Nova 数据库迁移（nova-manage db sync）过程中因中断导致的 schema 损坏；
  • 其caching_sha2_password认证插件与 Nova 的pymysql驱动兼容性最好（需在nova.conf中显式设置connection = mysql+pymysql://nova:password@10.0.0.10/nova?charset=utf8mb4）。

• 消息队列：Nova 各服务间（如 nova-api → nova-scheduler → nova-conductor → nova-compute）通过 AMQP 协议异步通信。官方支持 RabbitMQ、Kafka、Zaqar。我们选 RabbitMQ 3.11，因为：

  • Ubuntu 22.04 的rabbitmq-server包是 3.11.11，与 Nova Yoga 的kombu5.2.x 完全兼容；
  • 其quorum queues（仲裁队列）能提供强一致性，避免消息丢失（nova-scheduler发给nova-conductor的请求若丢失，会导致虚拟机创建卡死）；
  • 配置简单：只需rabbitmq-plugins enable rabbitmq_management开启 Web 管理界面，即可实时监控队列长度、消费者连接数。

安装命令如下（假设数据库和 MQ 服务已部署在10.0.0.10）：

# 创建 Nova 数据库和用户（在 MySQL 服务器上执行） mysql -u root -p -e "CREATE DATABASE nova CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" mysql -u root -p -e "GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'%' IDENTIFIED BY 'nova_pass_123'; FLUSH PRIVILEGES;" # 创建 RabbitMQ 用户和 vhost（在 RabbitMQ 服务器上执行） sudo rabbitmqctl add_user nova nova_pass_123 sudo rabbitmqctl add_vhost /nova sudo rabbitmqctl set_permissions -p /nova nova ".*" ".*" ".*"

注意：nova_pass_123是示例密码，请务必替换为符合复杂度要求的强密码（至少 12 位，含大小写字母、数字、符号）。Nova 的数据库密码一旦写入nova.conf，就成为整个云平台的安全边界，绝不能用弱口令。

3.4 Libvirt 与 QEMU：虚拟化层的硬核选型

Nova 本身不创建虚拟机，它只是一个“调度器”和“协调者”，真正的虚拟机创建由libvirt完成，而libvirt又调用qemu-kvm执行。因此，libvirt 和 QEMU 的版本选择，直接决定 Nova 的稳定性和功能上限。

• Libvirt 版本：必须 ≥ 8.0.0。低于此版本不支持virtiofs（高速虚拟机文件共享）、nvme设备直通等现代特性。Ubuntu 22.04 的libvirt-daemon-system正好是 8.0.0，完美。

• QEMU 版本：必须 ≥ 6.2.0。这是第一个正式支持qemu-ga（QEMU Guest Agent）热升级的版本，能让 Nova 在不重启虚拟机的情况下动态调整 CPU、内存。Ubuntu 22.04 的qemu-kvm是 6.2.0，达标。

安装命令：

sudo apt install qemu-kvm libvirt-daemon-system virtinst virt-manager -y sudo systemctl enable libvirtd sudo systemctl start libvirtd

关键验证步骤（必须执行）：

# 检查 libvirt 是否能连接本地 hypervisor sudo virsh -c qemu:///system list --all # 检查 KVM 内核模块是否加载 lsmod | grep kvm # 检查 CPU 是否支持硬件虚拟化（Intel VT-x 或 AMD-V） egrep -c '(vmx|svm)' /proc/cpuinfo # 输出应为 > 0

如果virsh list报错Failed to connect to the hypervisor，大概率是libvirtd服务未启动，或当前用户不在libvirt用户组。执行：

sudo usermod -a -G libvirt $(whoami) sudo usermod -a -G kvm $(whoami) newgrp libvirt # 刷新组权限

这一步看似简单，却是后续nova-compute启动失败的最高发原因。我统计过，线上 67% 的nova-compute启动失败，根源都在libvirtd服务状态或用户组权限上。

4. 源码编译与服务注册：从 Git 到 systemd 的完整链路

现在，地基已打好，我们进入真正的“手动安装”核心环节：获取源码、编译安装、配置服务、注册到 OpenStack。这一步，我们将彻底抛弃所有“一键脚本”，用最原始的方式，把 Nova 的每一个齿轮都亲手拧紧。

4.1 拉取并安装 Nova 源码：为什么必须用-e模式？

OpenStack 官方发布流程是：源码托管在 https://opendev.org/openstack/nova，每个稳定版本（如 Yoga）会打一个stable/yogatag。我们不下载 tar.gz 包，而是用git clone，原因有三：

• 可追溯性：git log -n 5 --oneline可以清晰看到最近 5 次提交，包括关键 Bug 修复（如Fix instance resize failure on UEFI boot）；
• 可 patch 性：如果遇到未合入主干的紧急修复，可以直接git cherry-pick <commit-hash>；
• 可调试性：-e（editable）模式安装后，Python 的import nova会直接指向你本地的nova/目录，pdb.set_trace()打断点后，IDE（如 VS Code）能直接跳转到源码行，而不是.pyc编译文件。

执行命令：

cd /opt/stack sudo git clone https://opendev.org/openstack/nova.git cd nova sudo git checkout stable/yoga

验证 tag 是否正确：

git describe --tags # 应输出类似：33.2.0-12-gabcdef123

然后，在已激活的 venv 中，执行开发模式安装：

source /opt/stack/nova-venv/bin/activate pip install -e ".[mysql, rabbitmq]"

[mysql, rabbitmq]是 Nova 的“extra dependencies”，它会自动安装pymysql（MySQL 驱动）和kombu（RabbitMQ 驱动），避免手动pip install漏掉依赖。

注意：pip install -e .会执行setup.py，其中会调用pbr（Python Build Reasonableness）工具生成nova.egg-info/元数据目录。这个目录里包含了entry_points.txt，定义了nova-api、nova-scheduler等命令行入口。如果这一步失败，99% 是 Python 版本或依赖包版本不匹配，此时应检查pip list输出，对比 OpenStack Requirements 中的约束版本。

4.2 手写 nova.conf：每个参数都是一个故事

nova.conf是 Nova 的心脏，它不是一个简单的配置文件，而是一份“系统契约”，规定了 Nova 如何与 Keystone 认证、如何连接数据库、如何调度虚拟机、如何与 libvirt 交互。网上流传的“通用 nova.conf 模板”几乎全是毒药，因为每个参数的取值，都取决于你的硬件、网络、安全策略。

我们以一个典型的计算节点（Compute Node）配置为例，逐段解析：

[DEFAULT] # 基础标识 transport_url = rabbit://nova:nova_pass_123@10.0.0.10:5672/nova # 这是 Nova 服务间通信的 AMQP URL。注意：vhost 必须是 /nova，不能是 /，否则消息路由失败。 auth_strategy = keystone # 强制所有 API 请求必须经过 Keystone 认证。设为 noauth 仅用于测试，生产环境严禁。 use_neutron = True # 必须为 True！Nova 不再管理网络，全部交给 Neutron。设为 False 会导致虚拟机无法获取 IP。 firewall_driver = nova.virt.firewall.NoopFirewallDriver # 生产环境应使用 IptablesFirewallDriver，但首次安装为排除干扰，先设为 Noop。 [api_database] # API 数据库连接（用于存储 API 请求日志等，非核心） connection = mysql+pymysql://nova:nova_pass_123@10.0.0.10/nova_api?charset=utf8mb4 [database] # 主数据库连接（存储虚拟机、配额、主机等核心数据） connection = mysql+pymysql://nova:nova_pass_123@10.0.0.10/nova?charset=utf8mb4 [keystone_authtoken] # Keystone 认证配置。注意：www_authenticate_uri 指向 Keystone Public API，auth_url 指向 Admin API。 www_authenticate_uri = http://10.0.0.10:5000 auth_url = http://10.0.0.10:35357 memcached_servers = 10.0.0.10:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = nova password = nova_pass_123 # 这里的 nova 用户，必须已在 Keystone 中创建，并赋予 admin 角色到 service project。 [vnc] # VNC 控制台配置。如果使用 SPICE，此处应改为 [spice]。 enabled = True server_listen = 0.0.0.0 server_proxyclient_address = 10.0.0.20 # server_proxyclient_address 是计算节点的管理 IP，Nova 会告诉 Horizon（Web 控制台）用这个 IP 去连 VNC。 novncproxy_base_url = http://10.0.0.10:6080/vnc_auto.html # novncproxy_base_url 是 nova-novncproxy 服务的地址，通常和 Keystone 在同一台控制节点。 [glance] # Glance 镜像服务配置。 api_servers = http://10.0.0.10:9292 [oslo_concurrency] # 锁管理，防止并发操作损坏数据。 lock_path = /var/lib/nova/tmp [libvirt] # 最关键的虚拟化配置！ virt_type = kvm # 必须是 kvm，不能是 qemu（性能差 3 倍以上）。 cpu_mode = host-passthrough # 将宿主机 CPU 特性完全透传给虚拟机，保证性能最大化。host-model 是安全降级选项。 images_type = rbd # 如果使用 Ceph 存储，设为 rbd；如果使用本地磁盘，设为 default。 images_rbd_pool = vms # Ceph pool 名称，仅当 images_type=rbd 时生效。

这份配置的每一个参数，我都经历过血泪教训：

• server_proxyclient_address设错，会导致 Horizon 打开控制台时显示“Connection refused”，因为浏览器尝试连接的是计算节点的私有 IP，而非可路由的管理 IP；
• cpu_mode = host-passthrough在某些老旧 CPU 上会触发libvirt错误，必须降级为host-model，但降级后虚拟机无法使用 AVX-512 指令集；
• images_type = rbd时，若images_rbd_pool不存在，nova-compute启动会卡在Waiting for ceph cluster to be ready...，日志里没有任何错误提示，只能ceph -s查看集群状态。

提示：配置文件写完后，务必用nova-manage db sync初始化数据库。这会执行所有 SQL migration 脚本，创建表结构。如果报错，90% 是数据库连接参数错误，或 MySQL 用户权限不足（缺少CREATE、ALTER权限）。

4.3 systemd 服务单元：让 Nova 真正“活”起来

pip install -e .只是把代码装进了 Python 环境，nova.conf只是定义了规则，真正让 Nova 服务跑起来的，是 systemd。OpenStack 官方不提供 systemd unit 文件，因为部署方式太碎片化（有人用 Docker，有人用 Podman，有人用裸 metal）。我们必须手写。

以nova-compute.service为例（计算节点核心服务）：

[Unit] Description=OpenStack Compute Service (nova-compute) Documentation=https://docs.openstack.org/nova/latest/ After=network.target libvirtd.service Wants=libvirtd.service [Service] Type=simple User=nova Group=nova # 必须指定 User/Group，否则以 root 运行有严重安全风险 Environment=PATH=/opt/stack/nova-venv/bin:/usr/local/bin:/usr/bin:/bin Environment=PYTHONPATH=/opt/stack/nova # PYTHONPATH 指向 nova 源码根目录，确保 import 能找到模块 ExecStart=/opt/stack/nova-venv/bin/nova-compute --config-file /etc/nova/nova.conf Restart=always RestartSec=10 # RestartSec=10 是黄金值。设为 0 会导致频繁重启刷屏；设为 60 则故障恢复太慢。 LimitNOFILE=65536 # Nova 高并发时会打开大量文件描述符，必须提高限制。 [Install] WantedBy=multi-user.target

关键点解析：

• After=network.target libvirtd.service：明确声明启动顺序，nova-compute必须在网络和libvirtd启动之后才启动，否则会因无法连接qemu:///system而失败；
• User=nova：必须创建nova系统用户，并将其加入libvirt和kvm组：

  sudo useradd -r -g nova -d /var/lib/nova -s /bin/false nova sudo usermod -a -G libvirt,kvm nova sudo mkdir -p /var/lib/nova /etc/nova sudo chown -R nova:nova /var/lib/nova /etc/nova

• ExecStart中的路径必须绝对准确：/opt/stack/nova-venv/bin/nova-compute是 venv 中的可执行脚本，它会自动加载 venv 的 Python 解释器和依赖。

将上述内容保存为/etc/systemd/system/nova-compute.service，然后：

sudo systemctl daemon-reload sudo systemctl enable nova-compute sudo systemctl start nova-compute

验证是否成功：

sudo systemctl status nova-compute # 应显示 active (running) sudo journalctl -u nova-compute -f --since "1 minute ago" # 实时查看日志，应看到 "Starting compute manager"、"Found X compute nodes" 等字样

如果journalctl显示ERROR nova.compute.manager [None] Failed to initialize driver，99% 是libvirt连接问题，检查User=nova是否在libvirt组，以及libvirtd是否正在运行。

5. 服务注册与连通性验证：从单点启动到全局可见

当nova-compute进程在计算节点上成功运行，它还只是“活着”，并未真正“上线”。它必须向 OpenStack 的服务目录（Service Catalog）注册自己，让nova-api知道“这里有一个计算节点可以创建虚拟机”。这一步，是手动安装中最容易被忽略、也最致命的环节。

5.1 向 Keystone 注册 Nova 服务与 Endpoint

Nova 作为一个 OpenStack 服务，必须在 Keystone 中注册为一个service，并为其创建endpoint（服务访问地址）。这不能靠nova-compute自动完成，必须手动执行openstackCLI 命令。

首先，你需要一个admin-openrc.sh文件，内容如下（请替换为你的实际 Keystone 地址和密码）：

export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=admin_pass_123 export OS_AUTH_URL=http://10.0.0.10:35357/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 export OS_AUTH_TYPE=password

然后，加载环境变量并执行注册：

source admin-openrc.sh # 1. 创建 nova service openstack service create --name nova --description "OpenStack Compute" compute # 2. 创建 public、internal、admin 三个 endpoint openstack endpoint create --region RegionOne compute public http://10.0.0.10:8774/v2.1/%\(tenant_id\)s openstack endpoint create --region RegionOne compute internal http://10.0.0.10:8774/v2.1/%\(tenant_id\)s openstack endpoint create --region RegionOne compute admin http://10.0.0.10:8774/v2.1/%\(tenant_id\)s

注意：http://10.0.0.10:8774是nova-api服务的监听地址，不是nova-compute的地址。nova-compute是 worker，不对外提供 HTTP 接口。

5.2 在 Keystone 中创建 nova 用户并授权

nova-compute服务需要一个 Keystone 用户，用于向nova-api、keystone、glance等服务发起认证请求。这个用户必须属于serviceproject，并拥有admin角色。

# 创建 service project（如果尚不存在） openstack project create --domain default --description "Service Project" service # 创建 nova 用户 openstack user create --domain default --password-prompt nova # 输入密码：nova_pass_123 # 将 nova 用户添加到 service project，并赋予 admin 角色 openstack role add --project service --user nova admin

这一步完成后，nova.conf中的[keystone_authtoken]配置才真正生效。如果跳过此步，nova-compute启动时会反复报错Authorization failed: The request you have made requires authentication.，因为它无法通过 Keystone 认证。

5.3 连通性终极验证：五步法排查

当所有服务都启动、所有注册都完成，最后一步是验证整个链路是否真正打通。我总结了一套“五步法”，能在 5 分钟内定位 95% 的连通性问题：

1. Step 1：检查 nova-api 是否响应

   curl -H "X-Auth-Token: $(openstack token issue -f value -c id)" http://10.0.0.10:8774/v2.1/os-services # 应返回 JSON 格式的 services 列表，包含 nova-compute 的状态

2. Step 2：检查 nova-compute 是否在服务列表中

   openstack compute service list # 应看到一行：nova-compute compute-node-01 nova enabled up 2024-06-15T10:20:30.000000 # 关键字段：Status=enabled，State=up。若为 down，说明 nova-compute 进程已崩溃或未启动。

3. Step 3：检查 nova-compute 日志中的关键线索

   sudo journalctl -u nova-compute -n 50 | grep -E "(ERROR|WARNING|INFO.*Found)" # 正常启动的最后一行应是：INFO nova.compute.manager [None] Found 0 compute nodes # 如果是 "Found 0"，说明 nova-compute 已成功连接数据库并查询到主机信息。

4. Step 4：手动触发一次虚拟机创建（最小化测试）

   # 上传一个 Cirros 镜像（轻量级测试镜像） openstack image create "cirros" --file cirros-0.6.2-x86_64-disk.img --disk-format qcow2 --container-format bare --public # 创建一个