企业官网建设流程全解析

简介：本资源是一份面向OpenStack初学者与运维工程师的实用命令速查手册，聚焦网络计算场景下的核心服务操作，帮助用户快速掌握平台日常管理与故障排查所需的关键CLI指令。文档以Word格式（.docx）单文件呈现，体积精简仅20KB，内容结构清晰，覆盖主机基础命令、Keystone认证、Glance镜像、Nova计算、Neutron网络、Cinder块存储及虚拟机全生命周期管理七大模块，每类均按查询/编辑/删除更新分项列出典型命令及语法示例，含Apache服务状态检查、域与项目创建、镜像上传、虚拟机启停等高频操作。目录层级完整，含详细注解与实操样例，便于随用随查、即学即用。目前已有411人学习下载，适合作为OpenStack部署调试阶段的桌面参考工具或培训辅助材料。

1. 这不是“命令速查表”，而是一份能让你在 OpenStack 生产环境里少敲错三次openstack、少重启两次neutron-server、少翻一次日志的实战手册

你刚接手一个跑着 Nova+Neutron+Cinder 的 OpenStack 环境，控制节点上openstack endpoint list返回一堆regionOne和http://10.0.0.10:xxx，但openstack server list却报HTTP 401 Unauthorized；你照着文档改完/etc/nova/nova.conf，systemctl restart openstack-nova-api后服务状态是active (exited)——它根本没起来；你上传了 cirros 镜像，openstack image show cirros显示status: queued，等十分钟还是queued，没人告诉你glance-api和glance-registry必须同时 running，且registry默认监听127.0.0.1:9191，而api默认连http://localhost:9191，一旦你把registry绑定到0.0.0.0，api就连不上了。这不是玄学，是 OpenStack 命令链路上每个环节都卡着权限、端口、服务依赖、配置同步四道关。这份.docx手册表面是“命令罗列”，实则是把openstackCLI、systemctl、vim三类命令拧成一条可验证、可回溯、可定位失败点的操作流——它不教你“什么是域”，而是告诉你openstack domain create成功后，必须立刻openstack endpoint list --service image看 public/internal/admin 三个 endpoint 是否全存在；它不讲“ML2 是什么”，而是明确写出ml2_conf.ini里type_drivers = flat,vlan,vxlan和tenant_network_types = vxlan必须匹配，否则neutron net-create会静默失败。适合正在搭建基于 PackStack 或手动部署的 OpenStack 云平台的运维工程师、私有云交付工程师，以及被nova-status upgrade check报出十几条FAIL吓得不敢动生产环境的中级实施人员。

2. 主机与认证服务：从系统层打通 OpenStack 的身份信任链

OpenStack 不是独立运行的黑匣子，它的所有服务（keystone,glance,nova）都依赖底层 Linux 主机的网络可达性、服务进程存活性、以及最关键的—— Keystone 认证服务的可用性。很多初学者卡在openstack project list报错Connection refused，第一反应是 Keystone 挂了，其实八成是httpd没启、防火墙拦了 5000/35357 端口、或/etc/hosts里controller解析错了 IP。本章带你用最短路径建立“主机 → Apache → Keystone”的信任链，让openstackCLI 能真正说话。

2.1 主机网络与主机名：CLI 命令能执行的前提是 DNS 和路由通

OpenStack CLI 工具（openstack,nova,neutron）默认通过环境变量OS_AUTH_URL（如http://controller:5000/v3）连接 Keystone。这个 URL 能否解析、能否连通，完全取决于主机层面的网络配置。

提示：不要直接ping controller，要nslookup controller或dig controller，因为ping可能走/etc/hosts缓存，而openstackCLI 用的是 glibc 的 resolver，行为更严格。

# 查看主机名是否与 /etc/hosts 中定义一致（这是 OpenStack 服务间通信的基础） cat /etc/hostname # 输出应为 'controller' 或 'compute01' 等，不能是 'localhost.localdomain' # 查看 /etc/hosts 是否正确定义了所有节点的 IP 和主机名映射 cat /etc/hosts # 正确示例： # 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 # 10.0.0.11 controller # 10.0.0.31 compute01 # 10.0.0.32 compute02

