Horizon访问物理机共享失败怎么办？

Horizon控制台无法访问物理机共享资源，通常由权限配置错误、网络策略限制或共享服务异常导致，需检查相关设置与服务状态。

问题描述：
当您尝试通过OpenStack的Horizon仪表板访问挂载在物理机（计算节点或裸金属节点）上的共享存储（如NFS、Cinder卷、或其他类型的共享文件系统）时，操作失败或无法看到预期的内容，这通常表现为实例无法挂载卷、无法访问共享目录、或者在Horizon界面中相关操作按钮失效或报错。

问题根源分析：
导致Horizon无法有效访问物理机共享存储的原因是多方面的，通常涉及OpenStack各组件间的配置、网络连接、权限或服务状态问题,以下是最常见的排查方向：

网络连通性问题：
- 控制节点 -> 物理机： Horizon本身不直接访问物理机，但它依赖的后端服务（如Nova-Compute, Cinder-Volume）需要与物理机通信，确保控制节点（运行Horizon、Nova-API、Cinder-API等服务的节点）的网络能够到达物理机的管理IP地址和存储网络IP地址（如果分离）。
- 物理机 -> 存储设备： 物理机（计算节点）本身必须能够通过网络访问提供共享存储的服务端（如NFS服务器、Cinder存储后端、分布式存储集群节点等），检查物理机到存储设备IP的连通性（ping）和端口访问性（telnet 或 nc -zv）。
- 存储网络隔离： 如果使用了独立的存储网络（推荐），确保所有相关组件（物理机、存储设备、控制节点上的Cinder/Nova服务）都正确配置并连接在该网络上,且路由或VLAN配置正确。
防火墙规则阻挡：
- 物理机防火墙： 物理机（计算节点）上的防火墙（如firewalld、iptables、ufw）可能阻止了来自控制节点服务或存储设备的入站连接，或者阻止了出站到存储设备的连接，需要开放必要的端口（例如NFS的111, 2049, 20048；iSCSI的3260；Ceph的6789, 6800-7300等）。
- 存储设备防火墙： 共享存储服务器本身的防火墙必须允许来自物理机（计算节点）IP地址的访问。
- 控制节点防火墙： 虽然Horizon不直连物理机存储，但运行在其上的服务（如Nova API）与物理机的通信不能被本机防火墙阻断。
OpenStack服务状态异常：
- Nova-Compute: 运行在物理机上的nova-compute服务负责管理实例和挂载存储，检查其状态 (systemctl status nova-compute) 和日志 (/var/log/nova/nova-compute.log) 是否有错误,特别是关于挂载卷或访问共享存储的报错。
- Cinder-Volume (如果使用Cinder卷)： 如果挂载的是Cinder卷，确保Cinder-Volume服务（可能运行在控制节点或专用存储节点）状态正常 (systemctl status cinder-volume) 且日志 (/var/log/cinder/cinder-volume.log) 无相关错误,Cinder调度器需要能正确与后端存储驱动通信。
- Nova-API / Cinder-API: Horizon通过调用这些API来执行操作，检查API服务状态 (systemctl status nova-api, systemctl status cinder-api) 和日志,确保它们正常运行并能处理来自Horizon的请求。
- Horizon (Apache/httpd)： 虽然问题根源通常不在Horizon本身，但检查其服务状态 (systemctl status httpd 或 apache2) 和日志 (/var/log/httpd/error_log 或 /var/log/apache2/error.log) 可以排除前端问题或认证问题。
OpenStack配置错误：
- Nova 配置 (nova.conf on Compute Node)：
  - [libvirt] 部分：virt_type (如kvm), inject_password, inject_key 等设置可能影响存储挂载行为（虽然较少直接导致无法访问，但配置不当可能引发问题）。
  - [DEFAULT] 部分：compute_driver (如libvirt.LibvirtDriver) 必须正确。
  - 挂载点权限： 确保Nova-Compute服务运行的用户（通常是nova或libvirt）对物理机上用于挂载共享存储的本地目录（如/var/lib/nova/instances 或 /mnt/nfs）拥有读写权限，这是极其常见的问题根源。
