简介：这份《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/hosts

ifconfig虽然在新版系统中逐渐被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.log

systemctl 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 list

openstack 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 list

openstack-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 check

openstack compute service list输出里State为up、Status为enabled才算正常。如果某个 compute 节点显示down，先检查该节点的nova-compute服务是否在跑，再看消息队列（通常是 RabbitMQ）是否可达。

编辑 nova 配置：

# 编辑 nova 主配置文件 vim /etc/nova/nova.conf

nova.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.service

neutron-server接收 API 请求创建网络、子网、路由器；neutron-linuxbridge-agent负责实际的二层网络转发；neutron-dhcp-agent为虚拟机提供 DHCP 服务；neutron-metadata-agent让虚拟机能够访问 Nova 的 metadata 服务。这四个服务通常分布在控制节点和网络节点上，排查时要先确认在正确的节点上看。

# 查看网络列表 openstack network list # 查看端口列表 openstack port list

openstack 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.ini

ML2（Modular 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-list

openstack-cinder-api提供 HTTP 接口，openstack-cinder-scheduler决定卷创建在哪个存储节点上，openstack-cinder-volume通过驱动和底层存储交互，target.service是 iSCSI 目标服务，负责把卷暴露给计算节点。cinder service-list输出里每个组件的State为up才正常。

# 编辑 cinder 主配置 vim /etc/cinder/cinder.conf

cinder.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-id=e7f65cb4-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-03

pause和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 demo

openstack role assignment list --user=nova输出里 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 hsjn

openstack 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确认当前认证能拿到 token，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都强制走一遍「改配置 → 列服务 → 批量重启 → 逐个确认状态」的流程，再也没在这上面翻过车。希望这些经验帮到你。

本文还有配套的精品资源，点击获取