共享存储断开后 lvmlockd 泄漏 VG 共享锁导致云主机创建失败

适用场景

• 产品：ZCF
• 版本： 未指定
• 组件：ZStack Cloud
• 触发条件：使用 lvmlockd 的共享存储集群（典型于 ZStack 的共享块或 SAN-backed 主存储部署）。

问题现象

• 存储与物理主机之间的暂时性断连导致 lvmlockd 中留下了未释放的卷组（VG）共享锁（sh 锁）。
• 由于创建新卷需要获取卷组（VG）的排他锁（ex 锁），后续操作（如运行 vgs 或 lvchange）每次都会导致额外的共享锁（sh 锁）泄漏，
• 进而引发死锁，导致虚拟机创建请求失败。

判断方法

1. 在物理主机上执行 vgs；如果 VG 锁被挂起（或处于死锁状态），该命令会卡住。
2. 在物理主机上执行 vgs --no-locking。 如果命令立即返回结果，则证实瓶颈是由锁管理器（lvmlockd）引起的，而非底层存储硬件。
3. 执行 dmesg -T | grep -i error，以确认在虚拟机创建开始失败的前后时间段内，是否出现了重复的 I/O 错误信息。

问题根因

• 主机与存储之间发生的暂时性断连会导致 lvmlockd 中残留 VG sh 锁，且自动恢复进程无法将其清除。
• 硬件级故障（例如光模块/端口故障、光纤问题）会导致反复出现的 I/O 错误，从而引发持续的锁泄漏。
• 管理节点任务队列中陈旧或卡死的任务会保留过期的锁引用，从而阻塞后续的卷创建请求。

解决方案

1. 确认 VG 锁是瓶颈

• 在物理主机上执行：

  vgs

• 现象确认：若锁已卡住的预期表现：该命令挂起。
• 通过绕过锁来确认：

  vgs --no-locking

• 预期结果：vgs --no-locking 立即返回，确认阻塞来自锁管理器而非底层存储。

2. 确认存在近期存储断开

• 执行命令：

  dmesg -T | grep -i error

• 预期结果：验证存储链路中断是否引发了 sh 锁泄漏。

3. 在受影响计算节点上重启 sanlock 和 lvm2-lvmlockd

• 执行重启命令：

  systemctl restart sanlock
  systemctl restart lvm2-lvmlockd

• 检查残留锁：

  sanlock client status | grep VGLK

• 异常处理：若计算节点重启后该计数持续增长，则继续执行第 4 步。

4. 消除存储侧的 IO error

• 继续监控 dmesg -T | grep -i error。若 IO error 持续出现，锁泄漏也会再次发生。
• 操作：定位受影响的存储端口（典型怀疑对象为主机的 HBA / 光纤通道 / 光模块）并更换。

5. 在管理节点上重启 sanlock 和 lvm2-lvmlockd

• 在拥有该集群的管理节点上执行重启：

  systemctl restart sanlock
  systemctl restart lvm2-lvmlockd

6. 清除管理节点任务队列中卡住的任务

• 操作：检查 ZStack Cloud UI 的任务中心，查看是否存在长时间处于“运行中”或“等待中”状态的任务。如有必要，重启管理节点服务以重置队列。

7. 重试云主机创建

• 操作路径：在 ZStack Cloud Web UI 中重新触发虚拟机创建请求。

验证方法

1. 在存储主机上通过 lvs 确认 LV（Logical Volume）处于 active 状态。
2. 通过命令确认无残留锁：

   lvmlockd -L 2>&1 | grep lvm_

3. 检查 ZStack UI：重新发起创建后，任务在数分钟内完成，新创建的云主机显示为 Running 状态