- Cinder 配置 (cinder.conf on Controller & Volume Node – 如果使用Cinder)：
  - [DEFAULT] 部分：enabled_backends 定义了使用的存储后端。
  - [backend_name] 部分 (如 [lvm], [nfs]): 后端的特定配置必须准确无误，包括存储设备的访问路径/IP、认证信息、挂载选项等，对于NFS后端，nfs_shares_config 文件路径必须正确,且文件内容列出了有效的NFS共享路径。
  - 权限与用户映射： 如果存储后端（如NFS）有用户/组权限要求，确保Cinder-Volume服务运行的用户（通常是cinder）在存储设备上有相应的访问权限，或者正确配置了nas_secure_file_permissions/nas_share_path等选项进行用户映射。
- Neutron 配置 (如果存储网络依赖Neutron)： 如果存储流量走租户网络或特定的Provider Network，确保网络配置正确，安全组规则允许必要的流量（但通常存储流量建议走管理或存储专用网络，避免依赖租户网络安全组）。
共享存储本身的问题：
- 存储服务状态： 检查NFS服务器、iSCSI Target、Ceph集群、SAN设备等共享存储提供方的服务是否正常运行。
- 存储空间： 目标共享存储是否有足够的空间和inode？
- 导出/共享设置： NFS的/etc/exports文件是否正确配置，允许物理机（计算节点）的IP访问？iSCSI Target的LUN是否正确映射并授权给计算节点？Ceph的pool权限和密钥是否正确？
- 挂载选项： 在OpenStack配置中指定的挂载选项（如nfs_options）是否与存储服务器兼容？不兼容的选项可能导致挂载失败。
认证与权限问题：
- Keystone 令牌： Horizon使用用户的Keystone令牌进行认证，确保用户有足够的权限（如member角色）执行挂载卷等操作，尝试使用管理员账号在Horizon操作看是否可行,以区分是权限问题还是配置问题。
- 存储认证： 如果共享存储本身需要认证（如Ceph的cephx，某些iSCSI Target的CHAP）,确保在Cinder后端配置或Nova配置中正确提供了密钥或认证信息。

专业排查步骤 (建议按顺序)：

基础检查：
- 确认Horizon登录用户拥有操作实例和卷的必要权限。
- 在Horizon界面检查Nova-Compute服务状态（管理员 -> 系统 -> 计算服务）和目标物理机（计算节点）的状态是否Up。
- 检查Cinder服务状态（管理员 -> 系统 -> 卷服务）和存储后端状态。
日志分析 (关键！)：
- 物理机 (Compute Node)： 重点查看 /var/log/nova/nova-compute.log，搜索实例ID、卷ID或错误关键字（如mount, nfs, iscsi, Permission denied, Connection refused, Timeout, No such file or directory）。
- 控制节点：
  - 查看 /var/log/nova/nova-api.log 和 /var/log/cinder/cinder-api.log,了解Horizon发出的API请求是否被正确处理或有无错误。
  - 如果使用Cinder，查看 /var/log/cinder/cinder-volume.log 和 /var/log/cinder/cinder-scheduler.log，关注卷创建、调度、挂接操作的日志。
- 存储节点/设备： 检查存储服务器自身的日志（如NFS的/var/log/messages， Ceph的/var/log/ceph/ceph*.log）。
网络验证：
- 从物理机 (Compute Node) 执行：
  - ping <storage_server_ip> (验证基础连通性)
  - telnet <storage_server_ip> <port> 或 nc -zv <storage_server_ip> <port> (验证关键端口访问性，如NFS: 111, 2049; iSCSI: 3260; Ceph: 6789)
  - showmount -e <storage_server_ip> (针对NFS,查看导出的共享列表)
