企业官网建设流程全解析

简介：本资源是一份面向云计算初学者与运维工程师的OpenStack私有云实战搭建指南，聚焦IaaS层基础平台部署，解决从零构建可用私有云环境的核心问题。文档以清晰步骤链贯穿全流程：涵盖主机名与hosts映射配置、SELinux与防火墙调优、YUM源配置、iaas-xiandian软件包安装、Glance镜像上传与创建、Cinder云硬盘与Neutron内外网定义等关键操作，特别包含控制节点与计算节点双机协同部署要点及浮动IP绑定、卷挂载等典型业务验证环节。资源为单个Word文档（.doc格式），体积仅119KB，内容精炼、指令明确、目录层级完整，便于逐项对照执行与笔记批注。目前已有619人学习下载，适合作为高校云计算课程实验参考、企业私有云POC快速落地手册或OpenStack认证备考实操补充材料。

1. OpenStack 私有云搭建：不是装完就跑的“一键脚本”，而是网络、存储、认证三线并行的系统工程

你手头这份openstack私有云搭建.doc，表面看是份竞赛类实训文档（带chinaskills_cloud_iaas.iso和iaas-xiandian包），但实际是一套高度收敛、强依赖环境约束的 OpenStack 部署流水线——它不面向生产环境高可用架构，也不走 DevStack 或 Kolla 这类通用路径，而是专为教学验证与技能考核设计的“最小可行私有云”。它用两台物理/虚拟机（controller + compute）硬编码了网络拓扑、服务依赖和密码策略，所有组件（Keystone、Glance、Nova、Neutron、Cinder、Horizon）通过 shell 脚本串行安装，跳过容器化、跳过 HA、跳过 TLS，但恰恰因此，它成了理解 OpenStack 各服务间真实调用链路的“黑匣子解剖图”：比如iaas-install-neutron-controller.sh里如何把br-ex桥绑定到物理网卡、neutron router-gateway-set怎么触发 L3 agent 的 SNAT 规则生成、openstack server add volume背后 Cinder 如何调度 LVM 卷并通知 Nova 挂载。如果你正被 OpenStack 的“服务太多、报错太散、日志太深”卡住，这份文档就是你的第一块拆解板——它不教你“云是什么”，它逼你亲手把openrc.sh里的HOST_IP_NODE和INTERFACE_NAME对齐真实网卡，把BLOCK_DISK=sda3和lsblk输出反复比对，把neutron subnet-create的 CIDR 和network_segment_IP做数学校验。新手靠它建立 OpenStack 组件地图，熟手靠它反推服务启动顺序与依赖断点。别把它当说明书，它是张必须手填的电路图。

2. 环境筑基：从主机名、SELinux 到 YUM 源，每一步都在为后续服务启动埋下伏笔

OpenStack 不是独立运行的单体应用，它的每个服务进程都像精密钟表里的齿轮，必须在特定时间、特定权限、特定网络上下文中咬合。而环境筑基阶段，就是给这些齿轮上油、校准、固定底座的过程。跳过或潦草处理这一步，后续iaas-install-*脚本失败率会陡增 70% 以上——不是脚本有问题，是你没给它准备好“呼吸的空气”。

2.1 主机名与 hosts 映射：服务发现的底层协议锚点

OpenStack 服务间通信大量依赖 hostname 解析（如 Nova 计算节点向 Keystone controller 发起 token 校验时，URL 中的controller必须能被 DNS 或/etc/hosts解析）。文档中要求：

# 控制节点执行 hostnamectl set-hostname controller # 计算节点执行 hostnamectl set-hostname compute

注意：hostnamectl set-hostname修改的是hostname，但 OpenStack 服务（尤其是 Neutron agent）实际读取的是/proc/sys/kernel/hostname，而该值在hostnamectl后需Ctrl+D退出当前 session 才刷新。更稳妥做法是执行sysctl kernel.hostname=controller并写入/etc/sysctl.conf。

接着在/etc/hosts中硬编码映射：

# /etc/hosts（控制节点） 192.168.1.130 controller 192.168.1.140 compute # 注意：必须包含本机 IP + hostname，否则 keystone-admin-openrc.sh 中的 export OS_AUTH_URL=http://controller:5000/v3 会解析失败

逻辑说明：openstackCLI 工具默认使用http://controller:5000/v3作为认证端点。若controller无法解析，source /etc/keystone/admin-openrc.sh后执行openstack token issue直接报Connection refused，而非提示“host not found”。这是新手最常踩的第一个坑——以为网络通就行，忽略了服务发现层。