逻辑说明：openstackCLI 在发起 HTTP 请求前，会调用getaddrinfo()查询controller的 IP。如果/etc/hosts里没有controller条目，它会走 DNS；若 DNS 不可用或返回错误 IP，请求直接失败。cat /etc/hostname输出必须与/etc/hosts中该行的主机名完全一致（区分大小写），否则httpd的虚拟主机配置可能不生效。

参数说明：/etc/hosts文件中，每行格式为<IP地址> <主机名> [别名...]。OpenStack 官方文档强烈建议使用静态 hosts 映射而非 DNS，因为 DNS 故障会导致整个云平台不可用。

2.2 Apache httpd 服务：Keystone 的 HTTP 入口，挂了就等于整个认证体系瘫痪

Keystone v3 服务由httpd（Apache）托管，其配置文件/etc/httpd/conf.d/wsgi-keystone.conf定义了 WSGI 应用路径。systemctl status httpd.service不仅检查 Apache 进程，更关键的是确认httpd能成功加载 Keystone 的 WSGI 模块。

# 检查 httpd 服务状态（注意：active (running) 是必要条件，但非充分条件） systemctl status httpd.service # 若显示 active (exited)，说明 Apache 启动失败，需立即查日志 # 查看最近 50 行错误日志（核心排查点） tail -50 /var/log/httpd/error_log # 关键错误示例： # [wsgi:error] ModuleNotFoundError: No module named 'keystone' # [core:error] AH00526: Syntax error on line 12 of /etc/httpd/conf.d/wsgi-keystone.conf: Invalid command 'WSGIScriptAlias', perhaps misspelled or defined by a module not included in the server configuration

逻辑说明：httpd启动失败最常见的原因是 Python 环境问题（如python3-keystone未安装）、WSGI 模块未启用（LoadModule wsgi_module modules/mod_wsgi.so缺失）、或wsgi-keystone.conf中路径错误（如WSGIScriptAlias / /usr/bin/keystone-wsgi-public应指向实际可执行文件）。tail -50 /var/log/httpd/error_log是比systemctl status更精准的诊断入口。

参数说明：/var/log/httpd/error_log是 Apache 的错误日志主文件，记录模块加载、语法错误、权限拒绝等致命问题。/var/log/httpd/keystone_access.log记录 HTTP 请求，用于分析认证流量，但不解决启动问题。

2.3 Keystone 域与项目：openstack domain list成功 ≠ Keystone 可用，必须验证 endpoint

openstack domain list返回结果，只代表 Keystone API 接口响应了，不代表后端数据库连接正常、不代表httpd下的 WSGI 应用能访问数据库、更不代表openstackCLI 使用的认证 token 有效。真正的验证是openstack endpoint list—— 它要求 Keystone 不仅要响应，还要能查询自身服务目录（Service Catalog）。

# 第一步：确保环境变量已正确设置（这是所有 openstack 命令的前提） source /root/admin-openrc.sh # 该文件应包含：export OS_AUTH_URL=http://controller:5000/v3 # export OS_PROJECT_NAME=admin # export OS_USER_DOMAIN_NAME=Default # export OS_PROJECT_DOMAIN_NAME=Default # export OS_USERNAME=admin # export OS_PASSWORD=ADMIN_PASS # export OS_IDENTITY_API_VERSION=3 # export OS_IMAGE_API_VERSION=2 # 第二步：查询域列表（基础可用性） openstack domain list # 正常输出应含 default 域，Enabled=True # 第三步：查询 endpoint 列表（关键验证！） openstack endpoint list --service identity # 正确输出应有 3 行，Interface 分别为 public, internal, admin，URL 均指向 controller:5000/v3 # 若只返回 0 行或报错 "No endpoints found"，说明 Keystone 的 service catalog 为空或损坏

