OpenStack Nova手动安装配置实战：生产环境部署指南

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_table=ON（否则表空间无法在线收缩）、max_connections≥500（Nova-api 和 nova-scheduler 会各自建立独立连接池）、wait_timeout=28800（避免长连接被中间设备误杀）。这些参数在官方文档里散落在三个不同章节，新手根本找不到关联逻辑。而本文要做的，就是把这些隐性依赖全部拎出来，告诉你为什么必须这么配、不这么配会触发什么故障现象、以及如何用一条 SQL 快速验证当前 MySQL 实例是否达标。

适合阅读本文的，不是刚学 Linux 的小白，而是已经部署过至少一套 Web 服务、能看懂systemctl status输出、知道my.cnf和/etc/nova/nova.conf区别的人。如果你正面临以下场景之一，这篇内容就是为你写的：需要在现有物理服务器集群上构建高可用 OpenStack（非单机 demo）；公司安全合规要求所有服务必须启用 TLS 双向认证；需要对接已有的 LDAP/AD 用户体系而非 Keystone 内置用户；或者你正在考取 OpenStack Certified Administrator（COA）认证，需要真正理解 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 加密和负载均衡。

如果把所有服务塞进一台机器，表面看省了网络开销，实则制造了三重隐患：

1. 资源争抢：nova-scheduler 的 CPU 密集型调度算法（Filter Scheduler + Weight Functions）会和 nova-compute 的 QEMU 进程争夺 CPU 时间片，导致调度延迟飙升，虚拟机创建时间从 3 秒拉长到 47 秒；
2. 单点故障：该节点宕机，整个云平台计算能力归零，无任何降级路径；
3. 安全越界：计算节点需直连物理网卡并运行 untrusted guest code，按等保三级要求，其网络区域必须与控制平面物理隔离，混部直接违反安全基线。

因此，本文采用的部署拓扑是：

• 控制节点（IP: 192.168.10.10）：仅部署 nova-api、nova-scheduler、nova-conductor、nova-novncproxy；
• 计算节点（IP: 192.168.10.20）：仅部署 nova-compute；
• 共享服务：MySQL（192.168.10.100）、RabbitMQ（192.168.10.100）、Keystone（192.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-api：RESTful 接口入口，接收所有用户请求；
• 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 年 Q2，OpenStack 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. 连接池大小必须 ≥500，Nova 服务会为每个 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 Cache），Nova 的查询高度动态，缓存命中率 <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_NAME='nova';"

若返回空，说明 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 的所有调度指令——这是典型的横向越权。

正确做法是：

1. 创建专用 vhost：sudo rabbitmqctl add_vhost /openstack
2. 创建两个独立用户：
   • nova_api_user：仅授予/openstackvhost 的configure、write、read权限，用于 nova-api 和 nova-scheduler；
   • nova_compute_user：仅授予/openstackvhost 的write、read权限（禁用 configure），用于 nova-compute；

权限分配命令如下：

sudo rabbitmqctl add_user nova_api_user 'StrongPassw0rd!' sudo rabbitmqctl add_user nova_compute_user 'AnotherStr0ngP@ss!' 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 AnotherStr0ngP@ss! 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_id：Keystone 中创建的 nova 用户 ID；
• Service User 的 project_id：通常为service项目 ID；
• Nova Endpoint 的 interface URL：必须指向控制节点的 nova-api 地址，且协议、端口、路径三者缺一不可。

完整操作链：

1. 在 Keystone 中创建 nova 用户：

   openstack user create --domain default --password-prompt nova # 输入密码后，记录返回的 ID 字段（如 8a3b4c5d...）

2. 将用户加入 service 项目并赋予 admin 角色：

   openstack role add --project service --user nova admin

3. 创建 nova service 实体：

   openstack service create --name nova --description "OpenStack Compute" compute # 记录返回的 service_id

4. 创建三个 endpoint（public/internal/admin）：

   openstack 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：系统基础加固

# 禁用 swap（Nova 要求内存严格可控） 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 -p

Step 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-essential

Step 3：安装并配置 MySQL 客户端

sudo apt install -y mysql-client-core-8.0 # 测试连通性（需提前在 MySQL 服务端授权 nova 用户） mysql -h 192.168.10.100 -u nova -p'nova_pass' -e "SELECT 1;"

Step 4：安装 RabbitMQ 客户端

sudo apt install -y rabbitmq-c-dev # 测试 AMQP 连通性 sudo rabbitmqctl -q -n rabbit@192.168.10.100 list_vhosts

Step 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 id

Step 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 = mysql+pymysql://nova:nova_pass@192.168.10.100/nova_api?charset=utf8mb4

在[database]段落：

connection = mysql+pymysql://nova:nova_pass@192.168.10.100/nova?charset=utf8mb4

在[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_pass

Step 9：初始化数据库

sudo nova-manage api_db sync sudo nova-manage db sync # 验证表是否创建成功 mysql -h 192.168.10.100 -u nova -p'nova_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 apache2

Step 11：启动并启用 Nova 服务

sudo systemctl enable nova-api nova-scheduler nova-conductor nova-novncproxy sudo systemctl start nova-api nova-scheduler nova-conductor nova-novncproxy

Step 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 配置存在三个致命缺陷，必须手动修复：

缺陷 1：CPU 模型未锁定，导致虚拟机迁移失败
默认 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="... elevator=none" sudo update-grub && sudo reboot

缺陷 3：libvirt 网络未桥接到物理网卡，虚拟机无法上网
默认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:AnotherStr0ngP@ss!@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-id=PROVIDER_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?token=xxx # 在浏览器中打开，应看到 cirros 的 login 提示符

若页面空白，检查sudo systemctl status nova-novncproxy是否运行，以及netstat -tlnp | grep :6080是否监听。

Test 3：SSH 登录验证

# 获取虚拟机 IP openstack server show test-vm | grep addresses # SSH 登录（cirros 默认用户 cirros，密码 cubswin:) ssh -o StrictHostKeyChecking=no cirros@192.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 -p'nova_pass' -e "SELECT COUNT(*) FROM nova.instances WHERE deleted=0;" # 应返回 0

这证明 nova-conductor 正确执行了软删除，而非残留脏数据。

5. 常见问题与排查技巧实录

5.1 虚拟机状态卡在 BUILD 的 5 类根因与定位方法

openstack server list中虚拟机长期处于BUILD状态，是 Nova 最高频故障。根据近三年线上案例统计，87% 的 BUILD 卡顿可归为以下五类，按发生概率排序：

独家技巧：当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却总分配到其他节点。这通常不是调度