简介本资源是一份面向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_busvirtio能让 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_NAMEDefault export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_NAMEadmin export OS_USERNAMEadmin export OS_PASSWORDADMIN_PASS export OS_AUTH_URLhttps://controller:5000/v3 export OS_IDENTITY_API_VERSION3 export OS_IMAGE_API_VERSION2 export OS_VOLUME_API_VERSION3 export OS_COMPUTE_API_VERSION2.93 export OS_REGION_NAMERegionOne export OS_INTERFACEpublic export OS_ENDPOINT_TYPEpublicURL提示OS_AUTH_URL必须带协议https://、端口5000和 API 版本路径/v3OS_INTERFACEpublic决定 CLI 调用哪个 endpointpublic/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 CLIpython-openstackclient版本必须与后端服务 API 版本对齐。常见误区是认为“装最新版 client 就能兼容所有服务”但事实是Wallaby2021.1服务端要求 CLI ≥ 5.4.0 才支持openstack volume backup create --forceYoga2022.1引入openstack server group create --policy soft-anti-affinity需 CLI ≥ 6.1.0若用 CLI 6.5.0 对接 Queens2018.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 providerPackstack 默认只创建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 trueCirros 镜像依赖 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_agentyes \ --property os_require_quiesceyes \ 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_agentyes启用 QEMU Guest Agent使openstack server console log show可获取完整 boot logos_require_quiesceyes在创建快照时触发 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-api4.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 的 regionopenstack catalog show network | grep region # 输出| region_id | RegionOne |确保OS_REGION_NAMERegionOne而非regionone或region-one强制刷新 placementsudo systemctl restart openstack-nova-api openstack-placement-api4.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-014.5 现象openstack server console log show SERVER_ID返回空内容原因实例未启用 QEMU Guest Agent或hw_qemu_guest_agentyes未在镜像 property 中设置。解决检查镜像属性openstack image show cirros-0.6.2-x86_64-disk | grep hw_qemu若无此属性重新设置openstack image set --property hw_qemu_guest_agentyes cirros-0.6.2-x86_64-disk重启实例使 guest agent 生效openstack server reboot --hard web-server-015. 进阶技巧用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 使用不同 cloudopenstack cloud list可快速查看已配置云。5.2 用openstack server event list追溯实例生命周期事件每个server createserver delete操作都会在 nova 数据库中记录 eventCLI 可直接查询# 查某实例的所有事件含时间戳、用户、状态变更 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 userStarted 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 链接。命令手册的价值最终体现在你能否用它回答“谁、何时、为何、做了什么”这四个问题。希望帮到你。本文还有配套的精品资源点击获取