逻辑说明：openstack endpoint list --service identity强制 Keystone 查询service表和endpoint表的关联。如果keystone-manage bootstrap未执行，或keystone-manage db_sync失败，endpoint表就是空的，此时openstack domain list仍能工作（因为它只查domain表），但所有其他服务（glance,nova）都无法注册 endpoint，整个云平台无法初始化。

参数说明：--service identity过滤只显示 Keystone 服务的 endpoint。publicendpoint 供外部用户访问，internal供 OpenStack 内部服务间调用（如nova调keystone），admin供管理员操作。三者 URL 必须全部存在且可连通（用curl -I http://controller:5000/v3验证）。

2.4 创建域、项目、用户：openstack命令背后是数据库事务，失败时必须查keystone-manage日志

openstack domain create看似一条命令，实则触发 Keystone 的完整 CRUD 流程：校验参数 → 生成 UUID → 插入domain表 → 触发通知 → 更新缓存。任何一环失败，命令就静默退出或报模糊错误。

# 创建新域（带描述，符合生产环境规范） openstack domain create --description "Production Environment Domain" prod # 创建项目（绑定到 prod 域） openstack project create --domain prod --description "Core Compute Project" compute-prod # 创建用户（交互式输密码，避免明文出现在 bash history） openstack user create --domain prod --password-prompt compute-user # 提示输入密码两次，安全且不留痕 # 将用户加入项目并赋予 admin 角色（这是授权的关键一步） openstack role add --project compute-prod --user compute-user admin

逻辑说明：--password-prompt是最佳实践，避免密码明文出现在命令行历史（history）和进程列表（ps aux）。openstack role add命令本质是向assignment表插入一条记录，将user_id,project_id,role_id关联起来。如果openstack role list能看到admin角色，但openstack role add报错Role not found，说明--role admin中的admin是角色名，而数据库里存储的是角色 ID，需先openstack role show admin获取 ID 再用--role <id>。

参数说明：--domain prod指定域，--project compute-prod指定项目，--user compute-user指定用户。三者必须已存在，否则命令失败。openstackCLI 本身不校验依赖关系，失败时只报NotFound，需人工确认上游资源是否存在。

2.5 避坑：认证服务常见问题排查（现象→原因→解决）

• 现象：openstack domain list返回HTTP 401 Unauthorized
  原因：环境变量OS_AUTH_URL,OS_USERNAME,OS_PASSWORD未正确设置，或admin-openrc.sh中OS_AUTH_URL指向http://localhost:5000/v3（localhost 在 compute 节点解析为 127.0.0.1，但 Keystone 只监听 controller IP）
  解决：在所有节点执行source /root/admin-openrc.sh，确认OS_AUTH_URL=http://controller:5000/v3，且controller在/etc/hosts中解析为控制节点真实 IP。

• 现象：openstack endpoint list返回空，但openstack domain list正常
  原因：Keystone 数据库未初始化，keystone-manage db_sync未执行，或keystone-manage bootstrap未运行导致 service catalog 为空
  解决：登录 controller 节点，执行su -s /bin/sh -c "keystone-manage db_sync" keystone，再执行keystone-manage bootstrap --bootstrap-password ADMIN_PASS。

• 现象：openstack user create成功，但openstack user list --project=compute-prod查不到该用户
  原因：用户创建后未通过openstack role add将其分配到项目，user list --project只显示有角色绑定的用户
  解决：执行openstack role add --project compute-prod --user compute-user member（member 是标准角色），再查。

• 现象：systemctl status httpd.service显示active (running)，但curl http://controller:5000/v3返回Connection refused
  原因：httpd进程运行，但wsgi-keystone.conf中Listen 5000被注释，或防火墙firewalld拦截了 5000 端口
  解决：检查/etc/httpd/conf.d/wsgi-keystone.conf确认Listen 5000未注释；执行firewall-cmd --list-ports | grep 5000，若无输出则firewall-cmd --add-port=5000/tcp --permanent && firewall-cmd --reload。

