简介：本资源是一份面向OpenStack初学者与运维工程师的实用命令速查手册，聚焦网络计算场景下的核心服务操作，帮助用户快速掌握平台日常管理与故障排查所需CLI指令。文档以结构化方式系统梳理了主机基础命令、Keystone认证、Glance镜像、Nova计算、Neutron网络、Cinder块存储及虚拟机全生命周期管理等7大模块，覆盖查询、创建、编辑、启停、删除等高频操作，并附带典型命令语法、参数说明与使用示例，便于现场查阅与实操验证。资源为单文件Word文档（.docx），体积精简仅20KB，内容完整、排版清晰，适合作为随身备忘或培训辅助材料。目前已有411人学习下载，目录层级明确、分类细致，从主机网络配置到API端点创建均有详述，特别适合部署调试阶段快速定位命令、降低学习门槛。
1. 这不是一本“翻着看”的文档：OpenStack 命令手册的本质是运维工程师的实时决策支持系统
你手头那份openstack命令手册.docx，大概率不是用来“收藏吃灰”的 Word 文件——它真正该在的地方，是终端窗口旁、故障排查时、CI/CD 流水线卡点处、甚至凌晨三点告警弹窗亮起的那一刻。OpenStack 命令行工具（CLI）从来不是 Linux 基础命令的简单叠加，而是一套面向多租户、多服务、多状态云资源的强语义操作协议：openstack server list --status ACTIVE --project demo这条命令背后，实际触发的是 keystone 认证、nova 查询、neutron 网络状态聚合、cinder 卷挂载校验四层服务协同；一个--os-compute-api-version 2.93参数的缺失，可能让脚本在 Wallaby 和 Yoga 版本间彻底失效。这份手册的价值，不在于罗列所有子命令，而在于帮你在 30 秒内判断该用openstack volume show还是cinder volume-show，该加--os-region-name RegionOne还是--os-auth-url https://controller:5000/v3，以及为什么openstack image set --property hw_disk_bus=virtio能让 Windows 镜像启动速度提升 40%。适合刚通过 Packstack 搭建完最小化 OpenStack 环境的运维新人，也适合需要把 CLI 深度嵌入自动化流程的 SRE 工程师——前提是，你得先搞懂命令背后的上下文约束，而不是复制粘贴就跑。
2. 从环境初始化到命令执行：OpenStack CLI 的五层可信链构建
OpenStack CLI 不是apt install python-openstackclient之后就能直接敲openstack server create的工具。它的每一次成功执行，都依赖于一条从操作系统层穿透到云服务 API 层的完整信任链。跳过任何一层，轻则报错HTTP 401 Unauthorized，重则误删生产环境镜像。我一般会按以下五层顺序逐级验证，每层失败都对应明确的排错路径：
2.1 环境变量与认证凭证：.rc文件不是摆设，而是运行时契约
OpenStack CLI 默认从环境变量读取认证信息，而非配置文件。最稳妥的做法是使用官方推荐的admin-openrc.sh（或demo-openrc.sh）脚本加载：
# 示例：admin-openrc.sh 内容（需根据实际部署修改） export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=admin export OS_USERNAME=admin export OS_PASSWORD=ADMIN_PASS export OS_AUTH_URL=https://controller:5000/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 export OS_VOLUME_API_VERSION=3 export OS_COMPUTE_API_VERSION=2.93 export OS_REGION_NAME=RegionOne export OS_INTERFACE=public export OS_ENDPOINT_TYPE=publicURL提示：
OS_AUTH_URL必须带协议（https://）、端口（5000）和 API 版本路径（/v3）；OS_INTERFACE=public决定 CLI 调用哪个 endpoint（public/internal/admin），多数生产环境只开放 public 接口；OS_COMPUTE_API_VERSION若不显式指定，CLI 会默认用最低兼容版本（如 2.1），导致部分新特性（如--config-drive true）不可用。
执行source admin-openrc.sh后，务必验证变量是否生效：
env | grep OS_ | sort # 应看到全部 OS_* 变量，且值非空 openstack token issue 2>/dev/null | grep -q "id" && echo "✅ 认证变量加载成功" || echo "❌ 认证失败"2.2 客户端版本与服务端 API 兼容性：别让openstack --version成为幻觉
OpenStack CLI（python-openstackclient）版本必须与后端服务 API 版本对齐。常见误区是认为“装最新版 client 就能兼容所有服务”，但事实是：
- Wallaby（2021.1）服务端要求 CLI ≥ 5.4.0 才支持
openstack volume backup create --force - Yoga（2022.1）引入
openstack server group create --policy soft-anti-affinity，需 CLI ≥ 6.1.0 - 若用 CLI 6.5.0 对接 Queens（2018.1）服务端，
openstack network qos rule create会直接报HTTP 404
验证方法分两步：
# 1. 查本地 CLI 版本及支持的 API 范围 openstack --version # 输出如 openstack 6.4.0 openstack help | head -20 | grep -E "(Compute|Image|Volume)" # 查看各服务帮助中隐含的 API 版本线索 # 2. 查服务端实际暴露的 API 版本（需管理员权限） openstack catalog list | grep -E "(compute|image|volume)" # 输出示例：| compute | compute | RegionOne | https://controller:8774/v2.1 | ... # 注意 v2.1 表示 Compute API 最高支持 2.1，此时 CLI 的 --os-compute-api-version 必须 ≤ 2.1参数说明：
--os-compute-api-version等参数可在单次命令中覆盖环境变量，例如openstack --os-compute-api-version 2.85 server list强制使用 2.85 版本，避免全局变量污染其他脚本。
2.3 Endpoint 可达性与 TLS 证书信任：curl 是比 openstack 更诚实的诊断员
即使环境变量正确、CLI 版本匹配，网络层问题仍会导致Connection refused或SSL certificate verify failed。不要直接openstack server list报错就放弃，先用底层工具验证：
# 1. 检查 Keystone endpoint 是否响应（绕过 CLI 认证逻辑） curl -k -H "Content-Type: application/json" \ -d '{"auth": {"identity": {"methods": ["password"],"password": {"user": {"name": "admin","domain": {"name": "default"},"password": "ADMIN_PASS"}}}}}' \ https://controller:5000/v3/auth/tokens 2>/dev/null | jq -r '.token.id' | head -c 8 # 2. 若返回 8 位 token 前缀，说明 HTTPS 通、Keystone 活；若报 SSL 错误，则需： # - 将 controller 的 CA 证书加入系统信任库（/etc/pki/ca-trust/source/anchors/） # - 或临时禁用验证（仅测试）：export OS_CACERT=/dev/null # 3. 验证 Compute endpoint（替换为实际 URL） curl -k -I https://controller:8774/v2.1 2>/dev/null | head -1 # 应返回 HTTP/1.1 200 OK 或 401 Unauthorized（表示服务可达，只是未认证）3. 核心资源操作命令：从创建、查询到故障定位的闭环指令集
OpenStack CLI 命令设计遵循 RESTful 资源模型，但实际使用中存在大量“非对称操作”——比如创建服务器时需指定 flavor/image/network，但查询时却要靠--status或--name过滤。本节聚焦最常使用的 4 类资源（Server、Image、Network、Volume），给出每个操作的最小必要参数组合、典型错误场景及替代方案对比。
3.1 Server（计算实例）：openstack server create的 7 个必填项与 3 个隐藏依赖
创建一台可用的虚拟机，绝不止--image--flavor--network三个参数。以下是我在 Packstack 部署环境中验证过的最小可行命令（Yoga 版本）：
openstack server create \ --image "cirros-0.6.2-x86_64-disk" \ --flavor m1.tiny \ --network provider \ --key-name mykey \ --security-group default \ --user-data /tmp/cloud-init.txt \ --config-drive true \ --wait \ web-server-01| 参数 | 为什么必须？ | 常见坑 |
|---|---|---|
--network provider | Packstack 默认只创建provider网络（Flat 类型），若用--network selfservice会报Network not found | 新手常误以为--nic net-id=...更灵活，实则--network自动处理 port 创建，--nic需手动管理 port 生命周期 |
--key-name mykey | 无密钥则无法 SSH 登录，且--user-data中的ssh_authorized_keys不生效 | openstack keypair create mykey > mykey.pem后必须chmod 600 mykey.pem，否则 CLI 提示Permission denied |
--config-drive true | Cirros 镜像依赖 config drive 获取 metadata，否则/var/lib/cloud/instances/为空 | 若省略，实例会启动但 cloud-init 不执行，--user-data失效 |
避坑逻辑：
--wait参数让 CLI 阻塞直到实例进入ACTIVE状态，避免脚本后续操作因实例未就绪而失败；但若超时（默认 300 秒），需检查 nova-scheduler 日志中是否有No valid host was found—— 这通常意味着 compute 节点资源不足或 placement service 未同步。
3.2 Image（镜像）：openstack image create的元数据陷阱与格式强制转换
上传镜像时，--disk-format和--container-format必须与实际文件格式严格匹配，否则 glance 会拒绝导入：
# 正确：Cirros qcow2 镜像 openstack image create \ --disk-format qcow2 \ --container-format bare \ --file cirros-0.6.2-x86_64-disk.img \ --public \ --property hw_qemu_guest_agent=yes \ --property os_require_quiesce=yes \ cirros-0.6.2-x86_64-disk # 错误示例（若实际是 raw 格式却声明 qcow2）： # openstack image create --disk-format qcow2 --file ubuntu-22.04-server-cloudimg-amd64.img ... # 报错：Invalid disk format 'qcow2' for image参数说明：
--property设置的元数据直接影响实例行为。hw_qemu_guest_agent=yes启用 QEMU Guest Agent，使openstack server console log show可获取完整 boot log；os_require_quiesce=yes在创建快照时触发 guest fs freeze，避免数据不一致。
3.3 Network（网络）：openstack network create的 provider:physical_network 绑定规则
Packstack 默认创建provider网络，其关键在于--provider-physical-network和--provider-network-type的绑定：
# 创建 provider 网络（对应物理网卡 enp0s3） openstack network create \ --share \ --provider-network-type flat \ --provider-physical-network provider \ --external \ provider # 创建 selfservice 网络（需先有 provider 网络作为上联） openstack network create selfservice openstack subnet create \ --network selfservice \ --subnet-range 192.168.100.0/24 \ --gateway 192.168.100.1 \ --dns-nameserver 8.8.8.8 \ selfservice-subnet注意：
--provider-physical-network provider中的provider是 neutron 配置文件/etc/neutron/plugins/ml2/ml2_conf.ini中[ml2_type_flat]下定义的物理网络名，不是网卡名。若配置为flat_networks = datacentre，此处必须写--provider-physical-network datacentre，否则 neutron-server 日志报Physical network datacentre is not configured。
3.4 Volume（块存储）：openstack volume create的 cinder-volume 服务状态依赖
创建卷前，必须确认cinder-volume服务在 compute 节点上运行且状态为up：
# 查看 cinder-volume 服务状态 openstack volume service list | grep -E "(host|State)" # 正常输出：| cinder-volume | controller | nova | up | ... | # 创建卷（需指定 size，单位 GB） openstack volume create \ --size 10 \ --type lvm \ --description "Boot volume for web-server" \ web-server-vol-01避坑逻辑：
--type lvm对应 cinder 配置中的enabled_backends = lvm，若 backend 名为ceph，此处必须写--type ceph；--size最小值由 cinder 配置min_volume_size = 1决定，若设为0.5会报Volume size cannot be less than 1。
4. 常见问题排查：那些让你重启服务前该先看的日志和命令
OpenStack CLI 报错信息往往高度抽象，直接 Google 错误码容易陷入无效搜索。我习惯按“CLI → API → Service → Log”四级递进排查，以下是最常踩的 5 个坑，每条都附带现象 → 原因 → 解决的闭环：
4.1 现象：openstack server list返回空列表，但 Horizon 控制台可见实例
原因：CLI 默认只查询当前 project（由OS_PROJECT_NAME指定），而 Horizon 可能以 admin 身份登录查看所有 project。
解决：
- 确认
OS_PROJECT_NAME值（echo $OS_PROJECT_NAME） - 若需查所有 project，加
--all-projects参数（需 admin 权限）：openstack server list --all-projects --long | grep -E "(ID|Name|Status)"
4.2 现象：openstack image create卡住不动，数分钟后报Timeout
原因：glance-api 服务未启动，或/var/lib/glance/images/目录权限错误（glance 用户无写入权）。
解决：
- 检查服务状态：
systemctl status openstack-glance-api - 修复目录权限：
sudo chown glance:glance /var/lib/glance/images/ sudo chmod 755 /var/lib/glance/images/ sudo systemctl restart openstack-glance-api
4.3 现象：openstack network list显示provider网络，但openstack server create --network provider报Network not found
原因：neutron-server 未将网络同步到 placement service，或--os-region-name与服务 catalog 中 region 不匹配。
解决：
- 查服务 catalog 中 network endpoint 的 region：
openstack catalog show network | grep region # 输出：| region_id | RegionOne | - 确保
OS_REGION_NAME=RegionOne（而非regionone或region-one） - 强制刷新 placement：
sudo systemctl restart openstack-nova-api openstack-placement-api
4.4 现象：openstack volume list显示available，但openstack server add volume失败，报Volume not in available state
原因：卷处于attaching状态（nova-compute 正在挂载），但 CLI 未等待状态变更。
解决：
- 查卷真实状态：
openstack volume show <VOLUME_ID> -f value -c status - 若为
attaching，等待 10~30 秒后重试，或加--wait参数：openstack server add volume --wait web-server-01 web-server-vol-01
4.5 现象：openstack server console log show <SERVER_ID>返回空内容
原因：实例未启用 QEMU Guest Agent，或hw_qemu_guest_agent=yes未在镜像 property 中设置。
解决：
- 检查镜像属性：
openstack image show cirros-0.6.2-x86_64-disk | grep hw_qemu - 若无此属性，重新设置：
openstack image set --property hw_qemu_guest_agent=yes cirros-0.6.2-x86_64-disk - 重启实例使 guest agent 生效：
openstack server reboot --hard web-server-01
5. 进阶技巧：用openstack命令生成可审计、可回滚的基础设施快照
真正的运维价值不在“能创建资源”，而在“能证明资源为何存在、何时被修改、谁操作了它”。OpenStack CLI 提供了原生支持审计追踪的机制，无需额外工具。
5.1 用--os-cloud隔离多环境，避免source admin-openrc.sh的全局污染
.openstack/clouds.yaml是 CLI 的多云配置中心，比反复source更安全：
# ~/.openstack/clouds.yaml clouds: packstack-prod: auth: auth_url: https://controller:5000/v3 username: admin password: ADMIN_PASS project_name: admin user_domain_name: Default project_domain_name: Default region_name: RegionOne identity_api_version: 3 image_api_version: 2 packstack-dev: auth: auth_url: https://dev-controller:5000/v3 # ... 其他字段之后所有命令加--os-cloud packstack-prod即可切换上下文：
openstack --os-cloud packstack-prod server list --long > prod-servers-$(date +%F).csv openstack --os-cloud packstack-dev image list --long > dev-images-$(date +%F).csv优势：避免环境变量泄漏；支持 CI/CD 中不同 stage 使用不同 cloud；
openstack cloud list可快速查看已配置云。
5.2 用openstack server event list追溯实例生命周期事件
每个server createserver delete操作都会在 nova 数据库中记录 event，CLI 可直接查询：
# 查某实例的所有事件（含时间戳、用户、状态变更） openstack server event list --server web-server-01 --long # 输出关键字段： # | Event | Started At | Result | User ID | # | attach_interface | 2023-10-05T08:22:11Z | Success | 2a1b3c4d5e6f7g8h9i0j1k2l3m4n5o6p | # | compute_create | 2023-10-05T08:21:55Z | Success | 2a1b3c4d5e6f7g8h9i0j1k2l3m4n5o6p |审计价值：
User ID可关联 keystone user，Started At提供精确时间线，Result区分成功/失败。配合openstack user show <USER_ID>即可定位操作人。
5.3 用openstack resource save导出资源状态为 JSON，实现基础设施即代码（IaC）基线
OpenStack CLI 本身不提供terraform plan，但可通过导出当前状态建立基线：
# 导出所有核心资源为结构化 JSON openstack server list --long --format json > servers.json openstack image list --long --format json > images.json openstack network list --long --format json > networks.json openstack volume list --long --format json > volumes.json # 后续可用 diff 工具比对变更（如 git diff servers.json） # 或用 jq 提取关键字段做合规检查： jq -r '.[] | select(.Status == "ERROR") | .Name' servers.json血泪经验：
--format json输出包含created_atupdated_at字段，是判断资源是否被意外修改的关键依据；--long参数确保输出所有字段，避免--format csv丢失 nested object（如 security_groups）。
我坚持把每次openstack server create都配上--description "Created by $USER on $(date)"，并在 Git 仓库中存档所有.json快照——不是为了炫技，而是当某天有人问“这台服务器为什么存在”，我能直接git blame servers.json指向当年的 commit 和 PR 链接。命令手册的价值，最终体现在你能否用它回答“谁、何时、为何、做了什么”这四个问题。希望帮到你。
本文还有配套的精品资源，点击获取
