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.0（Wallaby），但当前 LTS 版本是 Yoga（25.2.0），而企业客户要求的往往是上一个稳定版 Xena（24.3.0）。你无法用apt install直接降级，强行dpkg -i又会触发python3-neutronclient依赖冲突——因为 Neutron 包版本被锁死了。手动安装则完全不同：你直接从 OpenStack 官网下载nova-24.3.0.tar.gz，用pip install --no-deps跳过冲突依赖，再单独pip install python-neutronclient==7.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服务，它才是真正与 Hypervisor（KVM/QEMU）交互的“工人”。它定期向nova-conductor上报自身资源（CPU 核数、可用内存、磁盘空间），并执行spawn（启动）、destroy（销毁）、resize（调整规格）等指令。一台计算节点可以是物理服务器，也可以是嵌套虚拟机（用于测试），但必须确保/dev/kvm设备存在且可被libvirt访问。

我推荐的最小可行拓扑是2 节点分离式：一台 Ubuntu 22.04 Server 作为控制节点，另一台同版本系统作为计算节点。两者通过千兆内网互通，IP 规划如下：

• 控制节点：192.168.10.10（hostname:controller）
• 计算节点：192.168.10.20（hostname:compute1）

这个设计规避了单点故障（如果nova-scheduler和nova-compute在同一台机器，该机器宕机则整个云失去调度能力），也符合 OpenStack 官方文档的推荐架构。很多教程鼓吹“All-in-One”，那是给 demo 看的玩具，不是生产环境的基石。

2.3 核心依赖选型与版本锁定策略

Nova 的稳定运行，极度依赖三个外部组件：数据库、消息队列、身份认证服务。它们的版本组合不是随意搭配的，必须严格遵循 OpenStack 的互操作矩阵（Interoperability Matrix）。以我们选定的 Nova Yoga（25.2.0）为例，官方认证的组合是：

提示：所有依赖必须通过官方渠道安装。MySQL 严禁用apt install mysql-server（Ubuntu 默认是 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_INTEL=y（Intel CPU）或CONFIG_KVM_AMD=y（AMD 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_forward=1 # 关闭 ICMP 重定向（防止网络中间人攻击） net.ipv4.conf.all.send_redirects=0 net.ipv4.conf.default.send_redirects=0 # 提升连接队列长度（应对高并发 API 请求） net.core.somaxconn=65535 # 减少 TIME_WAIT 状态持续时间（加速 socket 复用） net.ipv4.tcp_fin_timeout=30 # 启用 SYN Cookies（抵御 SYN Flood 攻击） net.ipv4.tcp_syncookies=1

执行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 pid=1234 comm="qemu-system-x86" name="disk"错误，虚拟机永远处于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 'nova'@'localhost' IDENTIFIED BY 'N0vaP@ssw0rd!2024'; CREATE USER 'nova'@'%' IDENTIFIED BY 'N0vaP@ssw0rd!2024'; -- 授予所有数据库的全部权限（注意：生产环境应细化到具体表） GRANT ALL PRIVILEGES ON nova_api.* TO 'nova'@'localhost'; GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost'; GRANT ALL PRIVILEGES ON nova_cell0.* TO 'nova'@'localhost'; 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 R4bb1tP@ss!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/R4bb1tP@ss!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。手动安装的核心是隔离、纯净、可复现。

步骤分解与原理说明：

1. 创建专用用户与目录结构：

   # 创建 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

2. 构建 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

3. 安装 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-keystoneclient==5.4.0 \ python-neutronclient==7.12.0 \ python-cinderclient==9.3.0 \ oslo.db==12.2.0 \ oslo.log==5.3.0

为什么不用pip install nova？因为 PyPI 上的nova包是开发快照版，版本号为25.2.0.dev123，其setup.cfg中的依赖声明不包含oslo.db>=12.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] # 主数据库连接字符串，格式：mysql+pymysql://user:pass@host:port/dbname connection = mysql+pymysql://nova:N0vaP@ssw0rd!2024@192.168.10.10/nova?charset=utf8mb4 # Cell0 数据库连接（必须单独配置） connection_cell0 = mysql+pymysql://nova:N0vaP@ssw0rd!2024@192.168.10.10/nova_cell0?charset=utf8mb4 # 连接池参数：最大连接数 300，空闲超时 3600 秒，避免连接泄漏 max_pool_size = 300 idle_timeout = 3600 # 启用连接健康检查（每 30 秒 ping 一次） ping_interval = 30

提示：mysql+pymysql是强制要求。mysqlclient（C 扩展）在高并发下有内存泄漏，PyMySQL（纯 Python）虽稍慢，但稳定可靠。charset=utf8mb4必须显式声明，否则pymysql默认用latin1，插入中文会报错。

[oslo_messaging_rabbit]Section —— 消息队列可靠性保障

[oslo_messaging_rabbit] # RabbitMQ 连接 rabbit_hosts = 192.168.10.10:5672 rabbit_userid = openstack rabbit_password = R4bb1tP@ss!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 = N0vaP@ssw0rd!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] Description=OpenStack Compute API Server After=network.target After=mysqld.service After=rabbitmq-server.service # 依赖 keystone，确保 auth 服务先启动 After=openstack-keystone.service [Service] Type=simple User=nova Group=nova # 指向虚拟环境中的可执行文件 ExecStart=/opt/nova-venv/bin/nova-api # 工作目录，日志和 pid 文件存放地 WorkingDirectory=/var/lib/nova # 标准输出重定向到 journal StandardOutput=journal StandardError=journal # 环境变量，指定配置文件路径 Environment="OSLO_CONFIG_DIR=/etc/nova" Environment="OSLO_LOG_DIR=/var/log/nova" # 重启策略：崩溃后 10 秒重启，最多 5 次/分钟 Restart=always RestartSec=10 StartLimitInterval=60 StartLimitBurst=5 [Install] WantedBy=multi-user.target

关键权限控制点：

• PID 文件路径：nova-api默认在/var/run/nova/下创建nova-api.pid，但该目录属主是root，nova用户无权写入。解决方案是在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 --signal=SIGHUP 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 --name=cell1 --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:R4bb1tP@ss!2024@192.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.service

Step 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 AdminP@ssw0rd!2024 --os-identity-api-version 3 --os-image-api-version 2 server list，应返回空列表（无虚拟机）而非报错。

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

5.1 典型故障速查表与根因分析