2.2 SELinux 与防火墙：不是简单关闭，而是精准降权

文档要求将 SELinux 设为permissive并清空 iptables 规则。这不是偷懒，而是规避 OpenStack 复杂安全上下文带来的权限冲突：

• SELINUX=permissive在/etc/selinux/config中设置后，必须重启系统（reboot）才生效。setenforce 0只是临时切换，且部分 OpenStack 服务（如httpdfor Horizon）在启动时会检查/etc/selinux/config，若仍为enforcing，可能拒绝加载模块。
• iptables -F清空规则后，iptables-save > /etc/sysconfig/iptables是必须操作。否则重启后规则恢复，Neutron 的br-int、br-ex桥流量会被 DROP。

参数说明：iptables -Z清空计数器，iptables -X删除用户自定义链——这两步确保iptables -L输出干净，避免旧链干扰neutron-server启动时的iptables_manager初始化。

2.3 YUM 源配置：本地镜像挂载是性能与稳定性的双重保障

文档使用chinaskills_cloud_iaas.iso提供定制化 RPM 包（含iaas-xiandian、openstack-ocata或pike版本组件），而非公网源。原因有三：

• 公网源包版本碎片化，iaas-install-*脚本硬编码了包名与依赖关系；
• 本地挂载避免网络波动导致yum install中断；
• iaas-repo目录内含repodata，yum makecache速度远超远程同步。

挂载命令：

# 控制节点执行（计算节点同理） mkdir -p /opt/centos /opt/iaas mount -o loop CentOS-7-x86_64-DVD-1804.iso /opt/centos mount -o loop chinaskills_cloud_iaas.iso /opt/iaas # 验证挂载 lsblk | grep loop # 应显示两个 loop 设备 df -h | grep opt # 应显示 /opt/centos 和 /opt/iaas 占用

逻辑说明：mount -o loop将 ISO 文件当作块设备挂载，使file:///opt/centos成为有效baseurl。若挂载失败，yum repolist会报Cannot retrieve metalink...，而非具体包缺失——这是排查 YUM 源问题的第一信号。

2.4 FTP/HTTP 服务选型：计算节点获取源的两种路径与实操差异

计算节点无法直接挂载 ISO，需通过网络访问控制节点的/opt/centos和/opt/iaas/iaas-repo。文档给出 FTP 和 HTTP 两种方案，推荐 HTTP，原因如下：

实操建议：HTTP 方案中，执行ln -s /opt/centos /var/www/html/centos和ln -s /opt/iaas/iaas-repo /var/www/html/iaas-repo，比修改httpd.conf更安全。firewall-cmd --add-service=http --permanent && firewall-cmd --reload必须执行，否则计算节点yum repolist会超时。

3. 配置驱动：openrc.sh是 OpenStack 的“DNA 序列”，改错一个字段全盘崩溃

/etc/xiandian/openrc.sh不是普通环境变量文件，它是整个 IaaS-Xiandian 自动化部署的唯一配置中枢。所有iaas-install-*.sh脚本都 source 它来获取 IP、密码、网卡名等参数。它的错误不会立即报错，而是在服务启动后表现为：Keystone token 无效、Neutron agent 无法注册、Cinder volume 无法 attach——此时 debug 日志里满屏ConnectionRefusedError或Unauthorized，根源却在openrc.sh里一个HOST_IP写错。

3.1 关键字段解析：哪些必须改？哪些可不动？

# /etc/xiandian/openrc.sh（控制节点示例） HOST_IP=192.168.1.130 # ✅ 必须：控制节点管理 IP，Keystone/Nova API 监听地址 HOST_PASS=000000 # ✅ 必须：所有数据库 root 密码（MySQL）、RabbitMQ 密码、服务账户密码 HOST_NAME=controller # ✅ 必须：与 hostnamectl 设置一致 HOST_IP_NODE=192.168.1.140 # ✅ 必须：计算节点管理 IP，Nova-compute 连接 controller 的地址 INTERFACE_IP=192.168.1.130 # ✅ 必须：Neutron external network 绑定的物理网卡 IP（通常与 HOST_IP 同网卡） INTERFACE_NAME=p4p1 # ⚠️ 必须：物理网卡名！用 `ip link show` 确认，非 eth0/enp0s3 Physical_NAME=provider # ⚠️ 必须：Neutron provider network 名称，脚本中用于创建 `br-ex` BLOCK_DISK=sda3 # ⚠️ 必须：计算节点上用于 Cinder LVM 的空白分区，`fdisk -l` 确认 STORAGE_LOCAL_NET_IP=192.168.1.140 # ✅ 必须：计算节点 storage 网络 IP（若与管理网分离）

