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 分钟拉起全组件PackstackRDO 项目用 Puppet 自动化部署MicroStackCanonical甚至提供了 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 镜像且每个包需提供 SBOMSoftware Bill of Materials清单。DevStack 使用pip install -e githttps://opendev.org/openstack/nova#eggnova直接从 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 官方源码发布流程不依赖任何封装脚本。我们将从 OpenStack 官方 Git 仓库https://opendev.org/openstack/nova拉取指定稳定版本以 Yoga 版本为例tagstable/yoga在干净的 Python venv 中用pip install -e .方式进行开发模式安装-e即 editable mode便于后续调试和 patch所有配置文件nova.conf、policy.json全部手写不拷贝模板每个参数都解释其作用与取值逻辑所有 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-packagesNova 是一个典型的 Python 大型项目依赖超过 200 个第三方包pipdeptree | wc -l实测为 217。如果直接pip install nova会污染系统 Python 环境且与系统包如python3-keystoneclient产生版本冲突。正确做法是创建隔离的 venvsudo 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 时要带上这个 flagpython3 -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 的原子 DDLAtomic DDL能避免 Nova 数据库迁移nova-manage db sync过程中因中断导致的 schema 损坏其caching_sha2_password认证插件与 Nova 的pymysql驱动兼容性最好需在nova.conf中显式设置connection mysqlpymysql://nova:password10.0.0.10/nova?charsetutf8mb4。消息队列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-gaQEMU 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可调试性-eeditable模式安装后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”它会自动安装pymysqlMySQL 驱动和kombuRabbitMQ 驱动避免手动pip install漏掉依赖。注意pip install -e .会执行setup.py其中会调用pbrPython 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_12310.0.0.10:5672/nova # 这是 Nova 服务间通信的 AMQP URL。注意vhost 必须是 /nova不能是 /否则消息路由失败。 auth_strategy keystone # 强制所有 API 请求必须经过 Keystone 认证。设为 noauth 仅用于测试生产环境严禁。 use_neutron True # 必须为 TrueNova 不再管理网络全部交给 Neutron。设为 False 会导致虚拟机无法获取 IP。 firewall_driver nova.virt.firewall.NoopFirewallDriver # 生产环境应使用 IptablesFirewallDriver但首次安装为排除干扰先设为 Noop。 [api_database] # API 数据库连接用于存储 API 请求日志等非核心 connection mysqlpymysql://nova:nova_pass_12310.0.0.10/nova_api?charsetutf8mb4 [database] # 主数据库连接存储虚拟机、配额、主机等核心数据 connection mysqlpymysql://nova:nova_pass_12310.0.0.10/nova?charsetutf8mb4 [keystone_authtoken] # Keystone 认证配置。注意www_authenticate_uri 指向 Keystone Public APIauth_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 是计算节点的管理 IPNova 会告诉 HorizonWeb 控制台用这个 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_typerbd 时生效。这份配置的每一个参数我都经历过血泪教训server_proxyclient_address设错会导致 Horizon 打开控制台时显示“Connection refused”因为浏览器尝试连接的是计算节点的私有 IP而非可路由的管理 IPcpu_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] DescriptionOpenStack Compute Service (nova-compute) Documentationhttps://docs.openstack.org/nova/latest/ Afternetwork.target libvirtd.service Wantslibvirtd.service [Service] Typesimple Usernova Groupnova # 必须指定 User/Group否则以 root 运行有严重安全风险 EnvironmentPATH/opt/stack/nova-venv/bin:/usr/local/bin:/usr/bin:/bin EnvironmentPYTHONPATH/opt/stack/nova # PYTHONPATH 指向 nova 源码根目录确保 import 能找到模块 ExecStart/opt/stack/nova-venv/bin/nova-compute --config-file /etc/nova/nova.conf Restartalways RestartSec10 # RestartSec10 是黄金值。设为 0 会导致频繁重启刷屏设为 60 则故障恢复太慢。 LimitNOFILE65536 # Nova 高并发时会打开大量文件描述符必须提高限制。 [Install] WantedBymulti-user.target关键点解析Afternetwork.target libvirtd.service明确声明启动顺序nova-compute必须在网络和libvirtd启动之后才启动否则会因无法连接qemu:///system而失败Usernova必须创建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/novaExecStart中的路径必须绝对准确/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 driver99% 是libvirt连接问题检查Usernova是否在libvirt组以及libvirtd是否正在运行。5. 服务注册与连通性验证从单点启动到全局可见当nova-compute进程在计算节点上成功运行它还只是“活着”并未真正“上线”。它必须向 OpenStack 的服务目录Service Catalog注册自己让nova-api知道“这里有一个计算节点可以创建虚拟机”。这一步是手动安装中最容易被忽略、也最致命的环节。5.1 向 Keystone 注册 Nova 服务与 EndpointNova 作为一个 OpenStack 服务必须在 Keystone 中注册为一个service并为其创建endpoint服务访问地址。这不能靠nova-compute自动完成必须手动执行openstackCLI 命令。首先你需要一个admin-openrc.sh文件内容如下请替换为你的实际 Keystone 地址和密码export OS_PROJECT_DOMAIN_NAMEDefault export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_NAMEadmin export OS_USERNAMEadmin export OS_PASSWORDadmin_pass_123 export OS_AUTH_URLhttp://10.0.0.10:35357/v3 export OS_IDENTITY_API_VERSION3 export OS_IMAGE_API_VERSION2 export OS_AUTH_TYPEpassword然后加载环境变量并执行注册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% 的连通性问题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 的状态Step 2检查 nova-compute 是否在服务列表中openstack compute service list # 应看到一行nova-compute compute-node-01 nova enabled up 2024-06-15T10:20:30.000000 # 关键字段StatusenabledStateup。若为 down说明 nova-compute 进程已崩溃或未启动。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 已成功连接数据库并查询到主机信息。Step 4手动触发一次虚拟机创建最小化测试# 上传一个 Cirros 镜像轻量级测试镜像 openstack image create cirros --file cirros-0.6.2-x86_64-disk.img --disk-format qcow2 --container-format bare --public # 创建一个