• 现象：openstack project create报错Conflict: Duplicate entry
  原因：项目名已存在（OpenStack 项目名在 domain 内唯一），但openstack project list未显示，因--domain参数未指定，列表默认查default域
  解决：用openstack project list --domain prod查指定域下的项目，或改用唯一项目名。

3. 镜像与计算服务：从glance image-create到nova boot的完整链路验证

镜像服务（Glance）和计算服务（Nova）是 OpenStack 最核心的两个服务，它们的协作流程是：用户上传镜像 → Glance 存储镜像元数据和文件 → Nova 通过 Glance API 获取镜像信息 → Nova Scheduler 选择宿主机 → Nova Compute 创建虚拟机实例。这条链路上任何一个环节断开，openstack server create就会卡在BUILD状态或直接失败。本章聚焦于如何用命令验证 Glance-Nova 链路是否真正打通，而不是只看服务进程是否 running。

3.1 Glance 服务状态：systemctl status只是起点，openstack image list才是终点

Glance 由两个核心服务组成：openstack-glance-api（处理 REST 请求）和openstack-glance-registry（管理元数据，新版已弃用，但 PackStack 部署仍保留）。systemctl status只能证明进程存在，openstack image list才能证明 API 可用、数据库可读、存储后端可访问。

# 检查两个 Glance 服务状态（必须都是 active (running)） systemctl status openstack-glance-api.service openstack-glance-registry.service # 查看 Glance 服务日志（快速定位问题） journalctl -u openstack-glance-api.service -n 50 --no-pager journalctl -u openstack-glance-registry.service -n 50 --no-pager # 查询镜像列表（这是 Glance 可用的黄金标准） openstack image list # 正常输出应有至少一个镜像，Status=active # 若报错 "Connection to glance failed"，说明 openstack-cli 无法连 Glance API # 若返回空列表但无错，说明 Glance API 正常，但数据库无镜像

逻辑说明：openstack image list命令会向OS_IMAGE_API_VERSION=2指定的 Glance API（http://controller:9292/v2）发送 GET/v2/images请求。成功返回意味着：1)openstack-glance-api进程在监听 9292 端口；2)openstack-glance-api能连接数据库（查images表）；3)openstack-glance-api能访问后端存储（如 file、swift、rbd）；4)openstackCLI 的OS_AUTH_URL和 token 能被 Glance 验证。四个条件缺一不可。

参数说明：openstack image list默认只显示Name,ID,Status。加--long可显示Visibility,Protected,Owner等字段，对调试权限问题至关重要。

3.2 上传 Cirros 镜像：openstack image create的四个必填参数与存储后端强相关

Cirros 是 OpenStack 官方推荐的最小化测试镜像，但上传时参数稍有差池，镜像就会卡在queued状态，永远变不成active。这是因为 Glance 的disk-format和container-format必须与镜像文件物理格式严格匹配，且--public参数决定镜像可见范围。

# 下载 Cirros 镜像（确保文件完整） wget http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img # 校验 MD5（官方提供，避免下载损坏） echo "b252e1a0f1b5b1e1a0f1b5b1e1a0f1b5 cirros-0.6.2-x86_64-disk.img" | md5sum -c # 上传镜像（关键参数详解） openstack image create \ --file cirros-0.6.2-x86_64-disk.img \ --disk-format qcow2 \ --container-format bare \ --public \ "cirros-0.6.2"

逻辑说明：--disk-format qcow2告诉 Glance 镜像文件是 qcow2 格式（Cirros 官方镜像就是 qcow2）；--container-format bare表示镜像不包含容器封装（如 OVA、AKI），是裸磁盘镜像；--public使镜像对所有项目可见，否则只有上传者所在项目能用。--file必须是本地路径，Glance 不支持 URL 直传。

参数说明：qcow2是 QEMU 的常用格式，支持快照和压缩；raw是原始二进制格式，性能最好但体积大；vmdk是 VMware 格式。bare是最常用的 container-format；ami用于 Amazon EC2 镜像；ovf用于 OVF 包。选错会导致 Glance 无法解析镜像头，状态卡queued。

