1. 项目概述Nova 是什么为什么需要手动安装与配置Nova 是 OpenStack 云平台中最核心的计算服务组件它负责管理虚拟机实例的整个生命周期——从创建、调度、启动、暂停、迁移到销毁。你可以把它理解为整个私有云的“CPU 调度中枢”当用户在 Horizon 控制台点下“启动实例”按钮或者通过 OpenStack CLI 执行openstack server create命令时背后真正干活、跟 KVM/QEMU 打交道、向宿主机分配 CPU/内存/磁盘、协调网络和存储的就是 Nova 服务。它不是单个进程而是一组协同工作的守护进程nova-api、nova-scheduler、nova-conductor、nova-compute、nova-novncproxy 等各自承担不同职责通过消息队列如 RabbitMQ和数据库如 MySQL紧密通信。之所以强调“手动安装与配置”是因为绝大多数生产环境或深度学习/测试场景根本无法依赖一键脚本或发行版打包工具如 Ubuntu 的apt install nova-api。原因很实在自动包往往版本陈旧、模块固化、路径硬编码、依赖冲突严重且默认配置全是面向最小化演示环境设计的——比如它可能把所有服务都塞进一台机器里用 SQLite 当数据库连最基本的多节点部署、KVM 虚拟化支持、Neutron 网络集成、Ceph 存储后端对接都得你亲手掰开重装。我去年在给一家高校超算中心搭建教学云时就踩过这个坑用 DevStack 脚本跑出来的 Nova三天两头报No valid host was found错误查日志发现 scheduler 根本没读取到 compute 节点的资源报表最后追到源码层才发现是nova.conf里scheduler_driver参数被脚本错误覆盖成了已废弃的类名。这种问题只有亲手把每个配置项的意义、每个服务的启动顺序、每个依赖的版本边界都摸清楚才能稳住。所以“Nova 的手动安装与配置”本质上不是教你怎么敲几行命令而是带你重建一套可审计、可调试、可扩展的计算服务骨架。它适合三类人一是正在备考 OpenStack 认证如 COA的工程师需要透彻理解服务间调用链二是企业私有云运维人员必须能独立部署、升级、排障三是科研团队或边缘计算项目开发者需要将 Nova 深度嵌入定制化调度逻辑中比如把 GPU 资源按 CUDA Core 数量而非整卡粒度切分。如果你只是想快速搭个 Demo 看效果那确实该去看 DevStack 教程但如果你的目标是让 Nova 在未来三年内稳定支撑上百台物理服务器、数千个虚拟机那这份手动配置指南就是你必须亲手写下的第一份“云基础设施宪法”。2. 整体架构设计与方案选型逻辑2.1 为什么放弃一键脚本坚持手动拆解很多人看到“手动安装”四个字就头皮发麻觉得是自找麻烦。但实际操作中放弃自动化工具恰恰是最省时间的选择。我统计过自己过去五年部署的 17 个 Nova 环境其中 12 个用 DevStack 或 Packstack 部署的平均修复配置耗时 18.5 小时而 5 个纯手动部署的首次安装加调试平均只用了 9.2 小时且后续维护成本几乎为零。差距在哪关键在于“控制粒度”。DevStack 的黑盒陷阱它用临时目录如/opt/stack存放所有源码用local.conf做参数注入但底层服务的 systemd unit 文件、日志路径、socket 文件位置全由脚本动态生成。一旦出错你得在上千行 Bash 脚本里 grep “nova-api”再定位到它最终生成的nova-api.service文件在哪而这个路径在每次./unstack.sh ./stack.sh后都可能变化。更致命的是它默认启用devstack-gate测试模式会偷偷修改nova.conf中的debug True和use_syslog False导致生产环境日志爆炸式增长磁盘一夜之间被占满。发行版包的版本枷锁Ubuntu 22.04 官方仓库里的nova-api包版本是 24.2.0Wallaby但当前 LTS 版本是 Yoga25.2.0而企业客户要求的往往是上一个稳定版 Xena24.3.0。你无法用apt install直接降级强行dpkg -i又会触发python3-neutronclient依赖冲突——因为 Neutron 包版本被锁死了。手动安装则完全不同你直接从 OpenStack 官网下载nova-24.3.0.tar.gz用pip install --no-deps跳过冲突依赖再单独pip install python-neutronclient7.12.0指定兼容版本整个过程可控、可回溯、可写入 Ansible Playbook。因此我的方案选型原则非常明确以 OpenStack 官方发布的 stable 分支源码为唯一可信来源以 Python 的venv虚拟环境为运行沙箱以 systemd 为服务管理标准以 MySQL RabbitMQ 为生产级依赖栈。这看似步骤多实则是把所有不确定性变量版本、路径、权限、日志全部显式化让每一次systemctl restart nova-api都变成一次可预期的操作。2.2 服务角色划分与节点拓扑设计Nova 不是单体应用它天然要求分布式部署。哪怕你只有一台物理服务器也必须在逻辑上区分“控制节点”和“计算节点”。这是由它的服务职责决定的控制节点Controller Node承载nova-api接收 REST 请求、nova-scheduler决策虚拟机该放在哪台物理机上、nova-conductor作为数据库代理避免 compute 节点直连 DB 带来的安全与性能风险、nova-novncproxy提供 Web 控制台 VNC 代理。这些服务可以合并在一台机器但绝不能和nova-compute共存——因为后者需要加载 KVM 内核模块会极大增加控制节点的攻击面。计算节点Compute Node只运行nova-compute服务它才是真正与 HypervisorKVM/QEMU交互的“工人”。它定期向nova-conductor上报自身资源CPU 核数、可用内存、磁盘空间并执行spawn启动、destroy销毁、resize调整规格等指令。一台计算节点可以是物理服务器也可以是嵌套虚拟机用于测试但必须确保/dev/kvm设备存在且可被libvirt访问。我推荐的最小可行拓扑是2 节点分离式一台 Ubuntu 22.04 Server 作为控制节点另一台同版本系统作为计算节点。两者通过千兆内网互通IP 规划如下控制节点192.168.10.10hostname:controller计算节点192.168.10.20hostname:compute1这个设计规避了单点故障如果nova-scheduler和nova-compute在同一台机器该机器宕机则整个云失去调度能力也符合 OpenStack 官方文档的推荐架构。很多教程鼓吹“All-in-One”那是给 demo 看的玩具不是生产环境的基石。2.3 核心依赖选型与版本锁定策略Nova 的稳定运行极度依赖三个外部组件数据库、消息队列、身份认证服务。它们的版本组合不是随意搭配的必须严格遵循 OpenStack 的互操作矩阵Interoperability Matrix。以我们选定的 Nova Yoga25.2.0为例官方认证的组合是组件推荐版本选择理由替代方案风险DatabaseMySQL 8.0.33支持 JSON 字段用于存储 instance metadata、行级锁避免高并发下instance表死锁、GTID 复制便于主从切换PostgreSQL 14 也可但 MySQL 社区生态更成熟mysql-client工具链更丰富SQLite 仅限测试不支持并发写入Message QueueRabbitMQ 3.11.13AMQP 0.9.1 协议原生支持、rabbitmq_delayed_message_exchange插件完善用于 scheduler retry 机制、内存占用比 Kafka 低 40%Kafka 配置复杂需额外部署 ZooKeeperRedis 无持久化保障消息丢失风险高Identity ServiceKeystone Yoga (22.0.0)与 Nova Yoga 同期发布API v3 兼容性最佳federation和application credential特性完整使用旧版 Keystone如 Wallaby会导致openstack token issue返回 401因 JWT token 签名算法不匹配提示所有依赖必须通过官方渠道安装。MySQL 严禁用apt install mysql-serverUbuntu 默认是 8.0.33但mysql-client版本可能不匹配应下载 Oracle 官网.deb包用dpkg -i逐个安装mysql-community-server、mysql-community-client、mysql-community-common确保三者版本号完全一致如8.0.33-1ubuntu22.04。RabbitMQ 同理必须从 https://www.rabbitmq.com/install-debian.html 获取rabbitmq-server_3.11.13-1_all.deb而非apt仓库里的3.9.13。3. 核心细节解析与实操要点3.1 系统基础环境准备内核、网络与安全加固手动安装的第一步永远不是下载 Nova 源码而是把操作系统这台“发动机”调校到最佳状态。很多人的 Nova 启动失败根源其实在于/etc/sysctl.conf里几个被忽略的参数。内核参数调优KVM 虚拟化对内核有硬性要求。必须确认CONFIG_KVM_INTELyIntel CPU或CONFIG_KVM_AMDyAMD CPU已编译进内核。执行zcat /proc/config.gz | grep CONFIG_KVM若未启用CONFIG_IKCONFIG_PROC则用modprobe kvm modprobe kvm_intel lsmod | grep kvm验证模块加载。然后永久生效以下参数# 编辑 /etc/sysctl.conf追加以下内容 # 启用 IP 转发Neutron L3 Agent 必需 net.ipv4.ip_forward1 # 关闭 ICMP 重定向防止网络中间人攻击 net.ipv4.conf.all.send_redirects0 net.ipv4.conf.default.send_redirects0 # 提升连接队列长度应对高并发 API 请求 net.core.somaxconn65535 # 减少 TIME_WAIT 状态持续时间加速 socket 复用 net.ipv4.tcp_fin_timeout30 # 启用 SYN Cookies抵御 SYN Flood 攻击 net.ipv4.tcp_syncookies1执行sysctl -p生效后还需验证sysctl net.ipv4.ip_forward应返回1否则nova-network或neutron-openvswitch-agent将无法工作。网络规划与防火墙OpenStack 服务间通信端口必须开放但绝不能简单ufw disable。正确的做法是精确放行# 控制节点放行端口 sudo ufw allow from 192.168.10.0/24 to any port 3306 # MySQL sudo ufw allow from 192.168.10.0/24 to any port 5672 # RabbitMQ sudo ufw allow from 192.168.10.0/24 to any port 5000 # Keystone API sudo ufw allow from 192.168.10.0/24 to any port 8774 # Nova API sudo ufw allow from 192.168.10.0/24 to any port 8775 # Nova Metadata API # 计算节点只需放行到控制节点的 5672 和 3306 sudo ufw allow out to 192.168.10.10 port 5672 sudo ufw allow out to 192.168.10.10 port 3306注意nova-metadata-api端口 8775必须严格限制访问源为192.168.10.0/24内网段绝不能暴露到公网。历史上曾有因该端口开放导致元数据泄露攻击者通过curl http://169.254.169.254/openstack/latest/meta_data.json获取管理员凭据的案例。SELinux/AppArmor 策略Ubuntu 默认启用 AppArmor它会阻止nova-compute访问/var/lib/nova/instances/下的磁盘镜像文件。必须创建自定义 profile# 生成 nova-compute profile sudo aa-genprof /usr/bin/nova-compute # 按提示操作在 nova-compute 启动后手动创建一个虚拟机触发所有文件访问行为 # 最后执行 sudo aa-enforce /etc/apparmor.d/usr.bin.nova-compute若跳过此步nova-compute日志中会出现大量AVC avc: denied { read } for pid1234 commqemu-system-x86 namedisk错误虚拟机永远处于BUILD状态。3.2 数据库与消息队列初始化建库、授权与插件启用Nova 的数据持久化完全依赖 MySQL其表结构复杂度远超普通应用。一个典型的nova数据库包含 62 张表其中instances存储虚拟机元数据、compute_nodes记录物理节点资源、migrations追踪热迁移状态是核心。手动初始化必须一步到位避免后续因字符集或排序规则不一致导致UnicodeEncodeError。MySQL 初始化脚本在控制节点执行-- 创建 nova 数据库显式指定字符集和排序规则 CREATE DATABASE nova_api CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE DATABASE nova CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE DATABASE nova_cell0 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 创建 nova 用户密码必须满足 MySQL 8.0 的强密码策略至少 8 位含大小写字母数字特殊符号 CREATE USER novalocalhost IDENTIFIED BY N0vaPssw0rd!2024; CREATE USER nova% IDENTIFIED BY N0vaPssw0rd!2024; -- 授予所有数据库的全部权限注意生产环境应细化到具体表 GRANT ALL PRIVILEGES ON nova_api.* TO novalocalhost; GRANT ALL PRIVILEGES ON nova.* TO novalocalhost; GRANT ALL PRIVILEGES ON nova_cell0.* TO novalocalhost; GRANT ALL PRIVILEGES ON nova_api.* TO nova%; GRANT ALL PRIVILEGES ON nova.* TO nova%; GRANT ALL PRIVILEGES ON nova_cell0.* TO nova%; -- 刷新权限 FLUSH PRIVILEGES;实操心得nova_cell0数据库是 Nova Cells v2 架构的必需组件用于水平扩展计算节点。即使你当前只有一台 compute 节点也必须创建它否则nova-manage db sync会报Cell0 database is not up to date错误。utf8mb4是强制要求因为虚拟机名称、镜像描述等字段可能包含 emoji 或中文生僻字utf8仅支持 3 字节会截断数据。RabbitMQ 插件启用与用户创建RabbitMQ 默认不启用管理界面和延迟消息插件而这二者对 Nova 至关重要前者用于监控队列积压后者用于 scheduler 的 retry 机制。# 启用管理插件 sudo rabbitmq-plugins enable rabbitmq_management # 启用延迟消息插件Yoga 版本必需 sudo rabbitmq-plugins enable rabbitmq_delayed_message_exchange # 创建 nova 用户并设置标签 sudo rabbitmqctl add_user openstack R4bb1tPss!2024 sudo rabbitmqctl set_user_tags openstack administrator # 设置权限读写所有队列 sudo rabbitmqctl set_permissions openstack .* .* .* # 重启服务 sudo systemctl restart rabbitmq-server验证是否成功浏览器访问http://192.168.10.10:15672用openstack/R4bb1tPss!2024登录进入Admin Virtual Hosts确认/虚拟主机存在且openstack用户有administrator标签。3.3 Nova 源码安装与虚拟环境构建从 tarball 到可执行服务OpenStack 官方不再提供.deb或.rpm包所有稳定版均以tar.gz源码包形式发布。Yoga 版本的 Nova 源码包可在 https://releases.openstack.org/yoga/ 下载文件名为nova-25.2.0.tar.gz。手动安装的核心是隔离、纯净、可复现。步骤分解与原理说明创建专用用户与目录结构# 创建 nova 用户禁止登录仅用于服务运行 sudo useradd -r -s /bin/false nova # 创建服务目录遵循 Linux FHS 标准 sudo mkdir -p /var/lib/nova /var/log/nova /etc/nova sudo chown -R nova:nova /var/lib/nova /var/log/nova /etc/nova构建 Python 虚拟环境# 切换到 nova 用户创建 venv sudo -u nova python3 -m venv /opt/nova-venv # 激活环境并升级 pip关键旧版 pip 无法解析 OpenStack 的复杂依赖 sudo -u nova /opt/nova-venv/bin/pip install --upgrade pip # 安装 setuptools 和 wheel构建源码必需 sudo -u nova /opt/nova-venv/bin/pip install setuptools wheel安装 Nova 源码包# 解压源码到临时目录 tar -xzf nova-25.2.0.tar.gz -C /tmp/ # 进入源码目录使用 --no-deps 参数跳过依赖检查我们手动安装 cd /tmp/nova-25.2.0 sudo -u nova /opt/nova-venv/bin/pip install --no-deps . # 手动安装关键依赖版本必须精确匹配 sudo -u nova /opt/nova-venv/bin/pip install \ python-keystoneclient5.4.0 \ python-neutronclient7.12.0 \ python-cinderclient9.3.0 \ oslo.db12.2.0 \ oslo.log5.3.0为什么不用pip install nova因为 PyPI 上的nova包是开发快照版版本号为25.2.0.dev123其setup.cfg中的依赖声明不包含oslo.db12.0.0,13.0.0这样的精确范围会导致pip自动安装最新版oslo.db如 13.1.0而该版本移除了oslo_db.sqlalchemy.enginefacade模块nova-api启动时直接ImportError。手动下载 tarball 并pip install .能确保使用源码包内requirements.txt定义的精确依赖。安装完成后验证二进制文件是否存在ls -l /opt/nova-venv/bin/nova-* # 应看到 nova-api, nova-scheduler, nova-conductor, nova-compute 等可执行文件4. 实操过程与核心环节实现4.1 配置文件nova.conf的逐项解析与安全设置nova.conf是 Nova 的“心脏起搏器”超过 80% 的故障源于配置错误。它不是一个大杂烩而是按[DEFAULT]、[api]、[database]、[keystone_authtoken]、[glance]、[oslo_messaging_rabbit]、[libvirt]等 Section 组织。下面是对生产环境最关键的 7 个 Section 的深度解析。[DEFAULT]Section —— 全局行为定义[DEFAULT] # 服务监听地址必须绑定到内网 IP绝不能是 0.0.0.0暴露风险 my_ip 192.168.10.10 # 启用 Cells v2 架构现代 OpenStack 的标准 enable_cells true # 元数据服务地址供虚拟机内部 curl 获取信息 metadata_host 192.168.10.10 # 日志级别生产环境禁用 debug但保留 warning 以上 log_level WARNING # 禁用控制台日志避免敏感信息泄露到终端 use_stderr false # 启用实例软删除删除后保留 1 小时可恢复 instance_usage_audit_period hour[database]Section —— 数据库连接精调[database] # 主数据库连接字符串格式mysqlpymysql://user:passhost:port/dbname connection mysqlpymysql://nova:N0vaPssw0rd!2024192.168.10.10/nova?charsetutf8mb4 # Cell0 数据库连接必须单独配置 connection_cell0 mysqlpymysql://nova:N0vaPssw0rd!2024192.168.10.10/nova_cell0?charsetutf8mb4 # 连接池参数最大连接数 300空闲超时 3600 秒避免连接泄漏 max_pool_size 300 idle_timeout 3600 # 启用连接健康检查每 30 秒 ping 一次 ping_interval 30提示mysqlpymysql是强制要求。mysqlclientC 扩展在高并发下有内存泄漏PyMySQL纯 Python虽稍慢但稳定可靠。charsetutf8mb4必须显式声明否则pymysql默认用latin1插入中文会报错。[oslo_messaging_rabbit]Section —— 消息队列可靠性保障[oslo_messaging_rabbit] # RabbitMQ 连接 rabbit_hosts 192.168.10.10:5672 rabbit_userid openstack rabbit_password R4bb1tPss!2024 # 启用心跳检测每 60 秒发一次心跳包断连立即重连 heartbeat 60 # 消息持久化确保 broker 宕机不丢消息 amqp_durable_queues true # 启用延迟交换器scheduler retry 依赖 delayed_delivery true # 队列最大长度防止单个队列无限堆积 queue_length_limit 10000[libvirt]Section —— 计算节点专属配置仅 compute 节点[libvirt] # 虚拟化类型KVM 是主流选择 virt_type kvm # 启用硬件加速Intel VT-x/AMD-V cpu_mode host-passthrough # 磁盘镜像存储路径必须是 nova 用户可写 images_type default images_directory /var/lib/nova/instances # 启用 QEMU Guest Agent实现优雅关机、获取 IP inject_password false # 启用 libvirt 的 secret 存储用于存储 Ceph 密钥 use_libvirt_secret true[keystone_authtoken]Section —— 身份认证安全加固[keystone_authtoken] # Keystone 服务地址 auth_url http://192.168.10.10:5000/v3 # Nova 服务在 Keystone 中注册的用户名和密码 username nova password N0vaPssw0rd!2024 # 项目租户名称 project_name service # 用户域和项目域OpenStack 采用 domain 概念 user_domain_name Default project_domain_name Default # 启用 memcached 缓存 token提升性能 memcached_servers 192.168.10.10:11211 # 禁用 insecure 模式绝不允许 insecure false # 启用 signing key 轮换安全最佳实践 signing_dir /var/cache/nova/keystone-signing注意insecure false是红线。设为true会跳过 TLS 证书验证任何中间人攻击都能窃取 token。生产环境必须部署有效的 TLS 证书并在auth_url中使用https://。4.2 服务单元文件systemd编写与权限控制OpenStack 官方不提供 systemd unit 文件必须手写。每个服务对应一个.service文件存放在/etc/systemd/system/。以nova-api.service为例[Unit] DescriptionOpenStack Compute API Server Afternetwork.target Aftermysqld.service Afterrabbitmq-server.service # 依赖 keystone确保 auth 服务先启动 Afteropenstack-keystone.service [Service] Typesimple Usernova Groupnova # 指向虚拟环境中的可执行文件 ExecStart/opt/nova-venv/bin/nova-api # 工作目录日志和 pid 文件存放地 WorkingDirectory/var/lib/nova # 标准输出重定向到 journal StandardOutputjournal StandardErrorjournal # 环境变量指定配置文件路径 EnvironmentOSLO_CONFIG_DIR/etc/nova EnvironmentOSLO_LOG_DIR/var/log/nova # 重启策略崩溃后 10 秒重启最多 5 次/分钟 Restartalways RestartSec10 StartLimitInterval60 StartLimitBurst5 [Install] WantedBymulti-user.target关键权限控制点PID 文件路径nova-api默认在/var/run/nova/下创建nova-api.pid但该目录属主是rootnova用户无权写入。解决方案是在ExecStart后添加--pid-file /var/lib/nova/nova-api.pid并将/var/lib/nova/目录权限设为755属主nova:nova。日志轮转配置创建/etc/logrotate.d/nova/var/log/nova/*.log { daily missingok rotate 30 compress delaycompress notifempty create 644 nova nova sharedscripts postrotate systemctl kill --signalSIGHUP nova-api.service endscript }这确保日志每天切割保留 30 天且SIGHUP信号通知服务重新打开日志文件避免logrotate后日志停止写入。SELinux/AppArmor 策略更新每次新增ExecStart路径或WorkingDirectory都必须更新安全策略。对 AppArmor执行sudo aa-genprof /opt/nova-venv/bin/nova-api按提示操作即可。4.3 数据库同步与服务启动全流程完成配置后必须按严格顺序执行初始化任何一步跳过都会导致服务启动失败。Step 1同步数据库 Schema在控制节点以nova用户身份执行# 激活虚拟环境 source /opt/nova-venv/bin/activate # 同步 nova_api 数据库 nova-manage api_db sync # 同步 nova 主数据库 nova-manage db sync # 注册 cell0必须在 sync 之后否则报错 nova-manage cell_v2 map_cell0 # 创建 cell1即默认计算单元 nova-manage cell_v2 create_cell --namecell1 --verbose # 发现计算节点扫描 /etc/nova/nova.conf 中的 [DEFAULT] my_ip nova-manage cell_v2 discover_hosts --verbose关键验证点执行nova-manage cell_v2 list_cells应看到cell0和cell1两个条目且cell1的transport_url显示为rabbit://openstack:R4bb1tPss!2024192.168.10.10:5672/。若cell1为空则discover_hosts未成功需检查nova.conf中my_ip是否正确。Step 2启动服务并验证状态按依赖顺序启动先数据库、消息队列再 nova 服务# 控制节点 sudo systemctl daemon-reload sudo systemctl enable openstack-nova-api.service sudo systemctl enable openstack-nova-scheduler.service sudo systemctl enable openstack-nova-conductor.service sudo systemctl enable openstack-nova-novncproxy.service sudo systemctl start openstack-nova-api.service sudo systemctl start openstack-nova-scheduler.service sudo systemctl start openstack-nova-conductor.service sudo systemctl start openstack-nova-novncproxy.service # 计算节点仅启动 nova-compute sudo systemctl daemon-reload sudo systemctl enable openstack-nova-compute.service sudo systemctl start openstack-nova-compute.serviceStep 3服务健康检查检查进程ps aux | grep nova-应看到所有服务进程且用户为nova。检查端口sudo ss -tlnp | grep :8774\|:8775应显示nova-api监听192.168.10.10:8774。检查日志sudo journalctl -u openstack-nova-api.service -f观察是否有Starting nova-api和Serving on http://192.168.10.10:8774字样。API 测试在控制节点执行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 AdminPssw0rd!2024 --os-identity-api-version 3 --os-image-api-version 2 server list应返回空列表无虚拟机而非报错。5. 常见问题与排查技巧实录5.1 典型故障速查表与根因分析故障现象日志关键词根本原因解决方案nova-api启动失败报ImportError: No module named keystoneauth1ImportError,keystoneauth1pip install时未安装keystoneauth1依赖或版本不匹配手动执行sudo -u nova /opt/nova-venv/bin/pip install keystoneauth14.5.0版本必须与nova-25.2.0/requirements.txt一致nova-scheduler日志循环打印No valid host was foundNoValidHost,filternova.conf中scheduler_default_filters未启用ComputeFilter或compute_nodes表为空检查nova.conf的[filter_scheduler]Section确保enabled_filters ComputeFilter,AvailabilityZoneFilter,RetryFilter执行nova-manage cell_v2 discover_hostsnova-compute服务状态为activating (start)卡住activating,libvirtlibvirtd服务未启动或nova用户未加入libvirtd组sudo systemctl start libvirtdsudo usermod -a -G libvirtd novasudo systemctl restart openstack-nova-compute虚拟机状态长期为BUILDnova-compute日志报Unable to find imageUnable to find image,glancenova.conf中[glance]Section 的api_servers地址错误或 Glance 服务未运行检查 api_servers http://192.168.10.10:9