血泪经验：INTERFACE_NAME错配是 Neutron 安装失败的头号原因。例如脚本中ovs-vsctl add-br br-ex && ovs-vsctl add-port br-ex p4p1，若实际网卡是ens33，则br-ex无物理出口，neutron-server启动后neutron agent-list显示XXX down。解决方法：ip link show查真实网卡名，ovs-vsctl show看 bridge 状态，tcpdump -i p4p1 port 67 or port 68抓 DHCP 流量验证连通性。

3.2 密码策略：为什么所有*_PASS都设为000000？

这不是弱密码倡导，而是 IaaS-Xiandian 脚本的硬编码约定：

• DB_PASS=000000→ MySQL root 密码，iaas-install-mysql.sh中mysqladmin -u root password 000000；
• RABBIT_PASS=000000→ RabbitMQ guest 用户密码，iaas-install-rabbitmq.sh中rabbitmqctl change_password guest 000000；
• ADMIN_PASS=000000→ Keystone admin 用户密码，iaas-install-keystone.sh中openstack user create --password 000000 admin。

避坑：若你擅自改成Admin@123，iaas-install-glance.sh中openstack endpoint create ... --url http://controller:9292会因 Keystone 认证失败而卡住。脚本不校验密码强度，只按固定字符串匹配。生产环境需替换，但学习阶段请严格遵循。

3.3 网络段规划：network_segment_IP与Physical_NAME的协同逻辑

network_segment_IP=192.168.1.0/24 # ✅ 管理网络 CIDR，Nova、Neutron agent 通信网段 Physical_NAME=provider # ✅ provider network 名，Neutron 创建 external network 时引用 minvlan=2 maxvlan=200 # ✅ VLAN ID 范围，仅当使用 VLAN provider network 时生效

原理说明：Physical_NAME=provider会在iaas-install-neutron-controller.sh中触发：

ovs-vsctl add-br br-provider ovs-vsctl add-port br-provider $Physical_NAME

此时br-provider桥将接管provider网卡的流量。若Physical_NAME错配，br-provider无端口，neutron net-create --provider:physical_network provider直接报错Provider physical network provider is not associated with any bridge.

3.4 配置分发与校验：scp不是终点，source才是起点

控制节点配置好openrc.sh后，需分发至计算节点并二次修改：

# 控制节点执行 scp /etc/xiandian/openrc.sh root@compute:/etc/xiandian/openrc.sh # 计算节点执行（必须！） sed -i 's/HOST_IP=192.168.1.130/HOST_IP=192.168.1.140/g' /etc/xiandian/openrc.sh sed -i 's/INTERFACE_IP=192.168.1.130/INTERFACE_IP=192.168.1.140/g' /etc/xiandian/openrc.sh # 若计算节点网卡名不同，还需改 INTERFACE_NAME

逻辑说明：iaas-pre-host.sh脚本会读取openrc.sh中的HOST_IP来判断本机角色（if [ "$HOST_IP" == "$HOST_IP_NODE" ]; then），若未修改，计算节点会误执行 controller 脚本，导致服务端口冲突。

4. 服务安装：iaas-install-*.sh脚本链不是黑盒，而是可打断、可重入的原子操作

IaaS-Xiandian 的核心价值在于其脚本链的可调试性。每个iaas-install-*.sh都是独立 shell 脚本，内部有清晰的set -e（出错退出）、source /etc/xiandian/openrc.sh、yum install、systemctl start、openstackCLI 初始化步骤。它不像 Packstack 那样封装成单个 Python 进程，你可以随时Ctrl+C中断，查看日志，修复配置，再重新执行——这才是工程师该有的掌控感。

4.1 安装顺序的底层逻辑：为什么必须 controller 先于 compute？

OpenStack 服务存在强依赖链：

MySQL/RabbitMQ → Keystone → Glance → Nova-controller → Neutron-controller → Dashboard ↓ Nova-compute → Neutron-compute