3.3 Nova 服务状态：systemctl status+openstack compute service list双重验证

Nova 服务组件多（api, scheduler, conductor, compute, novncproxy），systemctl status只能看单个进程，而openstack compute service list能反映整个 Nova 服务网格的健康状况，特别是State（up/down）和Status（enabled/disabled）字段。

# 检查所有 Nova 相关服务进程（必须全部 active） systemctl status \ openstack-nova-api.service \ openstack-nova-scheduler.service \ openstack-nova-conductor.service \ openstack-nova-novncproxy.service \ openstack-nova-compute.service \ libvirtd.service # 查询 Nova 服务列表（核心验证，看所有组件是否注册且状态为 up） openstack compute service list # 正常输出中，Binary 列应有 nova-api, nova-scheduler, nova-conductor, nova-compute, nova-consoleauth, nova-novncproxy # Host 列应显示 controller, compute01 等节点名 # State 列应全为 'up' # Status 列应全为 'enabled'（若为 'disabled'，需 openstack compute service set --disable xxx）

逻辑说明：openstack compute service list查询nova-api的os-servicesAPI，返回services表数据。State=up表示该服务进程向nova-conductor发送的心跳正常（默认 60 秒）；Status=enabled表示该服务被允许接收任务。nova-compute在 compute 节点上，nova-api在 controller 上，两者必须都up且enabled，openstack server create才能调度成功。

参数说明：openstack compute service list不显示libvirtd状态，但nova-compute严重依赖libvirtd。若nova-compute显示up但虚拟机创建失败，必查systemctl status libvirtd和virsh list --all。

3.4 Nova 组件升级检查：nova-status upgrade check是生产环境上线前的“后悔药”

nova-status upgrade check是 Nova 自带的健康检查工具，它扫描数据库 schema、配置文件一致性、服务版本兼容性。在升级 OpenStack 版本或修改nova.conf后，此命令能提前发现可能导致虚拟机无法创建的深层问题。

# 运行升级检查（在 controller 节点执行） nova-status upgrade check # 正常输出以 "Checking upgrade readiness..." 开头，最后是 "Upgrade check complete." # 若有 FAIL 条目，必须修复后才能继续 # 示例：常见 FAIL 及修复 # FAIL: CellV2 is not ready (cell0 not mapped) # 解决：执行 nova-manage cell_v2 discover_hosts --verbose # FAIL: Database schema versions do not match # 解决：执行 nova-manage db sync # FAIL: Configuration option 'transport_url' not set in [DEFAULT] # 解决：在 /etc/nova/nova.conf 的 [DEFAULT] 段添加 transport_url = rabbit://openstack:RABBIT_PASS@controller

逻辑说明：nova-status upgrade check不是简单的配置校验，它会连接数据库执行 SQL 查询（如SELECT * FROM migrate_version），检查消息队列连接性，并验证nova.conf中关键选项（如transport_url,my_ip,use_neutron）是否设置。每个FAIL都对应一个真实故障点，忽略它上线后虚拟机创建大概率失败。

参数说明：nova-status upgrade check无参数，但依赖nova.conf中[database]和[DEFAULT]配置正确。执行前确保nova用户对数据库有读写权限。

3.5 避坑：镜像与计算服务常见问题排查（现象→原因→解决）

• 现象：openstack image list返回空，但systemctl status openstack-glance-api显示 active
  原因：Glance 配置文件/etc/glance/glance-api.conf中sql_connection指向错误数据库，或default_store = file但/var/lib/glance/images/目录不存在或权限不对
  解决：检查glance-api.conf的[database]和[glance_store]段；执行ls -ld /var/lib/glance/images/确认属主为glance:glance，权限755。

• 现象：openstack image create后openstack image show cirros-0.6.2显示status: queued，数分钟不变成active
  原因：openstack-glance-registry.service未运行，或glance-api.conf中registry_host = 127.0.0.1但glance-registry绑定到0.0.0.0:9191，导致 API 无法注册镜像
  解决：systemctl start openstack-glance-registry；检查glance-api.conf的[paste_deploy]段flavor = keystone是否正确，重启openstack-glance-api。

