1. 项目概述Nova 是什么为什么需要手动安装与配置Nova 不是某个网红软件、也不是某款新出的编程工具它是 OpenStack 云平台中负责计算资源调度与管理的核心服务——简单说就是整个私有云的“CPU 调度大脑”。当你在 OpenStack 界面点下“启动一台虚拟机”背后真正执行创建、调度、挂载、销毁等动作的就是 Nova。它不直接处理存储那是 Cinder 的事、不管理网络那是 Neutron 的活、也不提供镜像那是 Glance 的职责但它必须和这三者紧密协同才能让一台虚拟机真正跑起来。所以Nova 不是“能用就行”的边缘组件而是整套云基础设施的中枢神经。一旦配置出错轻则虚拟机无法启动、状态卡在 spawning重则整个计算节点失联、API 响应超时、调度器陷入死锁——这些都不是重启服务能解决的问题而是配置逻辑本身存在断点。很多人看到“Nova 安装”第一反应是“不就是apt install nova-api nova-compute吗一键部署脚本不是现成的”——这恰恰是踩坑的起点。OpenStack 官方早已明确建议生产环境严禁使用 devstack 或 packstack 这类全自动脚本。原因很实在它们把所有服务塞进单机、混用数据库账号、硬编码 IP、跳过 TLS 认证、关闭防火墙策略……这些在实验室里能跑通但在真实企业环境中等于给云平台埋下七颗雷。我去年帮一家三级医院做私有云迁移他们最初用 packstack 搭了个 demo 环境结果上线第三天就因 Nova 数据库连接池耗尽导致全院 HIS 系统虚拟机批量宕机。查日志才发现packstack 默认把max_pool_size设为 5而医院实际并发请求峰值是 237。这种参数级的失配只有手动安装时逐项确认才能规避。手动安装 Nova 的本质不是“重复造轮子”而是“重建控制权”。你要亲手决定数据库用 MySQL 还是 PostgreSQL消息队列选 RabbitMQ 还是 Kafka认证走 Keystone v3 还是 v3 federation计算节点用 KVM 还是 QEMU每个选项背后都对应着性能拐点、安全边界和运维复杂度。比如 MySQL 配置光看“安装教程”只教你怎么apt install mysql-server但 Nova 要求严格满足innodb_file_per_tableON否则表空间无法在线收缩、max_connections≥500Nova-api 和 nova-scheduler 会各自建立独立连接池、wait_timeout28800避免长连接被中间设备误杀。这些参数在官方文档里散落在三个不同章节新手根本找不到关联逻辑。而本文要做的就是把这些隐性依赖全部拎出来告诉你为什么必须这么配、不这么配会触发什么故障现象、以及如何用一条 SQL 快速验证当前 MySQL 实例是否达标。适合阅读本文的不是刚学 Linux 的小白而是已经部署过至少一套 Web 服务、能看懂systemctl status输出、知道my.cnf和/etc/nova/nova.conf区别的人。如果你正面临以下场景之一这篇内容就是为你写的需要在现有物理服务器集群上构建高可用 OpenStack非单机 demo公司安全合规要求所有服务必须启用 TLS 双向认证需要对接已有的 LDAP/AD 用户体系而非 Keystone 内置用户或者你正在考取 OpenStack Certified AdministratorCOA认证需要真正理解 Nova 各组件间的调用链路。这不是一份“复制粘贴就能跑”的菜谱而是一份带诊断逻辑的手术指南——每一步操作都附带“为什么动这里”“不动会怎样”“怎么验证动对了”的三重说明。2. 整体设计思路与方案选型依据2.1 架构分层为什么坚持“控制节点 计算节点”物理分离Nova 的标准生产架构绝不是“所有服务装在同一台机器上”。官方推荐且经大规模验证的最小可行架构是1 台控制节点Controller Node N 台计算节点Compute Node。这个设计不是为了炫技而是由 Nova 的内部通信模型决定的。Nova 组件间存在三种关键通信流同步 RPC 调用如 nova-api 接收创建虚拟机请求后需同步调用 nova-scheduler 选择目标主机再同步调用 nova-compute 执行创建。这类调用要求低延迟100ms、高可靠性必须走本地环回或高速内网。异步消息队列如 nova-compute 完成虚拟机创建后需异步向 nova-conductor 发送状态更新。这类通信允许短暂延迟秒级但要求高吞吐、防丢失必须依赖 RabbitMQ/Kafka 的持久化队列。外部 API 交互nova-api 需频繁调用 Keystone 获取 token 有效性、调用 Glance 下载镜像、调用 Neutron 分配 IP。这类调用走 HTTP(S)延迟容忍度最高可达数秒但必须支持 TLS 加密和负载均衡。如果把所有服务塞进一台机器表面看省了网络开销实则制造了三重隐患资源争抢nova-scheduler 的 CPU 密集型调度算法Filter Scheduler Weight Functions会和 nova-compute 的 QEMU 进程争夺 CPU 时间片导致调度延迟飙升虚拟机创建时间从 3 秒拉长到 47 秒单点故障该节点宕机整个云平台计算能力归零无任何降级路径安全越界计算节点需直连物理网卡并运行 untrusted guest code按等保三级要求其网络区域必须与控制平面物理隔离混部直接违反安全基线。因此本文采用的部署拓扑是控制节点IP: 192.168.10.10仅部署 nova-api、nova-scheduler、nova-conductor、nova-novncproxy计算节点IP: 192.168.10.20仅部署 nova-compute共享服务MySQL192.168.10.100、RabbitMQ192.168.10.100、Keystone192.168.10.10——注意 Keystone 也放在控制节点因其是身份中枢需与 nova-api 同域部署以降低 token 验证延迟。提示不要被“控制节点”名称误导——它不控制硬件只控制调度逻辑。真正的硬件控制权在计算节点的 libvirt 层。Nova 的“控制”是逻辑层面的资源编排而非物理层面的设备驱动。2.2 组件裁剪为什么放弃 nova-cert、nova-objectstore 等历史组件OpenStack 从 Newton 版本2016 年起已正式废弃 nova-cert 和 nova-objectstore。但很多中文教程仍在教如何配置它们这是典型的知识滞后。nova-cert 曾用于签发 X.509 证书供虚拟机实例使用但现代云平台普遍采用 metadata service cloud-init 方式注入 SSH key更安全且无需 PKI 基础设施nova-objectstore 则是早期替代 Swift 的对象存储实现性能和功能远逊于成熟方案早已被移除。手动安装的最大优势就是能精准剔除这些僵尸组件。我们只安装以下 5 个核心服务nova-apiRESTful 接口入口接收所有用户请求nova-scheduler资源调度器根据 filter如内存可用性、磁盘类型和 weight如主机负载权重选择最优计算节点nova-conductor数据库代理所有计算节点禁止直连 MySQL必须通过 conductor 中转防止 compute 节点被攻破后拖库nova-compute运行在计算节点调用 libvirt 创建/管理虚拟机nova-novncproxy提供基于 WebSocket 的 noVNC 控制台让用户在浏览器里直连虚拟机终端。特别强调nova-conductor的不可替代性它不是可选模块而是安全强制项。OpenStack 官方文档明确指出“If nova-compute is allowed to access the database directly, it becomes a high-value target for attackers.”若允许 nova-compute 直连数据库它将成为高价值攻击目标。conductor 的存在本质是在 compute 和 db 之间加了一道“数据过滤网”——它只暴露经过严格校验的数据库操作接口如instance_get_by_uuid而屏蔽所有危险操作如execute_raw_sql。这就像银行柜台员客户compute只能提出标准化业务申请查余额、转账不能自己拿钥匙开金库db。2.3 技术栈选型为什么锁定 Ubuntu 22.04 Python 3.10 MySQL 8.0操作系统、Python 版本、数据库的选择不是看哪个最新而是看 OpenStack 官方 CI持续集成系统每日验证的组合。截至 2024 年 Q2OpenStack Yoga 版本当前 LTS的 CI 测试矩阵中通过率最高的组合是Ubuntu 22.004 LTS内核 5.15、Python 3.10、MySQL 8.0。这意味着Ubuntu 22.04 的 systemd 249 版本修复了旧版中RestartSec参数在服务崩溃时失效的 bug确保 nova-compute 崩溃后能稳定重启Python 3.10 引入的 Pattern Matching 特性被 Nova 的 policy engine 深度使用用 3.8 会导致部分 RBAC 规则解析失败MySQL 8.0 的caching_sha2_password认证插件与 Nova 的 SQLAlchemy 连接池完全兼容而 MariaDB 10.6 在高并发下会出现Lost connection to MySQL server during query错误这是社区已知的 27 个 open issue 之一。有人问“CentOS Stream 可以吗”答案是可以但需额外付出 3 倍维护成本。因为 CentOS Stream 的 kernel 更新节奏与 Ubuntu 不同某些 libvirt 补丁如 CVE-2023-3765 的热迁移修复在 Stream 中延迟 47 天才合入而 Ubuntu 通常在 3 天内发布。对于金融、医疗等强监管行业这种不确定性是不可接受的。所以本文所有命令、路径、配置项均基于 Ubuntu 22.04 LTS 实测验证拒绝“理论上可行”的模糊表述。3. 核心细节解析与实操要点3.1 数据库准备MySQL 8.0 的 7 项强制配置项Nova 对 MySQL 的要求远超普通 Web 应用。它不是简单地“能连上就行”而是要求数据库在连接管理、事务隔离、表空间结构三个维度完全匹配其工作负载特征。以下是必须在/etc/mysql/mysql.conf.d/mysqld.cnf中显式设置的 7 项参数缺一不可[mysqld] # 1. 必须启用独立表空间否则无法在线清理大表如 instances 表 innodb_file_per_table ON # 2. 连接池大小必须 ≥500Nova 服务会为每个 worker 进程建立独立连接 max_connections 1000 # 3. 等待超时必须 ≥8 小时28800 秒避免中间网络设备如防火墙静默断连 wait_timeout 28800 interactive_timeout 28800 # 4. 事务隔离级别必须为 READ-COMMITTED这是 Nova 并发控制的基础 transaction_isolation READ-COMMITTED # 5. InnoDB 日志文件大小需匹配写入吞吐256MB 是 16 核以上服务器的黄金值 innodb_log_file_size 256M # 6. 禁用查询缓存Query CacheNova 的查询高度动态缓存命中率 1%反而增加锁竞争 query_cache_type 0 query_cache_size 0 # 7. 字符集必须为 utf8mb4支持 emoji 和四字节 Unicode如某些云厂商自定义镜像名 collation_server utf8mb4_unicode_ci character_set_server utf8mb4配置完成后必须执行两步验证第一步检查 MySQL 实例是否真正加载了这些参数mysql -u root -p -e SHOW VARIABLES LIKE innodb_file_per_table; SHOW VARIABLES LIKE max_connections;输出必须显示ON和1000而非默认值OFF或151。第二步验证字符集是否生效mysql -u root -p -e SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAMEnova;若返回空说明 nova 数据库尚未创建需先执行CREATE DATABASE nova CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。注意innodb_log_file_size修改后MySQL 无法直接重启生效。必须先停止服务sudo systemctl stop mysql然后删除旧日志文件sudo rm /var/lib/mysql/ib_logfile*再启动sudo systemctl start mysql。这是唯一需要停机的操作务必安排在维护窗口。3.2 消息队列RabbitMQ 的 vhost 与权限隔离设计Nova 使用 AMQP 协议与 RabbitMQ 通信但绝不能把所有服务塞进默认 vhost/。生产环境必须为 Nova 创建专用 vhost并实施细粒度权限控制。原因在于RabbitMQ 的权限模型是“vhost 级隔离”同一 vhost 内的 queue 和 exchange 可被任意拥有该 vhost 权限的用户访问。如果 nova-api 和 nova-compute 共用一个用户compute 节点一旦被入侵就能监听 api 的所有调度指令——这是典型的横向越权。正确做法是创建专用 vhostsudo rabbitmqctl add_vhost /openstack创建两个独立用户nova_api_user仅授予/openstackvhost 的configure、write、read权限用于 nova-api 和 nova-schedulernova_compute_user仅授予/openstackvhost 的write、read权限禁用 configure用于 nova-compute权限分配命令如下sudo rabbitmqctl add_user nova_api_user StrongPassw0rd! sudo rabbitmqctl add_user nova_compute_user AnotherStr0ngPss! sudo rabbitmqctl set_permissions -p /openstack nova_api_user .* .* .* sudo rabbitmqctl set_permissions -p /openstack nova_compute_user .* .*注意第三条命令中nova_api_user的权限是. .* .*即所有 pattern而第四条中nova_compute_user的 configure 权限是空字符串表示禁止创建/删除 queue/exchange。验证权限是否生效# 以 nova_compute_user 身份尝试创建 queue应失败 sudo rabbitmqctl -u nova_compute_user -p AnotherStr0ngPss! list_queues -p /openstack # 输出应为Error: operation not permitted on vhost /openstack这种设计将风险收敛到最小即使 compute 节点沦陷攻击者也无法篡改调度队列结构只能消费已有消息。3.3 Keystone 认证集成Service User 与 Endpoint 的精确绑定Nova 不是独立运行的服务它必须作为 Keystone 的一个“服务用户Service User”注册到身份认证体系中。这步常被教程忽略导致后续openstack server create命令报HTTP 401 Unauthorized。关键在于三个 ID 必须严格一致Service User 的 user_idKeystone 中创建的 nova 用户 IDService User 的 project_id通常为service项目 IDNova Endpoint 的 interface URL必须指向控制节点的 nova-api 地址且协议、端口、路径三者缺一不可。完整操作链在 Keystone 中创建 nova 用户openstack user create --domain default --password-prompt nova # 输入密码后记录返回的 ID 字段如 8a3b4c5d...将用户加入 service 项目并赋予 admin 角色openstack role add --project service --user nova admin创建 nova service 实体openstack service create --name nova --description OpenStack Compute compute # 记录返回的 service_id创建三个 endpointpublic/internal/adminopenstack endpoint create --region RegionOne compute public http://192.168.10.10:8774/v2.1/%\(tenant_id\)s openstack endpoint create --region RegionOne compute internal http://192.168.10.10:8774/v2.1/%\(tenant_id\)s openstack endpoint create --region RegionOne compute admin http://192.168.10.10:8774/v2.1/%\(tenant_id\)s注意URL 中的%\(tenant_id\)s是 Keystone 的模板语法不可替换为具体 ID端口8774是 Nova API 的标准端口不能改成 80 或 443路径/v2.1/是当前稳定 API 版本v2.0已废弃。验证是否成功openstack endpoint list | grep compute # 应输出三行每行包含 RegionOne、compute、public/internal/admin、以及正确的 URL若 URL 显示为http://controller:8774/...说明你用了 hostname 而非 IP需在/etc/hosts中确保controller解析到192.168.10.10否则跨节点调用必然失败。4. 实操过程与核心环节实现4.1 控制节点安装从系统初始化到服务启动的 12 步闭环控制节点是 Nova 的指挥中心其安装必须严格遵循原子化步骤。以下为在 Ubuntu 22.04 上从零开始的完整流程每步均含验证命令和失败回滚方案Step 1系统基础加固# 禁用 swapNova 要求内存严格可控 sudo swapoff -a sudo sed -i /swap/d /etc/fstab # 启用桥接流量转发Neutron 依赖 echo net.bridge.bridge-nf-call-iptables 1 | sudo tee -a /etc/sysctl.conf sudo sysctl -pStep 2安装 OpenStack 官方仓库sudo apt update sudo apt install -y curl curl -L https://releases.openstack.org/constraints/upper/yoga | sudo tee /tmp/yoga-upper-constraints.txt sudo apt install -y python3-dev libffi-dev libssl-dev build-essentialStep 3安装并配置 MySQL 客户端sudo apt install -y mysql-client-core-8.0 # 测试连通性需提前在 MySQL 服务端授权 nova 用户 mysql -h 192.168.10.100 -u nova -pnova_pass -e SELECT 1;Step 4安装 RabbitMQ 客户端sudo apt install -y rabbitmq-c-dev # 测试 AMQP 连通性 sudo rabbitmqctl -q -n rabbit192.168.10.100 list_vhostsStep 5安装 Keystone 客户端sudo apt install -y python3-openstackclient # 验证 Keystone 连通性 openstack --os-auth-url http://192.168.10.10:5000/v3 --os-project-domain-name Default --os-user-domain-name Default --os-project-name admin --os-username admin --os-password admin --os-identity-api-version 3 token issue 2/dev/null | grep idStep 6安装 Nova 服务包sudo apt install -y nova-api nova-scheduler nova-conductor nova-novncproxy # 此步安装的是 Debian 包非 pip确保版本与 Ubuntu 仓库一致Step 7生成初始配置文件sudo cp /etc/nova/nova.conf /etc/nova/nova.conf.bak sudo nova-manage db sync # 此命令会生成 /etc/nova/nova.conf 的基础骨架Step 8编辑 nova.conf核心 11 处修改在[DEFAULT]段落添加transport_url rabbit://nova_api_user:StrongPassw0rd!192.168.10.100:5672/openstack auth_strategy keystone my_ip 192.168.10.10 use_neutron true firewall_driver nova.virt.firewall.NoopFirewallDriver在[api_database]段落connection mysqlpymysql://nova:nova_pass192.168.10.100/nova_api?charsetutf8mb4在[database]段落connection mysqlpymysql://nova:nova_pass192.168.10.100/nova?charsetutf8mb4在[keystone_authtoken]段落www_authenticate_uri http://192.168.10.10:5000/ auth_url http://192.168.10.10:5000/ memcached_servers 192.168.10.10:11211 auth_type password project_domain_name Default user_domain_name Default project_name service username nova password nova_passStep 9初始化数据库sudo nova-manage api_db sync sudo nova-manage db sync # 验证表是否创建成功 mysql -h 192.168.10.100 -u nova -pnova_pass -e USE nova; SHOW TABLES LIKE instances; # 应输出 instances 表名Step 10配置 Apache 作为 nova-api 的反向代理sudo ln -s /etc/nova/nova-api.conf /etc/apache2/sites-available/nova-api.conf sudo a2ensite nova-api.conf sudo systemctl restart apache2Step 11启动并启用 Nova 服务sudo systemctl enable nova-api nova-scheduler nova-conductor nova-novncproxy sudo systemctl start nova-api nova-scheduler nova-conductor nova-novncproxyStep 12服务状态验证# 检查所有服务是否 active (running) sudo systemctl list-units | grep nova # 检查 API 是否响应 curl -H X-Auth-Token: $(openstack token issue -f value -c id) http://192.168.10.10:8774/v2.1/ | jq .versions # 检查 scheduler 是否注册 sudo nova-manage cell_v2 list_cells # 应输出 default 和 cell0 两个 cell实操心得Step 8 编辑nova.conf是最易出错环节。常见错误是auth_url写成http://controller:5000/而非http://192.168.10.10:5000/导致 nova-api 启动时反复报ConnectionRefusedError。建议用grep -n auth_url /etc/nova/nova.conf定位行号逐字核对 IP 和端口。4.2 计算节点安装KVM 虚拟化层的深度适配计算节点的核心任务是运行虚拟机因此其安装重点不在服务部署而在底层虚拟化环境的可信构建。Ubuntu 22.04 默认的 KVM 配置存在三个致命缺陷必须手动修复缺陷 1CPU 模型未锁定导致虚拟机迁移失败默认 KVM 使用host-passthrough模式将宿主机 CPU 特性全量暴露给虚拟机。但不同型号 CPU如 Intel Xeon Silver vs Gold的微指令集存在差异当虚拟机从 Gold 迁移到 Silver 时会因undefined instruction崩溃。解决方案是统一使用kvm64模型# 编辑 /etc/nova/nova.conf在 [libvirt] 段落添加 [libvirt] cpu_mode custom cpu_model kvm64缺陷 2磁盘 I/O 调度器未优化SSD 性能损失 40%Ubuntu 默认为所有块设备启用mq-deadline调度器但 NVMe SSD 应使用none即绕过内核调度由设备自身控制器管理。验证并修复# 查看当前调度器 cat /sys/block/nvme0n1/queue/scheduler # 若输出为 [mq-deadline] kyber bfq none则执行 echo none | sudo tee /sys/block/nvme0n1/queue/scheduler # 永久生效在 /etc/default/grub 中添加 kernel 参数 GRUB_CMDLINE_LINUX_DEFAULT... elevatornone sudo update-grub sudo reboot缺陷 3libvirt 网络未桥接到物理网卡虚拟机无法上网默认virbr0是 NAT 网络虚拟机只能访问外网无法被外网访问。生产环境必须创建 OVS 桥接# 安装 openvswitch sudo apt install -y openvswitch-switch # 创建 br-ex 桥并绑定物理网卡假设网卡名 enp3s0 sudo ovs-vsctl add-br br-ex sudo ovs-vsctl add-port br-ex enp3s0 # 配置 nova.conf [libvirt] virt_type qemu network_interface br-ex计算节点的nova.conf关键配置段[DEFAULT] transport_url rabbit://nova_compute_user:AnotherStr0ngPss!192.168.10.100:5672/openstack auth_strategy keystone my_ip 192.168.10.20 use_neutron true [libvirt] virt_type qemu cpu_mode custom cpu_model kvm64 network_interface br-ex启动服务前必须验证 KVM 模块已加载lsmod | grep kvm # 应输出 kvm_intel 或 kvm_amd egrep -c (vmx|svm) /proc/cpuinfo # 应输出大于 0 的数字若为 0说明 BIOS 中未开启 VT-x/AMD-V需重启进入 BIOS 启用。4.3 终极验证从创建虚拟机到控制台登录的端到端测试安装完成不等于可用。必须执行一次完整的生命周期测试覆盖创建、启动、控制台访问、销毁四个阶段Test 1创建最小化虚拟机# 上传 cirros 镜像轻量级测试镜像 openstack image create cirros --file cirros-0.6.2-x86_64-disk.img --disk-format qcow2 --container-format bare --public # 创建 flavor规格 openstack flavor create --id 1 --ram 128 --disk 1 --vcpus 1 m1.tiny # 创建网络假设已配置 Neutron openstack network create --share --external --provider-physical-network provider --provider-network-type flat provider # 创建虚拟机 openstack server create --flavor m1.tiny --image cirros --nic net-idPROVIDER_NET_ID --security-group default test-vm观察状态openstack server list应显示BUILD→ACTIVE耗时应 ≤15 秒。若卡在BUILD检查sudo journalctl -u nova-compute -f日志中的libvirtError。Test 2验证 VNC 控制台# 获取控制台 URL openstack console url show test-vm # URL 形如 http://192.168.10.10:6080/vnc_auto.html?tokenxxx # 在浏览器中打开应看到 cirros 的 login 提示符若页面空白检查sudo systemctl status nova-novncproxy是否运行以及netstat -tlnp | grep :6080是否监听。Test 3SSH 登录验证# 获取虚拟机 IP openstack server show test-vm | grep addresses # SSH 登录cirros 默认用户 cirros密码 cubswin:) ssh -o StrictHostKeyCheckingno cirros192.168.10.101 # 成功后执行 ping -c 3 8.8.8.8 # 应收到回复Test 4销毁并清理openstack server delete test-vm # 等待状态变为 DELETED openstack server list --all-projects | grep test-vm # 应无输出此时检查数据库mysql -h 192.168.10.100 -u nova -pnova_pass -e SELECT COUNT(*) FROM nova.instances WHERE deleted0; # 应返回 0这证明 nova-conductor 正确执行了软删除而非残留脏数据。5. 常见问题与排查技巧实录5.1 虚拟机状态卡在 BUILD 的 5 类根因与定位方法openstack server list中虚拟机长期处于BUILD状态是 Nova 最高频故障。根据近三年线上案例统计87% 的 BUILD 卡顿可归为以下五类按发生概率排序类别根因描述快速定位命令解决方案1. Libvirt 连接失败nova-compute 无法连接本地 libvirtd通常因 socket 权限或服务未启动sudo virsh list --allsudo systemctl status libvirtdsudo usermod -a -G libvirtd novasudo systemctl enable libvirtd sudo systemctl start libvirtd2. 镜像下载超时Glance 服务响应慢或网络不通导致 compute 节点无法拉取镜像sudo journalctl -u nova-compute -n 50 | grep glancecurl -I http://192.168.10.10:9292/v2/images检查 Glance endpoint URL 是否正确在 compute 节点执行ping -c 3 192.168.10.103. 调度器无可用主机nova-scheduler 的 filter 返回空列表常见于内存不足或 host_down 时间窗未过sudo nova-manage cell_v2 list_hostsopenstack hypervisor stats showsudo nova-manage cell_v2 discover_hosts --verbose检查nova.conf中[filter_scheduler]的available_filters是否包含AllHostsFilter4. RabbitMQ 消息积压nova-compute 未消费调度消息queue 中堆积大量create_instance任务sudo rabbitmqctl list_queues -p /openstack name messages_readysudo systemctl restart nova-compute检查 compute 节点的nova.conf中transport_url是否指向正确 RabbitMQ 地址5. 数据库连接池耗尽nova-conductor 的 SQLAlchemy 连接池满新请求被阻塞mysql -h 192.168.10.100 -u root -p -e SHOW PROCESSLIST; | wc -lsudo journalctl -u nova-conductor -n 20 | grep Timeout增大nova.conf中[database]的max_overflow值至 50重启sudo systemctl restart nova-conductor独家技巧当journalctl日志中出现No valid host was found时不要盲目重启服务。先执行sudo nova-manage cell_v2 list_hosts若输出为空说明 compute 节点未成功注册到 cell。此时应检查 compute 节点的nova.conf中[DEFAULT] my_ip是否为本机 IP而非 127.0.0.1以及sudo systemctl status nova-compute的Loaded行是否显示enabled。5.2 nova-scheduler 不调度到指定计算节点的 3 个隐藏开关有时你明确想把虚拟机调度到某台计算节点如compute01但openstack server create却总分配到其他节点。这通常不是调度