• iaas-install-mysql.sh和iaas-install-rabbitmq.sh必须最先执行，为所有服务提供数据与消息总线；
• iaas-install-keystone.sh创建 service project、admin user、endpoint，后续所有服务注册都依赖它；
• iaas-install-glance.sh需要 Keystone token 才能openstack image create；
• iaas-install-nova-controller.sh启动nova-api、nova-scheduler，但nova-compute服务启动时会向 controller 的nova-api注册，故 controller 必须先就绪。

实操验证：若先执行iaas-install-nova-compute.sh，日志/var/log/nova/nova-compute.log会出现：

ERROR nova.service Unable to establish connection to http://controller:8774/v2.1/os-services

此时systemctl status openstack-nova-api必为inactive (dead)。

4.2 脚本执行与日志定位：哪里出错？看哪几行？

每个脚本执行后，必须检查三处：

1. 脚本自身输出：末尾应有Install Success!或类似提示；
2. systemd 服务状态：

   systemctl status openstack-keystone # 应 active (running) systemctl status neutron-server # 应 active (running)

3. 关键日志文件：
   • Keystone：/var/log/keystone/keystone.log→ 查Starting Keystone和WSGI启动行；
   • Neutron：/var/log/neutron/server.log→ 查Neutron server started和Agent RPC connected；
   • Nova：/var/log/nova/nova-api.log→ 查Starting nova-api和Loaded extension。

参数说明：iaas-install-keystone.sh中openstack service create --name keystone --description "OpenStack Identity" identity是服务注册起点，若此步失败，后续所有openstack endpoint create均报No service with a type, name, or id of 'identity' exists。

4.3 Dashboard 安装的隐藏依赖：httpd与mod_wsgi的版本陷阱

iaas-install-dashboard.sh实际是安装openstack-dashboard（Horizon），它依赖 Apache HTTP Server (httpd) 和 Python WSGI 模块 (mod_wsgi)。常见翻车点：

• httpd版本过高（如 2.4.53+）与mod_wsgi不兼容，导致systemctl start httpd启动失败；
• /etc/httpd/conf.d/openstack-dashboard.conf中WSGIScriptAlias路径错误，访问http://controller/dashboard报404 Not Found；
• local_settings.py中OPENSTACK_HOST = "controller"未与/etc/hosts一致。

排查命令：

# 查看 mod_wsgi 是否加载 httpd -M | grep wsgi # 查看 dashboard 配置语法 httpd -t # 查看 apache 错误日志 tail -f /var/log/httpd/error_log

4.4 避坑：iaas-pre-host.sh与iaas-install-*.sh的执行边界

文档要求“前 9 个步骤完成无误后，安装 iaas-xiandian 软件包”，但新手常忽略iaas-pre-host.sh的作用：

# iaas-pre-host.sh 核心功能 # 1. 创建 /etc/xiandian 目录 # 2. 拷贝 openrc.sh 模板 # 3. 设置 selinux permissive（再次确认） # 4. 关闭 firewalld（若启用） # 5. 启动 ntpd（确保时间同步，Keystone token 依赖时间戳）

常见问题与解决：

现象：iaas-install-keystone.sh执行到openstack domain create --description "An Example Domain" example报错Connection refused
原因：iaas-pre-host.sh未执行，firewalld未关闭，iptables规则阻断 5000 端口
解决：systemctl stop firewalld && systemctl disable firewalld，再重试

现象：iaas-install-nova-controller.sh中openstack compute service list为空
原因：iaas-pre-host.sh未执行，ntpd未启动，controller 与 compute 时间差 > 5 分钟，Keystone token 被拒
解决：systemctl start ntpd && systemctl enable ntpd，ntpdate controller同步时间

现象：iaas-install-neutron-controller.sh执行后neutron agent-list显示l3-agent为down
原因：iaas-pre-host.sh未执行，openvswitch服务未启动，ovs-vsctl show无 bridge
解决：systemctl start openvswitch && systemctl enable openvswitch

5. OpenStack CLI 实战：从镜像、网络到虚拟机，每条命令背后都是服务协作

Dashboard 图形界面只是表象，OpenStack 的灵魂在 CLI。文档第 12 节列出的openstack命令，本质是调用 Keystone、Glance、Nova、Neutron 的 REST API。理解每条命令触发的服务链，才能真正驾驭私有云。

5.1 镜像上传：Glance 服务的双模式与格式陷阱

# 方式一：openstack CLI（推荐，API v3） openstack image create cirros \ --disk-format qcow2 \ --container-format bare \ --file /root/cirros-0.3.3-x86_64-disk.img \ --public # 方式二：glance CLI（API v2，兼容旧脚本） glance image-create \ --name cirros \ --disk-format qcow2 \ --container-format bare \ --file /root/cirros-0.3.3-x86_64-disk.img \ --is-public True

