简介这份《openstack命令手册.docx》面向云计算运维人员、OpenStack初学者及备考相关认证的技术人员聚焦于解决日常运维中命令零散、查询效率低的问题。资源包共1个docx文件约20KB以文档形式系统整理命令条目便于随身查阅与快速检索。内容按主机、认证、镜像、计算、网络、块存储、虚拟机管理七大模块划分每类下再分查询类与编辑类涵盖网络接口配置、域与项目创建、镜像上传、nova与neutron配置维护、cinder服务状态查看、虚拟机创建暂停重启删除等高频操作并附有命令语法与样例注解。目录层级清晰从基础查询到编辑维护逐层递进适合作为日常运维速查表或培训参考资料。目前已有411人学习下载可帮助读者减少翻查官方文档的时间快速定位所需命令并理解参数含义。1. OpenStack 命令手册从「背命令」到「查手册」的运维思维转变刚接手 OpenStack 云平台那会儿我习惯把常用命令抄在便签上贴在显示器边框结果一次控制节点重启后便签上的nova boot参数全变了样——微版本更新导致--nic的写法不再兼容。那一刻我才意识到OpenStack 命令手册不是一本背下来就一劳永逸的字典而是一套需要理解「服务客户端 认证上下文 资源对象」三层结构的动态查询系统。这份手册要解决的核心问题很具体当你面对一个报错的openstack server create如何快速定位是认证 token 过期、微版本不匹配还是后端 nova-compute 服务没起来。它适合已经用 kolla 或手动部署跑通了 OpenStack 云平台搭建、但被各服务命令差异搞得头晕的运维人员也适合正在做 openstack 部署、需要一套可复现命令清单的工程师。接下来的内容我会把手册拆成「认证与入口」「核心资源操作」「网络与存储」「排错与微版本」几个可落地的模块每个模块都给出能直接抄的命令和参数解释。2. 认证入口与客户端环境命令手册的第一页该写什么2.1 为什么source admin-openrc之后命令还是报 401很多人以为拿到admin-openrc文件、执行source就万事大吉但实际翻车往往发生在环境变量覆盖上。OpenStack 各服务客户端nova、neutron、glance 等统一走 Keystone 认证认证信息通过环境变量注入。常见问题是你之前export OS_PROJECT_NAMEtest手动改过项目名再source admin-openrc时脚本里的OS_PROJECT_NAMEadmin被已有变量挡住导致 token 申请下来但项目域不对返回 401。我一般会先跑一条不依赖具体资源的命令来验证认证链路# 清空可能冲突的旧变量再加载认证文件 unset OS_AUTH_URL OS_PROJECT_NAME OS_USERNAME OS_PASSWORD OS_USER_DOMAIN_NAME OS_PROJECT_DOMAIN_NAME source /etc/kolla/admin-openrc.sh # 用 token issue 验证认证是否真正通过 openstack token issue -c id -c expires -f value逻辑说明unset那行是后悔药防止之前调试留下的变量污染。openstack token issue只跟 Keystone 交互不碰 nova/neutron能最快判断认证层是否健康。参数上-c id -c expires只输出 token 和过期时间-f value去掉表头方便脚本取值。如果这条命令返回 token 字符串说明认证没问题后续报错就要往服务端或微版本方向查。2.2 用openstack endpoint list确认服务入口没写错认证通过但命令超时八成是 endpoint 配错了。OpenStack 命令手册里必须有一页专门讲 endpoint 检查因为 kolla 部署和手动部署的 endpoint 注册方式不同很容易出现nova的 endpoint 指向了旧控制节点 IP。# 列出所有服务的 public/internal/admin 三类 endpoint openstack endpoint list --interface public -f csv -c Service Name -c Service Type -c URL # 只看 nova 和 neutron 的 endpoint确认 IP 和端口 openstack endpoint list --service nova --interface public -f value -c URL openstack endpoint list --service neutron --interface public -f value -c URL逻辑说明--interface public是给外部 API 调用用的如果你在控制节点本机执行命令客户端默认走 public endpoint。-f csv输出逗号分隔方便复制到表格里比对。参数上--service nova按服务名过滤-c URL只取地址列。如果发现 URL 里的 IP 是127.0.0.1或者旧节点 IP就需要去/etc/kolla/globals.yml里检查kolla_internal_vip_address和api_interface重新跑kolla-ansible -i inventory post-deploy或手动更新 endpoint。提示改完 endpoint 后先openstack token issue再试资源命令不要直接重启所有服务否则容易把问题范围扩大。3. 核心资源操作虚拟机、镜像、 flavors 的命令手册怎么写才不翻车3.1openstack server create的微版本陷阱与参数拆解openstack server create是手册里被查次数最多的命令也是微版本坑最集中的地方。比如--nic net-idxxx在 nova 2.37 之后支持--nic auto但如果你客户端版本旧、服务端微版本高命令会直接报Invalid input。我一般会先确认当前客户端支持的微版本范围# 查看 nova 客户端支持的微版本区间 openstack --os-compute-api-version 2.1 server list 21 | head -5 # 显式指定微版本创建虚拟机避免自动协商失败 openstack --os-compute-api-version 2.60 server create \ --flavor m1.small \ --image cirros-0.5.2-x86_64-disk \ --nic net-id$(openstack network show private -f value -c id) \ --security-group default \ --key-name mykey \ test-vm-01逻辑说明第一行用最低微版本 2.1 试探如果报错说明客户端或服务端至少有一端不支持。第二行显式指定 2.60这个版本支持--nic的多种格式和--host调度。参数上--flavor可以用名字或 ID--image同理--nic net-id后面必须跟网络 UUID不能写网络名。--security-group和--key-name如果省略默认安全组会放行所有出站但禁止入站key 缺失则无法 SSH。3.2 镜像上传与格式转换openstack image create的必调参数镜像上传是 openstack 云平台搭建后的第一道实操门槛。常见做法是用openstack image create直接传 qcow2但如果你要跑多架构虚拟机比如通过 qemu 部署 arm64 实例就需要额外指定--property hw_architecturearm64和--property hw_machine_typevirt。# 上传 qcow2 镜像并设置多架构属性 openstack image create ubuntu-22.04-arm64 \ --disk-format qcow2 \ --container-format bare \ --property hw_architecturearm64 \ --property hw_machine_typevirt \ --property os_typelinux \ --file ubuntu-22.04-server-cloudimg-arm64.img \ --progress # 验证镜像属性是否生效 openstack image show ubuntu-22.04-arm64 -c properties -f json逻辑说明--disk-format qcow2告诉 glance 镜像的底层格式--container-format bare表示没有额外容器封装。--property是元数据nova 调度时会读取hw_architecture来决定放到哪种架构的计算节点。--progress显示上传进度大镜像必备。参数上--file后面跟本地路径如果镜像在远程 URL可以用--copy-from或--location。验证时-c properties -f json只输出属性字段方便脚本解析。注意如果上传后创建虚拟机报No valid host先检查计算节点的hw_architecture是否与镜像属性匹配而不是急着看 nova 日志。4. 网络与存储命令neutron 和 cinder 手册里最容易漏掉的参数4.1openstack network create与子网 DHCP 的联动网络创建看起来简单但手册里如果不写清楚--subnet-range和--gateway的关系很容易出现虚拟机拿到 IP 但 ping 不通网关。我一般会按「网络 → 子网 → 路由 → 安全组」的顺序写手册。# 创建私有网络和子网指定 DHCP 和 DNS openstack network create private-net openstack subnet create private-subnet \ --network private-net \ --subnet-range 192.168.100.0/24 \ --gateway 192.168.100.1 \ --dhcp \ --dns-nameserver 8.8.8.8 \ --allocation-pool start192.168.100.10,end192.168.100.200 # 创建路由并添加到外部网络的网关 openstack router create private-router openstack router set private-router --external-gateway public openstack router add subnet private-router private-subnet逻辑说明--dhcp启用 DHCP 服务--dns-nameserver可以写多个用逗号分隔。--allocation-pool限制自动分配的 IP 范围避免和手动指定的 IP 冲突。路由那三行是外网访问的关键--external-gateway public把路由接到外部网络add subnet把子网挂到路由上。参数上public是外部网络的名称如果你的环境里叫ext-net要相应替换。4.2 cinder 卷挂载openstack server add volume的 device 参数玄学卷挂载命令本身简单但--device参数在不同虚拟化后端下表现不一致。KVM 下/dev/vdb是常见写法但如果你用--device autonova 会自动分配反而更稳。# 创建卷并挂载到虚拟机 openstack volume create --size 10>#!/bin/bash set -euo pipefail # 参数校验必须传入虚拟机名、镜像名、flavor 名 VM_NAME${1:? Usage: $0 vm-name image-name flavor-name} IMAGE_NAME${2:? Usage: $0 vm-name image-name flavor-name} FLAVOR_NAME${3:? Usage: $0 vm-name image-name flavor-name} # 认证检查 if ! openstack token issue -c id -f value /dev/null 21; then echo 认证失败请先 source openrc 文件 exit 1 fi # 查询网络 ID NET_ID$(openstack network show private -f value -c id 2/dev/null || true) if [ -z $NET_ID ]; then echo 私有网络 private 不存在请先创建 exit 1 fi # 查询镜像 ID IMAGE_ID$(openstack image show $IMAGE_NAME -f value -c id 2/dev/null || true) if [ -z $IMAGE_ID ]; then echo 镜像 $IMAGE_NAME 不存在 exit 1 fi # 创建虚拟机 openstack --os-compute-api-version 2.60 server create \ --flavor $FLAVOR_NAME \ --image $IMAGE_ID \ --nic net-id$NET_ID \ --security-group default \ --key-name mykey \ $VM_NAME # 等待状态变为 ACTIVE最多等 120 秒 for i in $(seq 1 24); do STATUS$(openstack server show $VM_NAME -f value -c status 2/dev/null || echo UNKNOWN) if [ $STATUS ACTIVE ]; then echo 虚拟机 $VM_NAME 创建成功 openstack server show $VM_NAME -c addresses -f value exit 0 fi sleep 5 done echo 虚拟机 $VM_NAME 创建超时当前状态$STATUS exit 1逻辑说明set -euo pipefail让脚本在任意命令失败时退出避免错误累积。${1:?}是参数校验不传参直接报用法。认证检查用openstack token issue的返回值判断比source后直接跑资源命令更安全。网络和镜像查询用|| true防止set -e提前退出再手动判断空值。创建时显式指定微版本2.60避免协商失败。等待循环每 5 秒查一次状态最多 120 秒超时后输出当前状态方便排查。参数上--key-name mykey需要你提前在 OpenStack 里注册好 SSH 公钥可以用openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey创建。--security-group default默认只放行出站如果需要 SSH 入站要额外加--security-group ssh或者手动加规则。这个脚本我用了两年多最大的教训是不要在里面写openstack server delete做清理因为一旦变量为空delete可能误删其他虚拟机。清理操作永远手动确认。另外微版本号不要写死2.60如果你的环境是较老的 Queens 或 Rocky最高只支持到2.53左右写高了直接报错。我现在的习惯是先在测试环境跑一遍openstack --os-compute-api-version 2.1 server list确认最低版本能通再根据实际需要往上调。希望帮到你。本文还有配套的精品资源点击获取 OpenStack命令手册：从认证到微版本，运维避坑与脚本化实践
简介这份《openstack命令手册.docx》面向云计算运维人员、OpenStack初学者及备考相关认证的技术人员聚焦于解决日常运维中命令零散、查询效率低的问题。资源包共1个docx文件约20KB以文档形式系统整理命令条目便于随身查阅与快速检索。内容按主机、认证、镜像、计算、网络、块存储、虚拟机管理七大模块划分每类下再分查询类与编辑类涵盖网络接口配置、域与项目创建、镜像上传、nova与neutron配置维护、cinder服务状态查看、虚拟机创建暂停重启删除等高频操作并附有命令语法与样例注解。目录层级清晰从基础查询到编辑维护逐层递进适合作为日常运维速查表或培训参考资料。目前已有411人学习下载可帮助读者减少翻查官方文档的时间快速定位所需命令并理解参数含义。1. OpenStack 命令手册从「背命令」到「查手册」的运维思维转变刚接手 OpenStack 云平台那会儿我习惯把常用命令抄在便签上贴在显示器边框结果一次控制节点重启后便签上的nova boot参数全变了样——微版本更新导致--nic的写法不再兼容。那一刻我才意识到OpenStack 命令手册不是一本背下来就一劳永逸的字典而是一套需要理解「服务客户端 认证上下文 资源对象」三层结构的动态查询系统。这份手册要解决的核心问题很具体当你面对一个报错的openstack server create如何快速定位是认证 token 过期、微版本不匹配还是后端 nova-compute 服务没起来。它适合已经用 kolla 或手动部署跑通了 OpenStack 云平台搭建、但被各服务命令差异搞得头晕的运维人员也适合正在做 openstack 部署、需要一套可复现命令清单的工程师。接下来的内容我会把手册拆成「认证与入口」「核心资源操作」「网络与存储」「排错与微版本」几个可落地的模块每个模块都给出能直接抄的命令和参数解释。2. 认证入口与客户端环境命令手册的第一页该写什么2.1 为什么source admin-openrc之后命令还是报 401很多人以为拿到admin-openrc文件、执行source就万事大吉但实际翻车往往发生在环境变量覆盖上。OpenStack 各服务客户端nova、neutron、glance 等统一走 Keystone 认证认证信息通过环境变量注入。常见问题是你之前export OS_PROJECT_NAMEtest手动改过项目名再source admin-openrc时脚本里的OS_PROJECT_NAMEadmin被已有变量挡住导致 token 申请下来但项目域不对返回 401。我一般会先跑一条不依赖具体资源的命令来验证认证链路# 清空可能冲突的旧变量再加载认证文件 unset OS_AUTH_URL OS_PROJECT_NAME OS_USERNAME OS_PASSWORD OS_USER_DOMAIN_NAME OS_PROJECT_DOMAIN_NAME source /etc/kolla/admin-openrc.sh # 用 token issue 验证认证是否真正通过 openstack token issue -c id -c expires -f value逻辑说明unset那行是后悔药防止之前调试留下的变量污染。openstack token issue只跟 Keystone 交互不碰 nova/neutron能最快判断认证层是否健康。参数上-c id -c expires只输出 token 和过期时间-f value去掉表头方便脚本取值。如果这条命令返回 token 字符串说明认证没问题后续报错就要往服务端或微版本方向查。2.2 用openstack endpoint list确认服务入口没写错认证通过但命令超时八成是 endpoint 配错了。OpenStack 命令手册里必须有一页专门讲 endpoint 检查因为 kolla 部署和手动部署的 endpoint 注册方式不同很容易出现nova的 endpoint 指向了旧控制节点 IP。# 列出所有服务的 public/internal/admin 三类 endpoint openstack endpoint list --interface public -f csv -c Service Name -c Service Type -c URL # 只看 nova 和 neutron 的 endpoint确认 IP 和端口 openstack endpoint list --service nova --interface public -f value -c URL openstack endpoint list --service neutron --interface public -f value -c URL逻辑说明--interface public是给外部 API 调用用的如果你在控制节点本机执行命令客户端默认走 public endpoint。-f csv输出逗号分隔方便复制到表格里比对。参数上--service nova按服务名过滤-c URL只取地址列。如果发现 URL 里的 IP 是127.0.0.1或者旧节点 IP就需要去/etc/kolla/globals.yml里检查kolla_internal_vip_address和api_interface重新跑kolla-ansible -i inventory post-deploy或手动更新 endpoint。提示改完 endpoint 后先openstack token issue再试资源命令不要直接重启所有服务否则容易把问题范围扩大。3. 核心资源操作虚拟机、镜像、 flavors 的命令手册怎么写才不翻车3.1openstack server create的微版本陷阱与参数拆解openstack server create是手册里被查次数最多的命令也是微版本坑最集中的地方。比如--nic net-idxxx在 nova 2.37 之后支持--nic auto但如果你客户端版本旧、服务端微版本高命令会直接报Invalid input。我一般会先确认当前客户端支持的微版本范围# 查看 nova 客户端支持的微版本区间 openstack --os-compute-api-version 2.1 server list 21 | head -5 # 显式指定微版本创建虚拟机避免自动协商失败 openstack --os-compute-api-version 2.60 server create \ --flavor m1.small \ --image cirros-0.5.2-x86_64-disk \ --nic net-id$(openstack network show private -f value -c id) \ --security-group default \ --key-name mykey \ test-vm-01逻辑说明第一行用最低微版本 2.1 试探如果报错说明客户端或服务端至少有一端不支持。第二行显式指定 2.60这个版本支持--nic的多种格式和--host调度。参数上--flavor可以用名字或 ID--image同理--nic net-id后面必须跟网络 UUID不能写网络名。--security-group和--key-name如果省略默认安全组会放行所有出站但禁止入站key 缺失则无法 SSH。3.2 镜像上传与格式转换openstack image create的必调参数镜像上传是 openstack 云平台搭建后的第一道实操门槛。常见做法是用openstack image create直接传 qcow2但如果你要跑多架构虚拟机比如通过 qemu 部署 arm64 实例就需要额外指定--property hw_architecturearm64和--property hw_machine_typevirt。# 上传 qcow2 镜像并设置多架构属性 openstack image create ubuntu-22.04-arm64 \ --disk-format qcow2 \ --container-format bare \ --property hw_architecturearm64 \ --property hw_machine_typevirt \ --property os_typelinux \ --file ubuntu-22.04-server-cloudimg-arm64.img \ --progress # 验证镜像属性是否生效 openstack image show ubuntu-22.04-arm64 -c properties -f json逻辑说明--disk-format qcow2告诉 glance 镜像的底层格式--container-format bare表示没有额外容器封装。--property是元数据nova 调度时会读取hw_architecture来决定放到哪种架构的计算节点。--progress显示上传进度大镜像必备。参数上--file后面跟本地路径如果镜像在远程 URL可以用--copy-from或--location。验证时-c properties -f json只输出属性字段方便脚本解析。注意如果上传后创建虚拟机报No valid host先检查计算节点的hw_architecture是否与镜像属性匹配而不是急着看 nova 日志。4. 网络与存储命令neutron 和 cinder 手册里最容易漏掉的参数4.1openstack network create与子网 DHCP 的联动网络创建看起来简单但手册里如果不写清楚--subnet-range和--gateway的关系很容易出现虚拟机拿到 IP 但 ping 不通网关。我一般会按「网络 → 子网 → 路由 → 安全组」的顺序写手册。# 创建私有网络和子网指定 DHCP 和 DNS openstack network create private-net openstack subnet create private-subnet \ --network private-net \ --subnet-range 192.168.100.0/24 \ --gateway 192.168.100.1 \ --dhcp \ --dns-nameserver 8.8.8.8 \ --allocation-pool start192.168.100.10,end192.168.100.200 # 创建路由并添加到外部网络的网关 openstack router create private-router openstack router set private-router --external-gateway public openstack router add subnet private-router private-subnet逻辑说明--dhcp启用 DHCP 服务--dns-nameserver可以写多个用逗号分隔。--allocation-pool限制自动分配的 IP 范围避免和手动指定的 IP 冲突。路由那三行是外网访问的关键--external-gateway public把路由接到外部网络add subnet把子网挂到路由上。参数上public是外部网络的名称如果你的环境里叫ext-net要相应替换。4.2 cinder 卷挂载openstack server add volume的 device 参数玄学卷挂载命令本身简单但--device参数在不同虚拟化后端下表现不一致。KVM 下/dev/vdb是常见写法但如果你用--device autonova 会自动分配反而更稳。# 创建卷并挂载到虚拟机 openstack volume create --size 10>#!/bin/bash set -euo pipefail # 参数校验必须传入虚拟机名、镜像名、flavor 名 VM_NAME${1:? Usage: $0 vm-name image-name flavor-name} IMAGE_NAME${2:? Usage: $0 vm-name image-name flavor-name} FLAVOR_NAME${3:? Usage: $0 vm-name image-name flavor-name} # 认证检查 if ! openstack token issue -c id -f value /dev/null 21; then echo 认证失败请先 source openrc 文件 exit 1 fi # 查询网络 ID NET_ID$(openstack network show private -f value -c id 2/dev/null || true) if [ -z $NET_ID ]; then echo 私有网络 private 不存在请先创建 exit 1 fi # 查询镜像 ID IMAGE_ID$(openstack image show $IMAGE_NAME -f value -c id 2/dev/null || true) if [ -z $IMAGE_ID ]; then echo 镜像 $IMAGE_NAME 不存在 exit 1 fi # 创建虚拟机 openstack --os-compute-api-version 2.60 server create \ --flavor $FLAVOR_NAME \ --image $IMAGE_ID \ --nic net-id$NET_ID \ --security-group default \ --key-name mykey \ $VM_NAME # 等待状态变为 ACTIVE最多等 120 秒 for i in $(seq 1 24); do STATUS$(openstack server show $VM_NAME -f value -c status 2/dev/null || echo UNKNOWN) if [ $STATUS ACTIVE ]; then echo 虚拟机 $VM_NAME 创建成功 openstack server show $VM_NAME -c addresses -f value exit 0 fi sleep 5 done echo 虚拟机 $VM_NAME 创建超时当前状态$STATUS exit 1逻辑说明set -euo pipefail让脚本在任意命令失败时退出避免错误累积。${1:?}是参数校验不传参直接报用法。认证检查用openstack token issue的返回值判断比source后直接跑资源命令更安全。网络和镜像查询用|| true防止set -e提前退出再手动判断空值。创建时显式指定微版本2.60避免协商失败。等待循环每 5 秒查一次状态最多 120 秒超时后输出当前状态方便排查。参数上--key-name mykey需要你提前在 OpenStack 里注册好 SSH 公钥可以用openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey创建。--security-group default默认只放行出站如果需要 SSH 入站要额外加--security-group ssh或者手动加规则。这个脚本我用了两年多最大的教训是不要在里面写openstack server delete做清理因为一旦变量为空delete可能误删其他虚拟机。清理操作永远手动确认。另外微版本号不要写死2.60如果你的环境是较老的 Queens 或 Rocky最高只支持到2.53左右写高了直接报错。我现在的习惯是先在测试环境跑一遍openstack --os-compute-api-version 2.1 server list确认最低版本能通再根据实际需要往上调。希望帮到你。本文还有配套的精品资源点击获取