这应该是一个美好的周一早晨，我正在试图和食堂阿姨划价——这半根的油条就憋收我钱了。
万万万没想到在手机响了好多声之后，一个人从背后啪啪啪拍起了我的肩膀。
“不好啦，不好啦~杂工哥运营的那个大姐打上门来了”
“卧槽”我在震惊中，被实习生拉着跑回了楼上。
Proxmox VE上测试集群集体崩溃了
和服务器一块崩的还有我们的运营小姐姐以及被她怒喷的我们小老板，以及及一个客户。
大哥（客户）是真能省钱啊，为了省钱卖给他客户的是我们提供给他的体验系统。现在出问题了，客户骂客户，客户骂客服，客服她们部门（运营）裤裤的哭。
我%&（）%……￥*&……%，没办法抓紧修
周一的问题当天上午已解决，周二写的文章忘记发了。。。
当然，我
屏蔽的飞书，卸载的钉钉，登录状态失效的邮箱，拒接的告警电话这些我是没有提的~
问题描述
我们的 Proxmox VE 测试集群由多台服务器组成，出问题是是一台dell r730服务器。这台机器也是我们的老演员老朋友了，大概是我大学毕业那年的产品如今已十岁有余。
在pve的管理界面上只能看到这台机器挂载的一块硬盘处于unknown状态别的都是正常的。这块硬盘是卷组 STAT-4 的一部分，而该卷组下的所有逻辑卷（LV）都处于 inactive 状态，导致挂载这些逻辑卷的虚拟机无法启动。
问题分析
好在今天的网络是没问题的（前几天刚迁移的机房，因为网络出了两次洋相有时间写写）在问题发生后第一时间登上了服务器。
硬盘数量检查
从 lsblk 命令的输出中可以看到，系统中有以下几块硬盘：
- sda：大小为 931.5G
- sdb：大小为 744.6G
- sdc：大小为 3.6T
- sr0：大小为 1024M（这是一个光驱设备）
所以，总共有 3 块物理硬盘（sda、sdb 和 sdc）以及 1 个光驱设备（sr0）。这里没有发现问题
lzsb@r730:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
# 更多-----------
sdc 8:32 0 3.6T 0 disk
|-STAT--4-STAT--4_tmeta 252:4 0 15.9G 0 lvm
`-STAT--4-STAT--4_tdata 252:5 0 3.6T 0 lvm
sr0 11:0 1 1024M 0 rom
一系列巴拉巴拉检查
# 检查硬盘健康状态
smartctl -a /dev/sdc
# 检查硬盘分区
lsblk /dev/sdc
fdisk -l /dev/sdc
# 检查文件系统
umount /dev/sdc1 # 确保分区未挂载
fsck /dev/sdc1
# 检查 LVM 配置
pvs
vgs
lvs
# 查看系统日志
dmesg | grep sdc
journalctl -xe | grep sdc
# 检查 Proxmox 配置
cat /etc/pve/storage.cfg
问题找到了。LVM（逻辑卷管理）不正常了，确切的说是 LVM 元数据的损坏或不一致了。为了省点钱这块八手硬盘真是亏死了！
问题修复
LVM（逻辑卷管理）
# 检查卷组和逻辑卷状态
vgdisplay STAT-4
lvdisplay STAT-4
# 检查 LVM 元数据状态
vgscan
lvscan
问题果然在这儿
root@r730:~# vgscan
lvscan
Found volume group "STAT-4" using metadata type lvm2
Found volume group "pve" using metadata type lvm2
inactive '/dev/STAT-4/STAT-4' [<3.61 TiB] inherit
inactive '/dev/STAT-4/vm-100-disk-0' [100.00 GiB] inherit
# 更多数据，点击展开
ACTIVE '/dev/pve/vm-103-disk-0' [50.00 GiB] inherit
发现卷组 STAT-4 处于非活动状态，而该卷组下的 Thin Pool 元数据卷 STAT-4_tmeta 活动异常。Thin Pool 是 LVM 的一种逻辑卷类型，允许在同一个卷组中动态分配和管理存储空间。
注释：Thin Pool 是一种高级的 LVM 特性，允许用户创建多个逻辑卷而无需预先分配所有的物理存储空间。它通过元数据卷（
tmeta）和数据卷（tdata）来管理存储空间的分配和使用。
问题解决步骤
-
停用 Thin Pool 数据卷
首先，停用 Thin Pool 数据卷
STAT-4_tdata：lvchange -an STAT-4/STAT-4_tdata -
修复 Thin Pool 元数据
接下来，尝试修复 Thin Pool 元数据卷：
lvconvert --repair STAT-4/STAT-4_tdata注释：
lvconvert --repair命令用于修复 LVM Thin Pool 的元数据卷。这个命令会尝试修复元数据中的错误，使卷组恢复正常状态。 -
再次激活卷组
修复完成后，我们尝试再次激活卷组
STAT-4：vgchange -ay STAT-4经过上述步骤，卷组成功激活，所有逻辑卷恢复正常状态，挂载这些逻辑卷的虚拟机也能够正常启动。
详细操作记录
# 显示所有块设备信息
lsblk
# 显示物理卷信息
pvs
# 显示卷组信息
vgs
# 显示逻辑卷信息
lvs
# 检查硬盘健康状态
smartctl -a /dev/sdc
# 检查硬盘分区
lsblk /dev/sdc # 显示 /dev/sdc 的分区信息
fdisk -l /dev/sdc # 列出 /dev/sdc 的分区表
# 检查文件系统
umount /dev/sdc1 # 确保分区未挂载
fsck /dev/sdc1 # 检查并修复 /dev/sdc1 文件系统
# 检查 LVM 配置
pvs # 显示物理卷信息
vgs # 显示卷组信息
lvs # 显示逻辑卷信息
# 查看系统日志
dmesg | grep sdc # 查看与 sdc 相关的内核消息
journalctl -xe | grep sdc # 查看与 sdc 相关的系统日志
# 检查 Proxmox 配置
cat /etc/pve/storage.cfg # 查看 Proxmox 存储配置
# 检查卷组和逻辑卷状态
vgdisplay STAT-4 # 显示卷组 STAT-4 的详细信息
lvdisplay STAT-4 # 显示卷组 STAT-4 中逻辑卷的详细信息
# 检查 LVM 元数据状态
vgscan # 扫描所有可用的卷组
lvscan # 扫描所有可用的逻辑卷
# 停用 Thin Pool 数据卷
lvchange -an STAT-4/STAT-4_tdata # 停用卷组 STAT-4 中的 Thin Pool 数据卷
# 修复 Thin Pool 元数据
lvconvert --repair STAT-4/STAT-4_tdata # 修复卷组 STAT-4 中的 Thin Pool 数据卷
# 再次激活卷组
vgchange -ay STAT-4 # 激活卷组 STAT-4
问题溯源
这下问题来了，会出现这个问题？请看大屏幕~
周六早上大厦施工把电给断了，UPS撑了三个小时然后完全断电。再次开机时，我那八手硬盘：啊？胆敢断电这么长时间，我噶了！！！
最终，没有能定位到一个具体的原因。但是我觉得可能是如下原因：
- PVE自动执行了断电前未执行完成的关机命令导致的状态异常
- 突然断电可能导致 LVM 元数据不一致，导致卷无法正常激活。
- 批量操作（如批量关闭和启动虚拟机）可能导致系统状态不一致，从而引发激活错误。
- NFS 服务器未及时启动，依赖它的虚拟机可能会在尝试挂载 NFS 共享时失败导致的
各位元芳，你怎么看
总结
通过以上步骤，我们成功解决了 Proxmox VE 测试集群中因老旧硬盘断电导致的 LVM 元数据不一致问题，恢复了虚拟机的正常启动。这个案例提醒我们，硬盘状态异常可能会导致卷组和逻辑卷无法正常工作，进而影响虚拟机的启动。通过合理的分析和修复步骤，我们能够有效解决这个问题，确保测试集群的正常运行。
希望这篇文章能为遇到类似问题的管理员提供一些有价值的参考。如果在操作过程中遇到其他问题，建议参考 LVM 的官方文档或寻求专业技术支持。