原理说明：--disk-format qcow2指定镜像文件格式（QEMU Copy-On-Write），--container-format bare表示无元数据封装。若传入 ISO 文件（如CentOS-7-x86_64-DVD-1804.iso），Glance 会拒绝，因 ISO 不是可启动磁盘镜像。--public使镜像对所有 project 可见，否则需openstack image set --project demo cirros。

5.2 网络拓扑：external 与 internal 的隔离本质

# 创建 external network（物理网络直通） openstack network create --external --provider-network-type flat --provider-physical-network provider ext-net # 创建 internal network（租户网络，由 Neutron L2 agent 隔离） openstack network create int-net # 创建 external subnet（关联物理网关） openstack subnet create --network ext-net --subnet-range 192.168.1.0/24 --gateway 192.168.1.1 --dns-nameserver 114.114.114.114 ext-subnet # 创建 internal subnet（租户私有网段） openstack subnet create --network int-net --subnet-range 10.0.0.0/24 --gateway 10.0.0.1 --dns-nameserver 114.114.114.114 int-subnet

关键区别：--external参数让ext-net被标记为router:external=True，只有此类网络才能被neutron router-gateway-set绑定为路由器的外部网关。int-net无此标记，只能作为内部接口。--provider-network-type flat表示不封装 VLAN，直接使用物理网卡带宽。

5.3 路由器与浮动 IP：SNAT/DNAT 的命令级实现

# 创建路由器 openstack router create router # 绑定 external network（启用 SNAT） openstack router set --external-gateway ext-net --enable-snat router # 添加 internal subnet 接口（启用 DNAT） openstack router add subnet router int-subnet # 创建浮动 IP（从 external subnet 分配） openstack floating ip create ext-net # 绑定浮动 IP 到虚拟机 openstack server add floating ip vm1 192.168.1.150

底层机制：openstack router set --enable-snat触发 Neutron L3 agent 在br-ex上添加 iptables SNAT 规则：-A POSTROUTING -s 10.0.0.0/24 -j SNAT --to-source 192.168.1.130；openstack floating ip create在br-ex上添加 DNAT 规则：-A PREROUTING -d 192.168.1.150 -j DNAT --to-destination 10.0.0.2（假设 vm1 内网 IP 为 10.0.0.2）。

5.4 云硬盘挂载：Cinder 与 Nova 的协同工作流

# 创建卷类型（Cinder） openstack volume type create ssd # 创建云硬盘（Cinder） openstack volume create --size 1 --type ssd examlv1 # 将云硬盘附加到虚拟机（Nova 调用 Cinder API） openstack server add volume vm1 examlv1 # 在虚拟机内操作（vm1 OS 层） sudo fdisk /dev/vdb # 分区 sudo mkfs.xfs /dev/vdb1 # 格式化 sudo mkdir /data && sudo mount /dev/vdb1 /data

服务协作：openstack server add volume命令触发 Nova-compute 调用 Cinder API 创建 attachment，Cinder 通过 iSCSI 或 LVM 将卷映射到计算节点/dev/vdb，Nova 再通过 libvirt 将该设备透传给虚拟机。ls /dev/vd*在 vm1 内看到/dev/vdb，证明透传成功。

5.5 常见问题排查：CLI 报错的三分钟定位法

提示：所有openstack命令加--debug参数可输出完整 HTTP 请求/响应，如openstack server list --debug 2>&1 | grep -A 20 "REQ:"，这是定位 API 层问题的终极手段。

6. 故障注入与验证：用tcpdump和ip netns穿透 OpenStack 网络黑匣子

OpenStack 最让人抓狂的不是服务起不来，而是服务起来了，虚拟机却 ping 不通外网——此时日志里没有 ERROR，只有 INFO，仿佛一切正常。真正的验证，必须跳出 CLI 和 Dashboard，用底层工具刺穿网络虚拟化层。我从那以后，每次部署完 Neutron，都强制走一遍tcpdump抓包 +ip netns进入 namespace 查路由，这成了我的后悔药。

6.1 抓包定位：从虚拟机到外网的五段式流量追踪

假设 vm1（10.0.0.2）要访问www.baidu.com，流量路径为：

vm1 eth0 → qbr-xxx → qvo-xxx → br-int → qr-xxx（router namespace）→ br-ex → p4p1 → 外网

