OpenStack Nova服务端手动安装与配置指南

最新推荐文章于 2026-07-15 15:43:32 发布

原创

最新推荐文章于 2026-07-15 15:43:32 发布 · 401 阅读

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，并在代码中 patch nova/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 完成安装。