• 现象：openstack compute service list中nova-compute显示down，但systemctl status openstack-nova-compute是active
  原因：nova-compute进程运行，但未向nova-conductor发送心跳，通常因transport_url配置错误或 RabbitMQ 不可用
  解决：检查/etc/nova/nova.conf的[DEFAULT] transport_url = rabbit://...；执行rabbitmqctl list_queues看nova相关队列是否存在。

• 现象：openstack server create后虚拟机状态长期BUILD，nova list显示ERROR
  原因：nova-compute无法访问 Glance 镜像，常见于glance_api_servers配置为http://localhost:9292（在 compute 节点 localhost 是自己，不是 controller）
  解决：在/etc/nova/nova.conf的[glance]段设置glance_api_servers = http://controller:9292，重启openstack-nova-compute。

• 现象：nova-status upgrade check报FAIL: CellV2 is not ready
  原因：Nova Cell V2 架构未初始化，nova-manage cell_v2 list_cells返回空
  解决：执行nova-manage cell_v2 map_cell0，再nova-manage cell_v2 create_cell --name=cell1 --transport-url=rabbit://openstack:RABBIT_PASS@controller --database-connection=mysql+pymysql://nova:NOVA_DBPASS@controller/nova_cell1，最后nova-manage cell_v2 discover_hosts。

4. 网络与块存储服务：neutron net-create和cinder create的底层依赖验证

网络服务（Neutron）和块存储服务（Cinder）是 OpenStack 中最易出问题的两个服务，因为它们深度耦合 Linux 内核网络栈（bridge, ovs, iptables）和存储驱动（LVM, NFS, Ceph）。openstack network list成功不代表neutron-server能创建网络，cinder service-list显示up也不代表cinder-volume能创建卷。本章教你绕过 CLI 表象，直击 Neutron Agent 和 Cinder Volume 的真实工作状态。

4.1 Neutron 服务状态：systemctl status+openstack network agent list双保险

Neutron 架构复杂，neutron-server是中心 API，但真正干活的是各类 Agent：linuxbridge-agent（处理 L2 网络）、dhcp-agent（提供 DHCP）、metadata-agent（传递 metadata）。systemctl status只能看进程，openstack network agent list才能看 Agent 是否注册、是否alive、是否admin_state_up。

# 检查所有 Neutron 服务进程（controller 节点） systemctl status \ neutron-server.service \ neutron-linuxbridge-agent.service \ neutron-dhcp-agent.service \ neutron-metadata-agent.service # 查询 Neutron Agent 列表（关键验证，看所有 Agent 是否在线） openstack network agent list # 正常输出中，Agent Type 应有 'Linux bridge agent', 'DHCP agent', 'Metadata agent' # Host 列应显示 controller, compute01 等 # Alive 列应全为 ':-)'（笑脸表示 alive） # Admin State Up 列应全为 'True' # Binary 列应为 neutron-linuxbridge-agent 等

逻辑说明：openstack network agent list查询neutron-server的agentsAPI，返回agents表数据。Alive=:-)表示该 Agent 进程向neutron-server发送的心跳正常（默认 60 秒）；Admin State Up=True表示管理员未手动禁用该 Agent。neutron-linuxbridge-agent在 compute 节点上，负责创建 br-int、br-eth0 等网桥，并将虚拟机 tap 设备接入；若它Alive为XXX，虚拟机网络必然不通。

参数说明：openstack network agent list的Binary字段显示 Agent 类型，Host字段显示运行节点。neutron-server本身不显示在此列表中，它是中心服务。

4.2 ML2 配置解析：ml2_conf.ini中type_drivers与tenant_network_types的隐式依赖

