简介这份《openstack命令手册.docx》面向云计算运维人员、OpenStack初学者及备考相关认证的技术人员用于解决日常部署与运维中命令零散、查询不便的问题。资源包共1个docx文件约20KB以文档形式系统整理命令条目便于随身查阅与快速检索。内容按主机、认证、镜像、计算、网络、块存储、虚拟机管理七大模块编排每类下细分查询类与编辑类操作涵盖网络接口与IP信息查看、域/项目/用户/角色/服务列表查询与创建、镜像上传与安全组查看、nova与neutron服务状态检查、cinder组件信息、虚拟机创建暂停重启删除等常用指令并附有命令语法与样例说明。目录层级清晰从基础主机配置到各核心服务运维均有覆盖适合作为日常运维速查表或学习OpenStack命令体系的入门参考。目前已有411人学习下载。1. 从一份 docx 命令手册说起OpenStack 运维到底该背哪些命令刚接手一套 OpenStack 环境时最抓狂的不是架构有多复杂而是明明知道某个资源出问题了却想不起该敲哪条命令去查。控制节点上systemctl一长串服务名计算节点上nova、neutron、cinder各自的配置文件散落在/etc下认证、镜像、网络、块存储、虚拟机管理五六个模块的命令混在一起靠脑子记根本不现实。这份《OpenStack 命令手册.docx》解决的就是这个问题——它把主机、认证Keystone、镜像Glance、计算Nova、网络Neutron、块存储Cinder、虚拟机管理以及项目/用户/角色管理这几大块的常用命令按「查询类」和「编辑类」分好了类每条命令都带语法说明和样例。适合刚接触 OpenStack 云平台搭建与日常运维的工程师也适合已经能跑通部署、但排查故障时总在翻文档的人。它不教你架构原理就是一本能放在手边随时查的操作手册。2. 主机与认证服务从网卡配置到 Keystone 四件套2.1 主机层的网络接口与 IP 信息操作OpenStack 所有节点都跑在 Linux 主机上主机层的网络配置是所有服务通信的基础。手册里主机部分集中在/etc/sysconfig/network-scripts/和/etc/hosts这两个位置操作本身不复杂但改错了会导致节点之间 API 调用直接断掉。查询网络接口配置# 查看指定网卡的配置文件内容ens160 是网卡名实际环境可能是 ens192、eth0 等 cat /etc/sysconfig/network-scripts/ifcfg-ens160这条命令输出的是网卡的 IP 分配方式BOOTPROTO、IP 地址、子网掩码、网关、DNS 等关键字段。改之前先cat一遍留个底这是血泪经验——直接vim进去改完保存万一改错了连 SSH 都连不上只能去机房接显示器。查询主机 IP 和主机名信息# 查看所有网卡的 IP 地址确认管理网、业务网、存储网分别绑在哪块网卡上 ifconfig # 查看本机主机名 cat /etc/hostname # 查看主机名与 IP 的映射关系OpenStack 各节点之间靠这个做名称解析 cat /etc/hostsifconfig虽然在新版系统中逐渐被ip addr替代但在 CentOS 7 系的 OpenStack 环境里仍然是标配。/etc/hosts这个文件特别关键——控制节点、计算节点、网络节点的主机名和 IP 必须在这里写全否则 Keystone 认证时返回的 endpoint 地址可能解析不到表现为openstack命令全部超时。编辑操作就是把上面的cat换成vim# 编辑网卡配置改完需要重启网络服务或重启网卡 vim /etc/sysconfig/network-scripts/ifcfg-ens160 # 编辑主机名与 IP 映射 vim /etc/hosts改完网卡配置后常见做法是systemctl restart network或nmcli connection reload具体用哪个取决于系统用的是 network 还是 NetworkManager。改/etc/hosts不需要重启任何服务保存即生效。2.2 Keystone 认证服务的查询命令链路Keystone 是 OpenStack 的认证入口所有openstack命令执行前都要先 source 环境变量文件拿到 token。手册里认证服务的查询命令覆盖了域、项目、用户、角色、服务、端点六个维度这几条命令基本就是日常巡检的固定动作。先确认 Apache 服务状态因为 Keystone 通常跑在 Apache 的 WSGI 里# 查看 httpd 服务运行状态 systemctl status httpd.service # 查看 Apache 日志目录下的日志文件 cd /etc/httpd/logs tail -f keystone_access.logsystemctl status输出里重点看Active那一行是active (running)还是failed。如果 Keystone 认证异常先看 httpd 活没活着再看日志里有没有 401、403 或连接数据库失败的报错。然后是 OpenStack 层面的查询命令# 查看域列表确认 default 域是否存在且 Enabled 为 True openstack domain list # 查看项目列表 openstack project list # 查看用户列表 openstack user list # 查看角色列表 openstack role list # 查看服务列表确认 glance、nova、neutron、cinder 等服务是否注册 openstack service list # 查看 API 端点列表确认每个服务的 public、internal、admin 三个端点 URL 是否正确 openstack endpoint listopenstack endpoint list这条命令在排查服务调用失败时特别有用。输出里的URL字段如果指向了一个不可达的 IP 或者端口号写错了上层服务就会报连接超时。常见的情况是部署时控制节点 IP 变了但 endpoint 还指着旧 IP这时候所有跨节点 API 调用都会挂。2.3 创建域、项目、用户、角色与服务的完整流程认证服务的编辑类命令有一套固定的先后顺序先建域再建项目然后建用户接着建角色并把角色分配给用户和项目最后注册服务和端点。手册里给出的样例可以直接抄。创建域# 创建一个名为 example 的域附带描述信息 openstack domain create --description An Example Domain example创建项目# 在 default 域下创建名为 service 的项目 openstack project create --domain default --description Service Project service创建用户# 在 default 域下创建用户 demo执行后会提示输入密码 openstack user create --domain default --password-prompt demo--password-prompt会交互式让你输两遍密码比直接在命令里写明文密码安全。如果是在脚本里批量创建可以用--password直接指定但要注意命令历史泄露密码的风险。创建角色并分配给项目中的用户# 创建名为 user 的角色 openstack role create user # 把 user 角色分配给 hzab 项目中的 hq 用户 openstack role add --project hzab --user hq user创建服务并注册端点# 注册 glance 镜像服务类型为 image openstack service create --name glance --description OpenStack Image image # 为 glance 服务创建三个端点分别对应 public、internal、admin openstack endpoint create --region RegionOne image public http://172.26.128.126:9292 openstack endpoint create --region RegionOne image internal http://172.26.128.126:9292 openstack endpoint create --region RegionOne image admin http://172.26.128.126:9292这里有个容易翻车的点一个服务必须创建 public、internal、admin 三个端点少一个都可能导致某些操作失败。比如只有 public 没有 admin管理员执行某些命令时就会报找不到端点。三个端点的 URL 在小规模环境里通常一样但生产环境可能会分开走不同的网络平面。3. 镜像、计算、网络、块存储四大核心服务的命令实操3.1 Glance 镜像服务的查询与上传Glance 负责镜像的存储和管理查询类命令主要看服务状态和镜像列表。# 查看 glance 两个核心服务的状态 systemctl status openstack-glance-api.service openstack-glance-registry.service # 查看镜像列表关注 Status 是否为 active openstack image list # 查看某个具体镜像的详细信息 openstack image show cirros-0.3.4-x86_64-disk # 查看安全组列表 openstack group listopenstack-glance-api.service是 Glance 的入口接收用户请求openstack-glance-registry.service负责和数据库交互。两个都必须是active (running)缺一个镜像服务就不可用。openstack image list输出里Status为active才表示镜像可用如果是queued或saving说明上传还没完成或者卡住了。上传镜像的完整流程# 第一步下载一个测试用的 cirros 镜像 wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img # 第二步上传镜像到 Glance openstack image create test1 \ --file cirros-0.3.4-x86_64-disk.img \ --disk-format qcow2 \ --container-format bare \ --public--disk-format指定镜像的磁盘格式常见的有raw、qcow2、vmdk。qcow2支持写时复制和快照是 KVM 环境下最常用的格式。--container-format bare表示裸容器格式没有额外的元数据封装。--public让所有项目都能看到这个镜像不加的话只有当前项目可见。3.2 Nova 计算服务的状态检查与配置维护Nova 是 OpenStack 最核心也最复杂的服务手册里列了七个 systemd 服务单元每个都有明确职责。# 一次性查看所有 nova 相关服务状态 systemctl status openstack-nova-api.service \ openstack-nova-consoleauth.service \ openstack-nova-scheduler.service \ openstack-nova-conductor.service \ openstack-novncproxy.service \ libvirtd.service \ openstack-nova-compute.service这七个服务里nova-api是入口nova-scheduler决定虚拟机调度到哪台宿主机nova-conductor隔在 compute 和数据库之间避免直接访问nova-compute负责实际创建和销毁虚拟机libvirtd是底层虚拟化守护进程。任何一个挂了虚拟机的创建、启动、删除都会出问题。# 查看 nova 各组件是否正常注册到消息队列 openstack compute service list # 检查 nova 组件升级后的状态 nova-status upgrade checkopenstack compute service list输出里State为up、Status为enabled才算正常。如果某个 compute 节点显示down先检查该节点的nova-compute服务是否在跑再看消息队列通常是 RabbitMQ是否可达。编辑 nova 配置# 编辑 nova 主配置文件 vim /etc/nova/nova.confnova.conf里改完参数后需要重启对应的服务才能生效。常见做法是改完nova.conf后systemctl restart openstack-nova-api openstack-nova-scheduler openstack-nova-conductor计算节点上还要重启openstack-nova-compute。3.3 Neutron 网络服务的组件状态与配置文件Neutron 的组件比 Nova 更分散手册里列了四个核心服务。# 查看 neutron 四个核心服务状态 systemctl status neutron-server.service \ neutron-linuxbridge-agent.service \ neutron-dhcp-agent.service \ neutron-metadata-agent.serviceneutron-server接收 API 请求创建网络、子网、路由器neutron-linuxbridge-agent负责实际的二层网络转发neutron-dhcp-agent为虚拟机提供 DHCP 服务neutron-metadata-agent让虚拟机能够访问 Nova 的 metadata 服务。这四个服务通常分布在控制节点和网络节点上排查时要先确认在正确的节点上看。# 查看网络列表 openstack network list # 查看端口列表 openstack port listopenstack network list输出里的ID在创建虚拟机时要用到Subnets字段显示该网络关联的子网。openstack port list能看到每个端口绑定的 IP、MAC 和所属网络排查虚拟机网络不通时先看端口状态是不是ACTIVE。Neutron 的配置文件分布在多个位置# 编辑 neutron 主配置 vim /etc/neutron/neutron.conf # 编辑 ML2 插件配置ML2 是管理二层技术的框架 vim /etc/neutron/plugins/ml2/ml2_conf.ini # 编辑 linuxbridge agent 配置 vim /etc/neutron/plugins/ml2/linuxbridge_agent.ini # 编辑 DHCP agent 配置 vim /etc/neutron/dhcp_agent.ini # 编辑 metadata agent 配置 vim /etc/neutron/metadata_agent.iniML2Modular Layer 2是 Neutron 管理二层网络的核心框架可以同时支持 Linux Bridge、Open vSwitch 等多种二层技术。linuxbridge_agent.ini里配置的是物理网卡和虚拟网桥的映射关系改错了虚拟机就上不了网。dhcp_agent.ini控制 DHCP 服务的行为metadata_agent.ini里要填 Nova metadata 服务的地址和共享密钥。3.4 Cinder 块存储的服务状态与组件信息Cinder 提供持久化的块存储卷手册里列了三个核心服务。# 查看 cinder 服务及依赖的 target 服务状态 systemctl status openstack-cinder-volume.service \ target.service \ openstack-cinder-api.service \ openstack-cinder-scheduler.service # 查看 cinder 各组件注册信息 cinder service-listopenstack-cinder-api提供 HTTP 接口openstack-cinder-scheduler决定卷创建在哪个存储节点上openstack-cinder-volume通过驱动和底层存储交互target.service是 iSCSI 目标服务负责把卷暴露给计算节点。cinder service-list输出里每个组件的State为up才正常。# 编辑 cinder 主配置 vim /etc/cinder/cinder.confcinder.conf里主要配置数据库连接、消息队列、认证信息以及后端存储驱动。改完后重启openstack-cinder-api、openstack-cinder-scheduler、openstack-cinder-volume三个服务。4. 虚拟机全生命周期管理与项目用户角色操作4.1 创建虚拟机的五步准备与一条命令创建虚拟机之前需要先拿到四个关键信息网络 ID、规格名称、镜像名称、安全组名称。手册里把这一步拆得很清楚。# 第一步查看网络列表记下要使用的网络 ID openstack network list # 第二步查看规格列表选择虚拟机配置 openstack flavor list # 第三步查看镜像列表选择镜像 openstack image list # 第四步查看安全组列表 openstack security group list # 第五步创建虚拟机 openstack server create \ --image centos7.4-cloud \ --flavor vm-ram-01 \ --security-groups default \ --nic net-ide7f65cb4-1896-46b9-ae09-2fa141f1757c \ test06--nic net-id后面跟的是第一步查到的网络 ID这个参数最容易填错。如果网络 ID 写错了虚拟机会创建失败或者创建出来没有网络。--security-groups指定安全组不指定的话默认使用default安全组。创建完成后用openstack server list查看状态从BUILD变成ACTIVE才算成功。4.2 虚拟机的暂停、启动、重启与删除虚拟机生命周期操作命令很直观但有几个细节要注意。# 暂停虚拟机状态变为 PAUSED openstack server pause vm-szy-03 # 恢复暂停的虚拟机状态回到 ACTIVE openstack server unpause vm-szy-03 # 重启虚拟机 openstack server reboot vm-szy-03 # 删除虚拟机 openstack server delete vm-szy-03pause和unpause是一对操作暂停后的虚拟机不占用 CPU 资源但内存保留。reboot默认是软重启如果虚拟机卡死可以用--hard参数强制重启。delete删除后虚拟机的卷不会自动删除需要单独清理这是常见的资源残留问题。4.3 项目、用户、角色的查询与编辑命令项目、用户、角色是 Keystone 管理的三要素手册里把查询和编辑命令分得很细。# 查看项目列表 openstack project list # 查看某个项目的详情 openstack project show service # 查看某个项目下的所有用户 openstack user list --project service # 创建项目 openstack project create --domain default --description Service Project service # 更新项目名称 openstack project set demo --name test # 删除项目 openstack project delete demo用户管理命令# 查看用户列表 openstack user list # 查看用户详情 openstack user show demo # 查看某个用户的角色分配情况 openstack role assignment list --user nova # 创建用户 openstack user create --domain default --password-prompt demo # 启用用户 openstack user set demo --enable # 禁用用户 openstack user set demo --disable # 更新用户名 openstack user set demo --name test02 # 删除用户 openstack user delete demoopenstack role assignment list --usernova输出里 role、user、project 都显示为 ID需要配合openstack role list、openstack user list、openstack project list来对照查看。这是排查权限问题时最常用的命令组合。角色管理命令# 查看角色列表 openstack role list # 查看角色详情 openstack role show admin # 创建角色 openstack role create user # 把角色分配给项目和用户 openstack role add --project hzab --user hq user # 移除角色分配 openstack role remove --user hzab --project admin hsjnopenstack role add是把角色、用户、项目三者关联起来的关键命令。一个用户可以在不同项目中拥有不同角色权限是叠加的。移除角色时参数顺序和添加时一致但命令是remove。5. 避坑与排查那些手册上不会写的翻车现场5.1 环境变量没 source 导致所有 openstack 命令报错现象执行任何openstack命令都提示Missing value auth-url required for auth plugin password或者直接超时。原因当前 shell 没有加载认证环境变量OpenStack 客户端不知道 Keystone 在哪、用什么账号认证。解决先确认控制节点上存在admin-openrc或类似的环境变量文件然后执行source /root/admin-openrc。如果经常需要切换不同权限的账号可以写多个 rc 文件用source切换。注意source只对当前终端会话有效新开终端要重新执行。5.2 endpoint 地址指向旧 IP 导致跨节点调用失败现象控制节点上执行openstack命令正常但创建虚拟机时一直卡在BUILD状态或者计算节点上报nova-compute服务 down。原因部署时控制节点 IP 变更过但 Keystone 里注册的 endpoint URL 还是旧 IP计算节点通过 endpoint 地址回调控制节点 API 时连不上。解决用openstack endpoint list检查所有服务的 URL发现旧 IP 后用openstack endpoint set --url 新URL 端点ID逐个更新。更新完后重启相关服务。这个问题的隐蔽性在于控制节点本地操作不受影响只有跨节点调用才会暴露。5.3 创建虚拟机时网络 ID 填错导致虚拟机无网络现象虚拟机创建成功状态是ACTIVE但 SSH 连不上控制台里看虚拟机没有拿到 IP。原因openstack server create时--nic net-id填了一个不存在的网络 ID或者填成了子网 ID。OpenStack 不会在创建时报错但虚拟机的网卡没有正确绑定到网络。解决用openstack server show 虚机名查看addresses字段如果是空的说明网卡没绑上。这种情况下只能删除虚拟机重建因为运行中的虚拟机无法直接修改网卡绑定的网络。重建前先用openstack network list确认网络 ID 正确。5.4 修改配置文件后忘记重启对应服务现象改了nova.conf或neutron.conf里的参数但行为没有任何变化。原因OpenStack 各服务在启动时读取配置文件运行中不会自动重新加载。改完配置文件不重启服务改动不会生效。解决改完配置文件后重启对应的 systemd 服务。比如改了nova.conf要重启openstack-nova-api、openstack-nova-scheduler、openstack-nova-conductor计算节点上还要重启openstack-nova-compute。改了neutron.conf要重启neutron-server和相关的 agent。重启后用systemctl status确认服务正常拉起。5.5 删除项目前未清理关联资源导致删除失败现象执行openstack project delete demo报错提示项目下还有资源。原因项目下还有虚拟机、卷、网络、用户等关联资源Keystone 不允许直接删除非空项目。解决先用openstack server list --project demo、openstack volume list --project demo、openstack network list --project demo等命令查出项目下的所有资源逐个删除后再删项目。用户和角色分配也要先用openstack role assignment list --project demo查出来并移除。这个清理顺序建议是虚拟机 → 卷 → 网络 → 用户角色分配 → 项目。6. 把命令手册用成排查工具我的三条固定检查链路手册放在那里是死的真正有用的是把它变成一套固定的排查动作。我自己的习惯是遇到 OpenStack 问题先走三条链路基本能覆盖八成以上的故障场景。第一条链路是服务状态检查。不管什么问题先systemctl status把相关服务的状态过一遍。认证问题看httpd镜像问题看openstack-glance-api和openstack-glance-registry计算问题看openstack-nova-api到openstack-nova-compute那一串网络问题看neutron-server和三个 agent存储问题看openstack-cinder-api、openstack-cinder-scheduler、openstack-cinder-volume。这条链路能快速定位是哪个组件挂了。第二条链路是 OpenStack 层面的组件注册检查。openstack compute service list、cinder service-list、openstack network agent list这三条命令分别看 Nova、Cinder、Neutron 的组件是否正常注册到消息队列。输出里State不是up的组件就是问题源头。这条链路能发现服务进程活着但没注册上的情况比单纯看 systemd 状态更深入。第三条链路是 endpoint 和认证检查。openstack endpoint list确认所有服务的端点 URL 可达openstack token issue确认当前认证能拿到 tokenopenstack role assignment list --user 用户名确认权限分配正确。这条链路专门对付「服务都正常但就是调不通」的玄学问题。下面这张表是我常用的排查命令速查按故障现象分类故障现象首选检查命令关键看什么所有 openstack 命令超时systemctl status httpdhttpd 是否 active创建虚拟机卡在 BUILDopenstack compute service listnova-compute 是否 up虚拟机无网络openstack server show 虚机名addresses 字段是否为空卷创建失败cinder service-listcinder-volume 是否 up跨节点 API 调用失败openstack endpoint listURL 是否指向正确 IP权限不足报错openstack role assignment list --user 用户名角色是否正确分配还有一个习惯每次改完配置文件不要只重启一个服务就完事。OpenStack 的服务之间有依赖关系比如改了neutron.conf里的消息队列地址neutron-server和所有 agent 都要重启。我一般会把相关服务列出来用一条systemctl restart命令批量重启然后systemctl status逐个确认。这个动作多花两分钟能省掉后面半小时的排查时间。最后说一个真实教训。有次改完nova.conf里的vncserver_listen参数只重启了openstack-nova-api忘了重启openstack-nova-novncproxy结果虚拟机控制台一直黑屏。查了半天以为是网络问题最后发现是 novncproxy 还在用旧配置。从那以后我每次改nova.conf都强制走一遍「改配置 → 列服务 → 批量重启 → 逐个确认状态」的流程再也没在这上面翻过车。希望这些经验帮到你。本文还有配套的精品资源点击获取