简介这份《openstack命令手册.docx》面向云计算运维人员、OpenStack初学者及备考相关认证的技术人员聚焦于解决日常运维中命令零散、查询不便的问题。资源以文档形式系统梳理了OpenStack各核心服务的常用命令涵盖主机、认证、镜像、计算、网络、块存储及虚拟机管理七大模块并按查询类与编辑类分别归类便于按需检索。压缩包内共1个docx文件约20KB体积轻巧适合本地留存或随查随用。内容不仅列出命令语法还附有域、项目、用户、角色、服务及API端点等创建样例与注解说明如openstack domain create、glance image-create、nova boot等典型操作均有示例并包含更新、删除、禁用等维护类命令。目前已有411人学习下载适合希望快速上手OpenStack命令体系、提升排障与配置效率的读者参考。1. OpenStack 命令手册从一堆记不住的指令到能排障的实战地图刚接手一套 OpenStack 环境时最让人头大的不是架构图而是几十个客户端命令和它们背后那套「资源 ID 套资源 ID」的逻辑。openstack server list能跑通不代表你知道虚机卡在ERROR时该查哪一层openstack network show看得懂输出不代表你能顺着 port、router、agent 一路定位到流量为什么不通。这份命令手册要解决的就是这件事把 OpenStack 散落在各服务里的命令按「日常运维 故障排查」两条线重新组织成一张能照着敲、敲完能验证的地图。它适合两类人一是刚用 kolla 或手动方式把 OpenStack 云平台搭起来面对一堆服务不知道从哪下手的运维新手二是已经会几条基础命令但遇到虚机起不来、网络不通、卷挂不上时只能重启服务碰运气的熟手。下面不讲空泛概念直接按命令分组、参数含义、输出怎么读、报错怎么查的顺序展开目标是让你合上文章就能在自己的环境里复现一遍。2. 先把认证和客户端理顺命令敲不动多半卡在这2.1 环境变量与 clouds.yaml 的取舍OpenStack 命令能不能执行第一道坎是认证。传统做法是 source 一个openrc文件把OS_AUTH_URL、OS_USERNAME、OS_PROJECT_NAME这些变量灌进当前 shell。这种方式在单环境里够用但一旦你同时管着测试和生产两套云来回 source 就会翻车——上一条命令还在测试环境删东西下一条就打到生产上了。更稳的做法是用clouds.yaml让客户端按名字选环境。文件一般放在~/.config/openstack/clouds.yaml或/etc/openstack/clouds.yamlclouds: test-cloud: auth: auth_url: http://10.0.0.10:5000/v3 username: admin password: your-password project_name: admin user_domain_name: Default project_domain_name: Default region_name: RegionOne interface: internal identity_api_version: 3写完用openstack --os-cloud test-cloud server list验证。这里几个参数值得说清楚interface选internal还是public取决于你的 endpoint 注册方式选错了会报连接超时identity_api_version: 3对应 Keystone v3老环境如果是 v2 要去掉 domain 相关字段。region_name在多 region 环境里必须显式指定否则客户端可能随机挑一个。提示clouds.yaml里存了明文密码权限设成600别丢进 git。2.2 客户端版本与服务端 API 的错位openstack这个统一客户端本质是个插件集合每个服务对应一个插件包比如python-novaclient、python-neutronclient。你本地装的客户端版本比服务端 API 新太多时某些命令会报HttpException: 404或者参数不识别。排查方法很简单# 看客户端整体版本 openstack --version # 看某个服务的 API 版本 openstack versions showversions show会列出每个服务当前支持的 API 版本区间。如果你要用的命令在文档里存在但本地报「unrecognized arguments」八成是客户端插件太旧升级对应插件包即可。反过来服务端是老版本比如 Newton 之前新客户端的一些批量操作命令会直接失败这时候要么降客户端要么改用各服务自己的原生命令比如nova、neutron、cinder这些老客户端。2.3 用 help 和 --debug 把黑匣子打开命令记不住参数是常态openstack help 子命令能给出当前客户端实际支持的参数列表比翻在线文档准因为文档可能对应的是别的版本。真正排障时--debug是后悔药级别的存在openstack --debug server show server-id它会把完整的 HTTP 请求 URL、请求头、请求体、响应码、响应体全打出来。很多「命令没反应」「报错信息含糊」的问题加上--debug就能看到服务端返回的真实错误比如409 Conflict后面跟着的具体原因。代价是输出很长建议配合21 | tee debug.log存下来慢慢看。3. 计算与镜像命令虚机从创建到排障的完整链路3.1 镜像、flavor、网络三件套的准备命令创建虚机前先把三个前置资源确认清楚否则server create会以各种奇怪的理由失败。# 查看可用镜像关注 ID、状态、大小 openstack image list --status active # 查看 flavor关注 vcpu、ram、disk openstack flavor list # 查看租户网络和子网 openstack network list openstack subnet listimage list里状态必须是active如果是queued或saving说明镜像还没传完这时候创建虚机会卡在scheduling。flavor list要留意disk字段如果填 0 表示使用镜像本身的磁盘大小填了具体数字则会按该大小创建根盘选错会导致虚机磁盘比预期小。network list拿到网络 ID 后创建时用--nic net-id网络ID指定不指定的话可能落到默认网络上后续排查会多一层干扰。3.2 server create 的关键参数与创建后验证一条能用的创建命令长这样openstack server create \ --flavor m1.small \ --image image-id \ --nic net-idnetwork-id \ --security-group default \ --key-name mykey \ --availability-zone nova \ my-test-vm参数逐个说--flavor和--image是硬性依赖--nic可以写多次来挂多网卡--security-group不指定会走默认安全组默认组通常只放行同组内流量所以虚机起来后 ping 不通、ssh 连不上先查安全组--key-name是你提前用openstack keypair create导入的公钥名没配的话虚机没有登录凭证--availability-zone在多 AZ 环境里决定调度到哪个故障域。创建后别急着等用这条命令盯状态openstack server show my-test-vm -c status -c addresses -c faultstatus从BUILD变ACTIVE是正常如果变ERRORfault字段会给出原因常见的是No valid host was found资源不足或调度失败和PortBindingFailed网络侧绑定失败。addresses字段确认虚机拿到了 IP拿不到 IP 说明 DHCP 或网络配置有问题往 Neutron 方向查。3.3 虚机操作类命令的边界日常操作命令本身简单但边界要清楚openstack server stop id # 正常关机走 ACPI openstack server start id # 开机 openstack server reboot id # 软重启 openstack server reboot --hard id # 硬重启相当于拔电源 openstack server resize --flavor new-flavor id # 改规格 openstack server migrate id # 冷迁移 openstack server live-migrate id # 热迁移resize之后虚机进入VERIFY_RESIZE状态必须再执行openstack server resize confirm id才算完成忘了 confirm 会一直挂着。live-migrate依赖计算节点之间能互通迁移网络且目标节点有足够资源失败时用--debug看具体卡在哪一步。删除虚机用openstack server delete id如果虚机卡在ERROR删不掉可以加--force但要注意这不会清理底层残留的卷和网络端口。4. 网络命令从 port 到 router 的排障顺序4.1 网络资源的层级关系Neutron 的资源是层层嵌套的network 下面有 subnetsubnet 上挂 portport 绑定到虚机或 router 接口router 负责跨子网转发。排障时按这个层级从上往下或从下往上走别跳步。# 看网络和子网 openstack network show network-id openstack subnet show subnet-id # 看端口重点看 device_id 和 binding:vif_type openstack port list --network network-id openstack port show port-id # 看路由和路由接口 openstack router list openstack router show router-idport show里的device_id指向占用这个端口的虚机或 routerbinding:vif_type是ovs还是bridge决定了底层用哪种虚拟交换方式。如果binding:vif_type是unbound说明端口没绑定成功虚机网络肯定不通。4.2 用 agent 状态定位节点侧问题网络不通很多时候不是配置错而是某个节点上的 agent 挂了。先看 agent 列表openstack network agent list输出里关注Alive和State两列。Alive为False说明 agent 心跳断了State为Down说明 agent 进程在但服务异常。常见的 agent 有Open vSwitch agent负责 OVS 流表、DHCP agent负责分配 IP、L3 agent负责路由和 NAT、Metadata agent负责元数据服务。哪类 agent 挂了对应功能就失效DHCP agent 挂了虚机拿不到 IPL3 agent 挂了跨子网不通也上不了外网。定位到具体节点后登录该节点看服务日志路径一般是/var/log/neutron/下对应的openvswitch-agent.log、dhcp-agent.log、l3-agent.log。日志里搜ERROR和Traceback比在控制节点瞎猜快得多。4.3 安全组和浮动 IP 的验证命令虚机有 IP 但连不上先排除安全组openstack security group list openstack security group rule list sg-id默认安全组通常只有出方向和同组入方向规则要放行 ssh 得自己加openstack security group rule create \ --protocol tcp --dst-port 22 --remote-ip 0.0.0.0/0 sg-id需要外网访问时挂浮动 IPopenstack floating ip create external-network openstack server add floating ip server-id floating-ip浮动 IP 不通检查三处外部网络是否真的能路由、router 是否设置了外部网关openstack router set --external-gateway ext-net router-id、以及 L3 agent 所在节点的 NAT 规则是否正常。这三处任何一处缺失浮动 IP 都只是挂了个寂寞。5. 存储与编排命令卷挂载和栈部署的常见坑5.1 卷的创建、挂载与状态确认Cinder 卷的操作链路是创建、挂载、确认、卸载、删除openstack volume create --size 20 my-volume openstack volume list openstack server add volume server-id volume-id openstack volume show volume-id -c status -c attachmentsvolume create后状态从creating变available才能挂载。挂载后状态变in-useattachments字段会显示挂到了哪台虚机。如果一直卡在creating多半是后端存储LVM、Ceph 等出问题去控制节点看/var/log/cinder/cinder-volume.log。卸载用openstack server remove volume卸载后状态回到available才能删除。虚机里还需要手动识别新盘并格式化挂载这一步是操作系统层面的OpenStack 命令管不到。5.2 Heat 编排栈的调试方法用 Heat 部署一套资源时栈创建失败是家常便饭openstack stack create -t my-template.yaml my-stack openstack stack list openstack stack show my-stack openstack stack resource list my-stack openstack stack event list my-stackstack show看整体状态CREATE_FAILED说明有资源没建起来。resource list列出栈里每个资源的状态找到那个CREATE_FAILED的。event list按时间顺序打出每个资源的事件和错误信息这是定位根因的关键错误信息通常直接告诉你哪个参数不对或哪个资源冲突。调模板时建议先用openstack stack create --dry-run做语法和参数校验能省掉不少无效等待。6. 避坑与排查命令手册里不会写的五条血泪经验6.1 现象server list 返回空但虚机明明在跑原因当前认证的项目project不对。OpenStack 资源是按项目隔离的admin 项目看不到 demo 项目的虚机。解决openstack --os-project-name demo server list显式指定项目或者检查clouds.yaml里的project_name是否写错。6.2 现象命令报 401 Unauthorized 但密码没错原因token 过期或 Keystone endpoint 配错。token 默认有效期几小时过期后所有命令都 401。解决重新 source 环境变量或确认clouds.yaml里的auth_url指向正确的 Keystone 地址和端口v3 是 5000。如果auth_url写成了 VIP 但 VIP 没起来也会 401。6.3 现象虚机 ACTIVE 但 ssh 连不上原因安全组没放行、浮动 IP 没挂、或者虚机内部防火墙拦截。解决按顺序查——security group rule list确认 22 端口放行server show确认有浮动 IPport show确认端口绑定正常最后登录虚机看内部iptables或firewalld。四步里任何一步断了都连不上。6.4 现象删除网络时报「Network in use」原因还有 port 挂在这个网络上通常是虚机没删干净或 router 接口没摘。解决openstack port list --network net-id找出残留 port先删虚机或摘 router 接口再删 port最后删网络。直接--force删网络会留下孤儿 port后患无穷。6.5 现象live-migrate 卡在 migrating 不动原因迁移网络不通或目标节点资源不足。解决先确认计算节点之间迁移网络能通再openstack compute service list看目标节点是否enabled且up最后看目标节点剩余资源是否够。卡住超过预期时间可以用openstack server migrate --wait加超时或者直接 abort 后改用冷迁移。7. 把命令手册变成自己的排障脚本命令敲多了会发现真正高频的就那么几十条而且排障时往往是固定顺序的一串。与其每次翻手册不如把常用组合封装成 shell 函数或小脚本。比如我习惯把「查虚机全貌」做成一个函数osvm() { local id$1 openstack server show $id -c status -c addresses -c fault openstack port list --server $id -f value -c ID | while read -r pid; do echo --- port $pid --- openstack port show $pid -c binding:vif_type -c device_id done }这个函数先看虚机状态和故障信息再顺着端口查绑定情况一条命令把计算和网络两层串起来。参数上-f value -c ID是让输出只保留端口 ID方便管道处理-c指定列能大幅缩短输出排障时比默认的全字段输出好用得多。再进一步可以把常见故障的判断逻辑写成检查清单脚本认证是否正常、各 agent 是否 alive、虚机状态分布、卷状态分布、浮动 IP 占用情况。每次环境异常先跑一遍能快速缩小范围。命令手册的价值不在于背下来而在于你知道遇到哪类问题该敲哪几条、输出里哪个字段是关键、报错该往哪个日志翻。我自己踩过最深的坑是遇到问题就重启服务后来发现九成问题用--debug加对应服务日志就能定位重启只是把问题藏起来。希望这套按链路组织的命令用法能帮你少走几次重启的弯路。本文还有配套的精品资源点击获取