ML2（Modular Layer 2）是 Neutron 的核心插件，ml2_conf.ini是其配置心脏。type_drivers定义支持的网络类型（flat, vlan, vxlan），tenant_network_types定义租户网络默认类型。二者不匹配，neutron net-create会静默失败或创建出无法使用的网络。

# 查看 ml2 配置（关键段） grep -E "^(type_drivers|tenant_network_types|mechanism_drivers)" /etc/neutron/plugins/ml2/ml2_conf.ini # 正常输出示例： # type_drivers = flat,vlan,vxlan # tenant_network_types = vxlan # mechanism_drivers = linuxbridge,l2population # 验证 linuxbridge_agent 配置（必须与 ml2_conf.ini 一致） grep -E "^(physical_interface_mappings|enable_security_group)" /etc/neutron/plugins/ml2/linuxbridge_agent.ini # 正常输出示例： # physical_interface_mappings = provider:ens160 # enable_security_group = True

逻辑说明：type_drivers = flat,vlan,vxlan表示 ML2 支持这三种网络类型；tenant_network_types = vxlan表示租户网络默认用 vxlan。若tenant_network_types = vlan但physical_interface_mappings中没有vlan:ens160，neutron net-create --provider:network_type vlan就会失败。mechanism_drivers = linuxbridge表示用 Linux Bridge 实现 L2，必须与linuxbridge_agent.ini中的physical_interface_mappings对应。

参数说明：physical_interface_mappings = provider:ens160将物理网卡ens160映射为 provider 网络（外部网络），provider是自定义名字，可在neutron net-create时通过--provider:physical_network provider引用。

4.3 Cinder 服务状态：systemctl status+cinder service-list+targetcli三层验证

Cinder 服务包括cinder-api,cinder-scheduler,cinder-volume。cinder-volume是核心，它通过 LVM、NFS 或 Ceph 驱动创建卷。systemctl status看进程，cinder service-list看注册状态，targetcli看 iSCSI target 是否真正导出。

# 检查 Cinder 服务进程（controller 和 storage 节点） systemctl status \ openstack-cinder-api.service \ openstack-cinder-scheduler.service \ openstack-cinder-volume.service \ target.service # 查询 Cinder 服务列表（看 volume 服务是否 up） cinder service-list # 正常输出中，Binary 列应有 cinder-volume，Host 列应为 storage-node，State 应为 up，Status 应为 enabled # 验证 iSCSI target（LVM 后端必备） targetcli ls # 正常输出应显示 /backstores/block 和 /iscsi 下的 target，如： # o- iscsi ..................................................................... [...] # o- targets ................................................................... [...] # o- iqn.2010-10.org.openstack:volume-xxxxxxxxxxxx ......................... [...]

逻辑说明：cinder-volume服务启动时，会调用targetcli创建 iSCSI target 并导出 LVM 逻辑卷。target.service是targetcli的 systemd 服务，必须 running。targetcli ls直接查看内核 target framework 状态，比cinder service-list更底层。若cinder service-list显示up但targetcli ls无输出，说明cinder-volume未成功创建 target，常见于 LVM VG 不存在或cinder.conf中volume_group = cinder-volumes错误。

参数说明：targetcli是 Linux 内核 target framework 的命令行工具，ls命令列出所有 iSCSI target。iqn.2010-10.org.openstack:volume-xxx是 Cinder 自动生成的 target 名。

4.4 创建 provider 网络：neutron net-create的三个强制参数与物理网卡绑定

Provider 网络是 OpenStack 外部网络（如公司办公网），它直接映射到物理网卡。创建时必须指定--provider:physical_network（与linuxbridge_agent.ini中physical_interface_mappings的 key 一致）、--provider:network_type（flat/vlan）、--provider:segmentation_id（vlan id，flat 类型无需）。

# 创建 flat 类型 provider 网络（最简单，用于测试） neutron net-create \ --provider:physical_network provider \ --provider:network_type flat \ --shared \ provider-flat # 创建 vlan 类型 provider 网络（生产常用） neutron net-create \ --provider: <p> <a href="https://download.csdn.net/download/Lincon/64870409" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>