1. 项目概述为什么在2024年还要亲手装一遍 NovaNova 是 OpenStack 云平台的“心脏”——它不负责存储数据也不直接处理网络流量但它决定了每一台虚拟机从哪里来、运行在哪台物理服务器上、拥有多少 CPU 和内存、何时启动、何时关机、如何迁移。说白了没有 NovaOpenStack 就是一套漂亮的空壳连最基础的“开一台云主机”都做不到。所以“实训项目六Nova 的手动安装与配置”绝不是一份过时的考卷而是一次对云计算底层调度逻辑的硬核解剖。我带过十几期 OpenStack 实训班每次讲到 Nova 安装环节总有学员嘀咕“现在都用 DevStack 或 Packstack 一键部署了为啥非得手敲命令”我的回答很直接当你用一键脚本三分钟搭好环境却在三天后发现虚拟机无法调度、实例卡在 spawning 状态、日志里满屏No valid host was found时你靠什么排查靠翻 GitHub issue靠重装还是靠真正理解 Nova 的服务拓扑、数据库表结构、消息队列交互机制和配置项之间的因果关系手动安装的过程就是把整个 Compute 服务的“神经脉络”一寸寸摸清楚的过程。它强迫你面对真实世界里的依赖冲突比如 Python 3.9 和 nova-compute 要求的 oslo.utils 版本打架、权限错乱nova 用户没被加进 libvirtd 组导致无法创建 KVM 实例、端口抢占5672 被 RabbitMQ 占了但你误配成 5671、甚至 SELinux 策略拦截这种“看不见的墙”。这些坑脚本会帮你绕过去但不会教你如何识别和修复它们。这个项目的核心关键词是Nova、安装、配置、OpenStack、controller。它面向的不是只想点点鼠标就玩转云平台的初学者而是准备深入云计算运维、私有云架构或 OpenStack 二次开发的工程师。你需要的不是“能跑就行”的结果而是“知道每一步为什么必须这样走”的确定性。接下来的内容我会完全基于一个标准的三节点 OpenStack Train 版本CentOS 8 Stream Python 3.9环境从零开始不跳过任何一个配置项、不省略任何一条校验命令、不回避任何一个实操中踩过的深坑带你把 Nova 在控制节点controller上稳稳地立起来。这不是教程汇编这是我去年在某金融客户现场为他们重建高可用控制平面时亲手执行并反复验证过的完整操作链。2. 整体设计与思路拆解为什么是“手动”又为什么必须是“控制节点”2.1 手动安装的不可替代性从“黑盒”到“白盒”的认知跃迁很多人把“手动安装”误解为“复古行为”其实恰恰相反它是应对复杂生产环境的最高级自动化前置条件。Packstack、DevStack 这类工具的本质是将一套预设的、经过充分测试的“最小可行配置”打包固化。它们在实验室环境里表现完美但一旦进入企业级场景——比如客户要求 Nova 必须使用独立的 PostgreSQL 集群而非默认的 MySQL要求所有 RPC 通信强制 TLS 加密要求每个 nova-conductor 进程绑定到特定 NUMA 节点以优化延迟——这些定制化需求90% 的一键脚本根本无法满足。此时你唯一能依赖的就是对 Nova 各个组件nova-api、nova-scheduler、nova-conductor、nova-novncproxy的职责边界、启动顺序、配置文件路径、日志输出位置的肌肉记忆。手动安装的过程就是在大脑里构建一张完整的 Nova 服务依赖图nova-api启动前必须确保keystone的 token 验证接口可达nova-scheduler必须能通过nova-conductor访问nova数据库的compute_nodes表而nova-novncproxy则必须与nova-consoleauth共享同一个 memcached 实例。这张图是你后续做性能调优、故障定位、安全加固的唯一地图。提示不要试图在第一次手动安装时就追求“完美生产配置”。我的建议是先用最简配置MySQL 单点、RabbitMQ 单点、默认密码跑通全流程再逐项替换为高可用组件。这就像学开车先学会挂挡起步再练漂移。2.2 控制节点Controller的绝对核心地位它不只是“一个节点”在 OpenStack 架构中“controller” 节点常被简化为“放 API 服务的地方”这是巨大的认知偏差。对于 Nova 而言controller 节点是整个计算资源调度的“中央司令部”它集成了四个关键角色API 网关nova-api所有外部请求来自 Horizon、CLI、REST API的唯一入口。它不做实际计算只做鉴权、参数校验、请求路由。调度中枢nova-scheduler当用户发起“创建一台 4C8G 的 Ubuntu 实例”请求时scheduler 是那个真正拍板的人。它从数据库读取所有计算节点的实时资源CPU、内存、磁盘、PCIe 设备根据预设策略如RamFilter、ComputeFilter、AggregateInstanceExtraSpecsFilter筛选出候选节点并最终选择一个最优目标。数据协调员nova-conductor这是 Nova 架构中最容易被忽视、却最关键的组件。它作为nova-compute运行在计算节点上与数据库之间的“隔离墙”。所有涉及数据库写操作如更新实例状态、记录资源用量都必须经由 conductor而不是由 compute 直接操作。这保证了数据库连接池的稳定性和数据一致性避免了 compute 节点因网络抖动导致的数据库连接泄漏。控制台代理nova-novncproxy为用户提供 Web 浏览器访问虚拟机控制台的能力。它本身不渲染画面只是将浏览器的 WebSocket 请求通过nova-consoleauth的 token 验证后透明转发给目标计算节点上的nova-compute进程。这四个服务全部部署在 controller 节点上且彼此之间存在强依赖。nova-api启动失败整个集群对外“失联”nova-scheduler崩溃新实例永远卡在scheduled状态nova-conductor挂掉所有正在创建/删除的实例都会陷入“僵尸”状态nova-novncproxy不可用则用户无法通过 Horizon 连接控制台。因此controller 节点的稳定性直接决定了 Nova 服务的 SLA。手动安装就是要你亲手把这四根“承重柱”一根一根、严丝合缝地立稳。2.3 技术栈选型的深层逻辑为什么是 CentOS 8 Stream Train当前网络热词里频繁出现 “openstack train 三节点部署”、“centos6.5安装openstack脚本”这恰恰反映了两个极端一个是过度追逐新版本另一个是困守陈旧系统。我们选择 CentOS 8 Stream而非已停止维护的 CentOS 7和 OpenStack Train2020 年发布的稳定版但仍是目前企业私有云部署的主流选择是基于三个硬性原则长期支持LTS与社区活跃度的平衡Train 版本虽非最新但其对应的 python-novaclient、python-openstackclient 等 SDK 依然在主流发行版仓库中稳定更新且大量企业级文档、排障指南、Ansible Role 都基于此版本。而更新的 Wallaby 或 Xena 版本在某些硬件驱动如 NVIDIA GPU 直通的兼容性上反而更不稳定。Python 生态的成熟度CentOS 8 Stream 默认提供 Python 3.6完美匹配 Train 版本对 Python 3 的强制要求。相比之下CentOS 7 的 Python 2.7 已被官方弃用强行升级会引发pip、setuptools等基础工具的连锁崩溃。安全基线的可控性CentOS 8 Stream 的内核4.18和 SELinux 策略对容器化、KVM 虚拟化等现代云原生技术提供了更完善的支持。我们在某政务云项目中就遇到过CentOS 7 上的旧内核无法正确识别 NVMe SSD 的多队列特性导致 Nova 调度时误判磁盘 IOPS造成实例性能严重抖动。所以这个选择不是“凑合”而是经过数十个真实项目验证后的“最优解”。3. 核心细节解析与实操要点配置文件、权限、SELinux一个都不能少3.1 配置文件的“黄金三角”nova.conf、policy.json 与 api-paste.iniNova 的配置远不止一个nova.conf。真正的配置体系是一个“黄金三角”三者缺一不可且职责分明。nova.conf这是 Nova 的“主脑”定义了所有服务的全局参数。它被划分为多个 section如[DEFAULT]通用设置、[api]API 服务特有、[database]数据库连接、[oslo_messaging_rabbit]消息队列、[glance]镜像服务对接等。每一个 section 下的 key-value 对都直接影响服务的行为。例如[DEFAULT] use_neutron True这一行决定了 Nova 是使用老的nova-network还是与 Neutron 集成而[oslo_messaging_rabbit] rabbit_ha_queues true则开启了 RabbitMQ 的高可用队列这是生产环境的必备项。policy.json这是 Nova 的“宪法”定义了谁Role能在什么条件下Context对哪些资源Target执行什么操作Action。它不是简单的“允许/拒绝”而是精细的 RBAC基于角色的访问控制。例如os_compute_api:servers:create: rule:admin_or_owner这条规则意味着只有管理员admin或该服务器的拥有者owner才能创建新实例。如果你在 Horizon 上看到“创建实例”按钮是灰色的第一反应不应该是检查网络而是立刻grep servers:create /etc/nova/policy.json确认这条规则是否被意外修改。api-paste.ini这是 Nova 的“门禁系统”定义了 HTTP 请求进入nova-api服务后的处理流水线Pipeline。一个典型的 pipeline 可能是pipeline cors http_proxy_to_wsgi faultwrap authcontext keystonecontext osprofiler noauth2 request_id catch_errors sizelimit param_encryption json_body xml_body ec2_extension v3_extension versions. 每一个 filter如keystonecontext、authcontext都是一个中间件负责完成鉴权、上下文注入、错误捕获等任务。如果某个 filter 配置错误比如keystonecontext的auth_uri指向了错误的 Keystone 地址那么所有 API 请求都会在到达业务逻辑前就被拦截返回401 Unauthorized而日志里可能只有一行模糊的Failed to fetch token。注意这三个文件的修改顺序有严格要求。必须先确保nova.conf中的数据库、消息队列、Keystone 等基础连接配置无误再调整policy.json的权限策略最后才去动api-paste.ini的 pipeline。我曾在一个项目中因为先改了policy.json把admin_required改成了rule:admin_api但nova.conf里auth_strategy keystone还没配结果整个 API 服务启动后直接拒绝所有请求排查了整整一天。3.2 权限与用户nova 用户、libvirtd 组与数据库权限的铁三角OpenStack 的安全模型建立在严格的 Linux 用户隔离之上。Nova 的核心进程nova-api、nova-scheduler等默认以nova用户身份运行而不是root。这意味着任何需要操作系统级资源的操作都必须提前为nova用户授权。nova用户与libvirtd组这是 Nova 能否成功创建虚拟机的生死线。nova-compute在计算节点需要调用libvirtAPI 来管理 KVM/QEMU而libvirtd守护进程默认只允许root和libvirtd组内的用户进行连接。因此在 controller 节点上虽然nova-compute不运行但nova-api在处理某些请求如获取虚拟机列表时也会间接调用libvirt。所以nova用户必须被加入libvirtd组usermod -a -G libvirtd nova。漏掉这一步你会在/var/log/nova/nova-api.log里看到大量libvirtError: authentication failed的报错。数据库权限不仅仅是CREATE DATABASE创建nova_api、nova两个数据库只是第一步。更重要的是要为nova数据库用户授予精确的、最小化的权限。正确的 SQL 命令是CREATE DATABASE nova_api CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE DATABASE nova CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; 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; FLUSH PRIVILEGES;关键点在于nova_api和nova是两个独立的数据库分别存储 API 相关元数据如 flavor、image 的缓存和核心业务数据如 instance、compute_node。很多新手会错误地只创建一个nova数据库或者忘记给%主机授权导致计算节点无法连接。文件所有权与 SELinux 上下文在 CentOS 8 上/etc/nova/目录及其下的所有配置文件必须属于nova:nova用户组。chown -R nova:nova /etc/nova/是必须执行的命令。此外SELinux 的安全策略会阻止nova-api进程读取/etc/nova/nova.conf除非你为其打上正确的上下文标签semanage fcontext -a -t etc_t /etc/nova(/.*)? restorecon -Rv /etc/nova/。忽略 SELinux是 CentOS 环境下 Nova 启动失败的头号原因。3.3 日志与调试/var/log/nova/目录下的“福尔摩斯笔记”Nova 的日志系统是排障的终极武器。/var/log/nova/目录下每个服务都有独立的日志文件nova-api.log、nova-scheduler.log、nova-conductor.log、nova-novncproxy.log。但仅仅看日志还不够必须掌握三个核心技巧日志级别动态调整默认日志级别是INFO信息量巨大但关键错误容易被淹没。在排障时可以临时将nova.conf中的log_level DEBUG然后重启对应服务。但切记DEBUG 级别会产生海量日志仅用于短时间诊断问题解决后务必改回INFO或WARNING否则磁盘会被迅速占满。关联 IDRequest ID追踪当一个 API 请求如POST /servers发出后nova-api.log会生成一个唯一的req-xxxxxID。这个 ID 会贯穿整个请求生命周期出现在nova-scheduler.log、nova-conductor.log甚至计算节点的nova-compute.log中。使用grep req-xxxxx /var/log/nova/*.log就能把一次请求的完整调用链串起来这是定位跨服务问题的黄金法则。nova-manage工具的深度使用nova-manage是 Nova 的瑞士军刀。除了常见的db sync同步数据库表结构它还有几个鲜为人知但极其强大的子命令nova-manage service list列出所有注册的服务及其状态up/down、最后心跳时间。这是判断nova-scheduler是否真的在运行的最直接方式。nova-manage db archive_deleted_rows清理instances表中已删除的旧记录防止数据库膨胀。生产环境应定期执行。nova-manage cell_v2 discover_hosts在启用 Cell V2多区域架构时用于自动发现并注册新的计算节点。这是大规模部署的必备技能。4. 实操过程与核心环节实现从零开始一步一验4.1 环境准备与基础依赖安装在开始安装 Nova 之前必须确保 controller 节点的基础环境已经就绪。这不是可选项而是所有后续步骤的基石。首先确认系统版本和内核cat /etc/redhat-release # 应输出CentOS Stream release 8 uname -r # 应输出4.18.0-xxx.el8.x86_64 或更高然后启用 OpenStack Train 的官方仓库。CentOS 8 Stream 默认不包含 OpenStack 包必须手动添加# 安装 EPEL 和 OpenStack 仓库 dnf install -y epel-release dnf install -y centos-release-openstack-train # 禁用所有其他 OpenStack 仓库只保留 train dnf config-manager --disable \*openstack\* dnf config-manager --enable openstack-train # 更新系统并重启确保新内核生效 dnf update -y reboot接着安装基础依赖。这里有一个极易被忽略的坑python3-pip和python3-setuptools的版本。OpenStack Train 要求pip 20.0而 CentOS 8 Stream 默认的pip版本是 9.x。因此必须强制升级dnf install -y python3-pip python3-setuptools python3-devel gcc libffi-devel openssl-devel pip3 install --upgrade pip setuptools # 验证 pip3 --version # 输出应为pip 21.3.1 or higher最后安装数据库MySQL和消息队列RabbitMQ。虽然网络热词里有mysql安装配置教程但在这里我们必须采用 OpenStack 推荐的、经过充分测试的配置# 安装 MySQL dnf install -y mariadb mariadb-server python3-PyMySQL # 启动并设置开机自启 systemctl enable mariadb.service systemctl start mariadb.service # 运行安全初始化脚本设置 root 密码、删除匿名用户等 mysql_secure_installation # 创建 Nova 数据库用户此处使用 NOVA_DBPASS 作为密码占位符请替换为你的强密码 mysql -u root -p CREATE DATABASE nova_api CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE DATABASE nova CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; 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; FLUSH PRIVILEGES; exit安装 RabbitMQdnf install -y rabbitmq-server systemctl enable rabbitmq-server.service systemctl start rabbitmq-server.service # 创建 nova 用户并设置权限 rabbitmqctl add_user openstack RABBIT_PASS rabbitmqctl set_permissions openstack .* .* .* # 启用管理插件方便后续监控 rabbitmq-plugins enable rabbitmq_management实操心得在mysql_secure_installation步骤中一定要选择Y删除匿名用户和禁止 root 远程登录。我见过太多次因为没删匿名用户导致 Nova 服务启动时数据库连接被匿名用户劫持报出Access denied for user novalocalhost的诡异错误。4.2 Nova 服务安装与核心配置现在终于到了安装 Nova 服务本身的时候。在 CentOS 8 Stream 上所有 Nova 组件都打包在openstack-nova-api、openstack-nova-scheduler等 RPM 包中dnf install -y openstack-nova-api openstack-nova-scheduler openstack-nova-conductor openstack-nova-novncproxy安装完成后最关键的一步是生成初始的nova.conf配置文件。OpenStack 官方文档推荐使用crudini工具来编辑因为它能保证 INI 文件的格式绝对正确避免手工编辑时因空格、缩进而导致的解析失败# 备份原始配置 cp /etc/nova/nova.conf /etc/nova/nova.conf.bak # 清空配置文件 /etc/nova/nova.conf # 使用 crudini 逐项写入配置 crudini --set /etc/nova/nova.conf DEFAULT transport_url rabbit://openstack:RABBIT_PASScontroller:5672/ crudini --set /etc/nova/nova.conf DEFAULT my_ip 10.0.0.11 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 database connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova crudini --set /etc/nova/nova.conf api_database connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova_api # Keystone 认证 crudini --set /etc/nova/nova.conf api auth_strategy keystone crudini --set /etc/nova/nova.conf keystone_authtoken www_authenticate_uri https://controller:5000/ crudini --set /etc/nova/nova.conf keystone_authtoken auth_url https://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 https://controller:9292 # Nova-NVNCProxy 配置 crudini --set /etc/nova/nova.conf vnc enabled true crudini --set /etc/nova/nova.conf vnc server_listen \$my_ip crudini --set /etc/nova/nova.conf vnc server_proxyclient_address \$my_ip # 时区与日志 crudini --set /etc/nova/nova.conf DEFAULT log_dir /var/log/nova crudini --set /etc/nova/nova.conf DEFAULT default_log_levels amqpWARNING,amqplibWARNING,botoINFO,qpidINFO,sqlalchemyINFO,sudsINFO,iso8601INFO,requests.packages.urllib3.connectionpoolWARNING,urllib3.connectionpoolWARNING,websocketINFO,requests.packages.urllib3.util.retryWARNING,urllib3.util.retryWARNING,keystonemiddleware.auth_tokenINFO,oslo.messagingINFO,oslo_messagingINFO,oslo_serializationINFO,oslo_serviceINFO,oslo_utilsINFO,oslo_configINFO,oslo_policyINFO,oslo_dbINFO,oslo_concurrencyINFO,oslo_i18nINFO,oslo_contextINFO,oslo_cacheINFO,oslo_limitINFO,oslo_middlewareINFO,oslo_versionedobjectsINFO,oslo_upgradecheckINFO,oslo_rootwrapINFO,oslo_privsepINFO,oslo_reportsINFO,oslo_metricsINFO,oslo_messaging_rabbitINFO,oslo_messaging_kafkaINFO,oslo_messaging_zmqINFO,oslo_messaging_notificationsINFO,oslo_messaging_notifyINFO,oslo_messaging_rpcINFO,oslo_messaging_transportINFO,oslo_messaging_driversINFO,oslo_messaging_drivers_rabbitINFO,oslo_messaging_drivers_kafkaINFO,oslo_messaging_drivers_zmqINFO,oslo_messaging_drivers_notificationsINFO,oslo_messaging_drivers_notifyINFO,oslo_messaging_drivers_rpcINFO,oslo_messaging_drivers_transportINFO,oslo_messaging_drivers_driversINFO,oslo_messaging_drivers_drivers_rabbitINFO,oslo_messaging_drivers_drivers_kafkaINFO,oslo_messaging_drivers_drivers_zmqINFO,oslo_messaging_drivers_drivers_notificationsINFO,oslo_messaging_drivers_drivers_notifyINFO,oslo_messaging_drivers_drivers_rpcINFO,oslo_messaging_drivers_drivers_transportINFO上面这段crudini命令看似枯燥但每一行都对应着 Nova 运行的一个关键开关。例如firewall_driver设置为NoopFirewallDriver是因为在生产环境中防火墙策略通常由 Neutron 统一管理Nova 自身的 iptables 驱动反而会造成冲突。而default_log_levels的长列表则是为了抑制那些无意义的 INFO 级别日志让真正的错误信息更容易被发现。4.3 数据库同步与服务启动配置文件写完下一步就是让 Nova 知道它的“大脑”数据库长什么样。这通过nova-manage工具完成# 同步 nova_api 数据库 su -s /bin/sh -c nova-manage api_db sync nova # 同步 nova 数据库 su -s /bin/sh -c nova-manage db sync nova这两条命令会根据 Nova 的 SQLAlchemy 模型自动在数据库中创建所有必需的表。api_db sync创建的是nova_api数据库中的表如flavors、images而db sync创建的是nova数据库中的核心表如instances、compute_nodes、migrations。如果执行失败最常见的原因是数据库连接字符串错误或者nova用户没有足够的权限。同步成功后就可以启动 Nova 的各个服务了。注意启动顺序很重要# 启动 nova-api所有服务的入口 systemctl enable openstack-nova-api.service systemctl start openstack-nova-api.service # 启动 nova-scheduler必须在 api 之后因为它需要从 api 获取配置 systemctl enable openstack-nova-scheduler.service systemctl start openstack-nova-scheduler.service # 启动 nova-conductor同样依赖于 api 的配置 systemctl enable openstack-nova-conductor.service systemctl start openstack-nova-conductor.service # 启动 nova-novncproxy需要先有 nova-api 和 nova-conductor systemctl enable openstack-nova-novncproxy.service systemctl start openstack-nova-novncproxy.service启动完成后必须立即进行验证。最简单有效的方式是检查服务状态和监听端口# 检查所有 nova 服务是否为 active (running) systemctl list-units | grep nova # 检查 8774 端口nova-api是否在监听 ss -tlnp | grep 8774 # 检查 8775 端口nova-scheduler 的内部健康检查端口是否在监听 ss -tlnp | grep 8775 # 检查 6080 端口nova-novncproxy是否在监听 ss -tlnp | grep 6080如果一切正常你应该能看到类似这样的输出tcp LISTEN 0 128 *:8774 *:* users:((nova-api,pid12345,fd5)) tcp LISTEN 0 128 *:8775 *:* users:((nova-scheduler,pid12346,fd5)) tcp LISTEN 0 128 *:6080 *:* users:((nova-novncproxy,pid12347,fd5))4.4 最终验证与功能测试服务跑起来了不代表它就能工作。最后一步是用 OpenStack CLI 进行端到端的功能测试。这需要先配置好admin-openrc.sh环境变量文件cat admin-openrc.sh EOF export OS_PROJECT_DOMAIN_NAMEDefault export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_NAMEadmin export OS_USERNAMEadmin export OS_PASSWORDADMIN_PASS export OS_AUTH_URLhttps://controller:5000/v3 export OS_IDENTITY_API_VERSION3 export OS_IMAGE_API_VERSION2 export OS_CACERT/etc/ssl/certs/ca-bundle.crt EOF source admin-openrc.sh然后执行一系列关键命令# 1. 列出所有 Nova 服务确认它们的状态是 up openstack compute service list # 期望输出所有 nova-* 服务的 State 列为 up # 2. 列出所有可用的 Flavor虚拟机规格确认 nova-api 能正确访问数据库 openstack flavor list # 期望输出至少能看到 m1.tiny, m1.small 等默认规格 # 3. 查看 Nova 的端点Endpoint确认它已正确注册到 Keystone openstack catalog show compute # 期望输出包含 public, internal, admin 三个 URL且都指向 controller 的 8774 端口 # 4. 可选但强烈推荐尝试创建一个最小化的实例这是终极考验 # 首先确保你已经上传了一个镜像如 cirros openstack image list # 然后创建一个网络和子网假设你已配置好 Neutron openstack network create --share --external --provider-physical-network provider --provider-network-type flat provider openstack subnet create --network provider --allocation-pool start10.0.0.100,end10.0.0.200 --dns-nameserver 8.8.8.8 --gateway 10.0.0.1 --subnet-range 10.0.0.0/24 provider-v4 # 最后创建实例 openstack server create --flavor m1.tiny --image cirros --nic net-idPROVIDER_NET_ID --security-group default test-instance # 观察实例状态 openstack server list # 期望输出test-instance 的 Status 从 BUILD 变为 ACTIVE如果openstack compute service list显示所有服务都是up并且openstack flavor list能成功返回结果那么恭喜你Nova 的手动安装与配置已经成功完成了 90%。剩下的server create测试更多是验证整个 OpenStack 生态Neutron、Glance、Keystone的集成是否顺畅。5. 常见问题与排查技巧实录那些让你抓狂的“幽灵错误”5.1 问题速查表高频故障与一招毙命解决方案问题现象根本原因一招毙命解决方案验证命令openstack compute service list显示nova-scheduler状态为downnova-scheduler进程未启动或启动后因配置错误立即崩溃journalctl -u openstack-nova-scheduler -f查看实时日志90% 的情况是keystone_authtoken配置中的auth_url或password错误systemctl restart openstack-nova-scheduler journalctl -u openstack-nova-scheduler -n 50 -fnova-api.log中反复出现ConnectionRefusedError: [Errno 111] Connection refusednova-api无法连接到 RabbitMQ 消息队列检查nova.conf中的transport_url是否指向了正确的 controller 主机名和端口5672并确认rabbitmq-server服务正在运行ss -tlnp | grep 5672 ping controlleropenstack flavor list返回HTTP 401 Unauthorizednova-api无法通过 Keystone 进行身份验证检查nova.conf中[keystone_authtoken]段的auth_url、username、password、project_name是否与 Keystone 中创建的nova用户信息完全一致openstack --os-username nova --os-password NOVA_PASS --os-project-name service --os-auth-url https://controller:5000/v3 token issuenova-manage db sync报错ModuleNotFoundError: No module named pymysqlPython 环境中缺少PyMySQL驱动pip3 install PyMySQL并确保nova用户也能访问到该包sudo -u nova pip3 install PyMySQLsudo -u nova python3 -c import pymysql; print(pymysql.__version__)nova-novncproxy启动后Horizon 控制台页面显示 Unable to establish