- 从控制节点执行 ping 和 telnet/nc 到物理机的管理IP,验证控制平面通信。
- 检查物理机、控制节点、存储设备上的防火墙规则。
权限验证：
- 登录到物理机 (Compute Node)。
- 切换到Nova-Compute服务运行的用户（通常是sudo su - nova -s /bin/bash 或 sudo su -s /bin/bash nova）。
- 尝试手动模拟挂载操作：
  - 对于NFS后端： mkdir -p /tmp/testmount; mount -t nfs <storage_server_ip>:</path/to/share> /tmp/testmount，观察错误信息，检查挂载点权限 (ls -ld /var/lib/nova/instances) 并确保nova用户可写。
  - 对于其他类型： 根据后端类型尝试相应命令（如iscsiadm），手动操作的成功与否能极大缩小问题范围（是OpenStack配置问题还是底层OS/存储访问问题）。
配置复查：
- 仔细核对物理机上的 /etc/nova/nova.conf：
  - [DEFAULT] 部分的 compute_driver
  - [libvirt] 部分的 virt_type, inject_* 设置 (视情况)
  - 确认用于存储的本地目录（如instances_path）存在且nova用户有rwx权限。
- 核对控制节点和Cinder Volume节点上的 /etc/cinder/cinder.conf (如果使用Cinder卷)：
  - [DEFAULT] 的 enabled_backends
  - 对应后端（如[nfs]）的所有配置项，特别是nfs_shares_config文件路径及其内容、nfs_mount_options、存储路径(volume_backend_name, volume_driver)。
  - 认证相关配置（如Ceph的rbd_user, rbd_secret_uuid）。
- 检查 /etc/cinder/nfs_shares (或配置文件中指定的路径) 内容是否正确，包含有效的NFS共享路径（如storage_ip:/share_path）,并且物理机能够访问这些路径。
服务重启 (谨慎操作)：
- 在修改配置或确认服务状态异常后，按需重启相关服务。注意： 重启Nova-Compute可能导致其管理的实例短暂中断；重启Cinder-Volume可能导致卷操作中断,建议在维护窗口操作。
- 物理机：sudo systemctl restart nova-compute
- 控制节点：sudo systemctl restart nova-api
- Cinder节点：sudo systemctl restart cinder-volume cinder-scheduler (如果分离) / sudo systemctl restart cinder-api (控制节点)
- Horizon (通常不需要单独重启，除非修改了Horizon配置)：sudo systemctl restart httpd 或 apache2

专家提示：

分而治之： 明确问题是出在“Horizon -> OpenStack API”链路上，还是“OpenStack服务 -> 物理机”链路上，或是“物理机 -> 存储设备”链路上,手动挂载测试是区分的关键。
关注权限： nova 用户对本地挂载点目录的权限，以及存储服务用户（cinder, nova）在远端存储设备上的权限,是高频故障点。
日志为王： 错误信息通常直接指向问题根源，养成第一时间、精准查看日志的习惯。
版本差异： OpenStack不同版本（如Queens, Rocky, Train, Victoria, Wallaby等）的配置项和默认行为可能有细微差别,参考对应版本的官方文档。
存储后端多样性： 本文以NFS为例，但原理适用于iSCSI、Ceph RBD、本地LVM等,排查时需结合具体后端的特性和要求。

解决“Horizon无法访问物理机共享”是一个系统性排查过程，需要结合网络诊断、服务状态检查、日志分析、配置验证和权限确认，核心思路是确保从OpenStack控制层（API）到计算节点（Nova-Compute），再到物理存储设备的整个路径畅通无阻，且所有相关服务和配置均正确无误，通过上述详细的排查步骤和方向，应能定位并解决绝大多数此类问题，如遇复杂情况,建议参考对应OpenStack版本的官方文档或寻求社区支持。

引用说明：