步骤 1：在 vm1 内抓包

# 进入 vm1 控制台（Horizon 或 nova console-log vm1） ping -c 3 www.baidu.com # 在 vm1 内执行 tcpdump -i eth0 icmp -nn # 应看到 ICMP request 发出

步骤 2：在计算节点 qbr 桥抓包

# 计算节点执行（qbr 是 Linux bridge，连接 vm1 tap 设备） tcpdump -i qbr-xxx icmp -nn # 应看到相同 ICMP request

步骤 3：在 br-int 桥抓包

# br-int 是 OVS integration bridge tcpdump -i br-int icmp -nn # 应看到 request，但目的 IP 已被 SNAT 改为 192.168.1.130

步骤 4：进入 router namespace 抓包

# 获取 router namespace 名称 ip netns list | grep qrouter # 进入 namespace（假设为 qrouter-abc123） ip netns exec qrouter-abc123 tcpdump -i qr-xxx icmp -nn # qr-xxx 是 router 的 internal interface，应看到 SNAT 后的包

步骤 5：在 br-ex 桥抓包

# br-ex 是 OVS external bridge tcpdump -i br-ex icmp -nn # 应看到包从 qr-xxx 流向 qg-xxx（router external interface）

关键洞察：若步骤 1 有包，步骤 2 没包 → vm1 tap 设备未正确 attach 到 qbr；若步骤 2 有包，步骤 3 没包 → OVS flow table 未命中，ovs-ofctl dump-flows br-int查 rule；若步骤 3 有包，步骤 4 没包 → router namespace 未启用，ip netns exec qrouter-xxx ip a查 qr-xxx 是否 UP。

6.2 namespace 深度诊断：ip netns exec是 Neutron 的 X 光机

Neutron 的 router、dhcp、l3 agent 都运行在独立 network namespace 中。ip netns是透视它们的唯一窗口：

# 查看所有 namespace ip netns list # 进入 dhcp namespace（对应 int-net） ip netns exec qdhcp-xxx ip a # 应看到 dhcp port（如 10.0.0.1）UP 状态 # 查看 dhcp namespace 路由 ip netns exec qdhcp-xxx ip route # 应有 default via 10.0.0.1 dev tapxxx # 进入 router namespace ip netns exec qrouter-xxx ip a # 应看到 qr-xxx（10.0.0.1）和 qg-xxx（192.168.1.130）两个 interface # 查看 router 路由表 ip netns exec qrouter-xxx ip route # 应有 10.0.0.0/24 via 10.0.0.1 dev qr-xxx 和 default via 192.168.1.1 dev qg-xxx

避坑：ip netns exec需要iproute2包支持，若报command not found，yum install iproute -y。namespace 名称中的xxx是 UUID，neutron router-show router输出的id字段后 12 位。

6.3 Cinder LVM 验证：绕过 Nova，直击存储后端

当openstack volume create成功但openstack server add volume失败时，问题常在 Cinder 存储后端：

# 查看 Cinder-volume 服务状态 systemctl status openstack-cinder-volume # 查看 LVM VG 状态 vgdisplay cinder-volumes # 应显示 VG Size 和 Free PE # 查看 Cinder 卷状态 cinder list # 应显示 volume 状态为 available # 在计算节点查看是否识别到卷 ls /dev/mapper/ # 应有 cinder--volumes-volume-xxx 设备 # 手动映射卷到虚拟机（模拟 Nova 操作） kpartx -av /dev/mapper/cinder--volumes-volume-xxx # 应输出 add map cinder--volumes-volume-xxxp1

原理说明：cinder-volume服务将BLOCK_DISK=sda3初始化为 LVM PV，创建 VGcinder-volumes。cinder create命令在此 VG 中分配 LV，nova-compute通过 libvirt 将 LV 作为块设备透传给虚拟机。kpartx命令验证 LV 是否可被内核识别，是排除存储层问题的黄金步骤。

6.4 Horizon 登录失败的终极排查：从 cookie 到 session backend

http://controller/dashboard打不开，常见于：

• httpd服务未启动：systemctl status httpd；
• memcached未启动（Horizon session backend）：systemctl status memcached；
• local_settings.py中ALLOWED_HOSTS = ['controller']未包含访问 IP；
• 浏览器 cookie 残留导致 CSRF token mismatch。

快速修复：

# 清空 Horizon session rm -rf /var/lib/openstack-dashboard/SESSIONS/* #

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