OpenStack 创建虚拟机看起来只是执行一条命令，背后却需要身份、计算、网络、镜像、存储和资源调度等多个服务协同。理解这条请求链路，能明显提高部署与故障排查效率。
## 1. 主要服务及职责
- Keystone：认证用户身份，签发 Token，并提供服务目录。
- Nova：负责实例生命周期，包括 API、调度、计算节点执行和状态管理。
- Placement：维护资源提供者及 CPU、内存、磁盘、PCI 等资源库存与分配记录。
- Glance：保存和分发系统镜像及镜像元数据。
- Neutron：创建网络、子网、端口、安全组和路由等网络资源。
- Cinder：提供持久化块存储卷、快照和备份。
- Horizon：Web 管理界面，本质上仍通过各服务 API 工作。
Nova 本身还包含 nova-api、nova-scheduler、nova-conductor、nova-compute 和控制台代理等组件。消息队列用于组件间通信，数据库保存控制面状态。
## 2. 用户请求进入云平台
用户可以通过 Horizon、OpenStack CLI 或 SDK 发起请求。例如：
```bash
openstack server create \
--flavor m1.small \
--image ubuntu-22.04 \
--network private-net \
--security-group default \
--key-name demo-key \
demo-vm
```
客户端先从 Keystone 获取认证信息和服务目录，再把创建请求发送给 Nova API。生产环境不应把管理员密码直接写进脚本，应使用受限账号、application credential 或安全的凭证管理方式。
## 3. Nova API 检查请求
Nova API 会执行策略检查、配额检查和参数校验，确认镜像、规格、网络等引用是否有效。随后 Nova 创建实例记录和 Build Request，并把调度请求交给后续组件。
常见失败点：
- 项目实例、核心数、内存或端口配额不足。
- flavor、image、network 或 keypair 不存在。
- 用户缺少对应策略权限。
- 指定可用区或主机无效。
## 4. Scheduler 与 Placement 选择计算节点
nova-scheduler 从 Placement 获取候选资源提供者，先过滤不满足条件的主机，再根据权重选择目标计算节点。判断条件可能包括：
- vCPU、内存和本地磁盘是否足够。
- 可用区与主机聚合是否匹配。
- flavor extra specs 是否满足。
- NUMA、CPU pinning、Huge Page、GPU 或 PCI/SR-IOV 资源是否可用。
- 镜像、卷和网络是否带有额外约束。
遇到 NoValidHost 时，不要只看 hypervisor 剩余资源，还应检查 Placement allocation、主机聚合、extra specs、PCI 库存、禁用的计算服务和 nova-scheduler 日志。
## 5. Neutron 准备网络
Nova 请求 Neutron 创建或绑定端口。端口包含 MAC、固定 IP、安全组、绑定主机和 VNIC 类型等信息。普通虚拟网卡通常使用 normal，SR-IOV 场景可能使用 direct。
网络准备可能涉及：
- 从子网地址池分配固定 IP。
- 生成或更新 Neutron Port。
- 应用安全组和 QoS 策略。
- 由 OVS、OVN、Linux Bridge 或 SR-IOV 机制驱动完成绑定。
- 配置 DHCP、L2 转发与路由能力。
若实例卡在 networking 阶段，应检查端口状态、binding 信息、相关 agent、机制驱动日志和底层物理网络映射。
## 6. Glance 与 Cinder 准备启动盘
镜像启动时，nova-compute 从 Glance 获取镜像，缓存到计算节点并通过虚拟化驱动创建磁盘。卷启动时，Cinder 根据镜像创建卷或使用已有卷，再通过存储后端把设备连接到计算节点。
两种方式的区别：
- 镜像加本地临时盘：实例删除后根盘通常随之消失，创建速度和性能取决于本地存储。
- Boot from Volume：根盘由 Cinder 管理，可设置实例删除时是否保留，更适合需要持久化的场景。
## 7. nova-compute 创建虚拟机
目标计算节点上的 nova-compute 通过 libvirt/KVM 等虚拟化驱动：
1. 准备镜像或连接卷。
2. 创建网络接口并完成端口绑定。
3. 生成实例 XML 和设备配置。
4. 启动虚拟机进程。
5. 回报实例、任务和电源状态。
cloud-init 可以从 Metadata Service 或 Config Drive 获取主机名、SSH 公钥、用户数据和网络配置。镜像没有正确安装 cloud-init 时，密钥或初始化脚本可能不会生效。
## 8. 创建完成后的验证
```bash
openstack server show demo-vm
openstack server event list demo-vm
openstack port list --server demo-vm
openstack console log show demo-vm
openstack volume list --server demo-vm
```
至少确认：实例为 ACTIVE、任务状态为空、端口为 ACTIVE、固定 IP 正确、安全组符合预期、控制台无启动错误，并从目标网络实际测试连通性。
## 9. 一条实用排障链路
创建失败时按顺序定位：
1. 客户端认证、Endpoint 和项目是否正确。
2. Nova API 是否接受请求，配额是否足够。
3. Scheduler 是否找到候选主机。
4. Placement 库存和 allocation 是否一致。
5. Neutron 端口是否成功绑定。
6. Glance 镜像或 Cinder 卷是否可用。
7. nova-compute、libvirt 和底层存储是否正常。
8. 修复后重新创建，并验证用户实际访问路径。
不要直接修改 Nova、Neutron 或 Cinder 数据库来“修状态”。应先确认真实资源状态，再使用受支持的 API、管理命令或恢复流程。
## 参考资料
- https://docs.openstack.org/nova/latest/install/get-started-compute.html
- https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html