VMware寻找消失的Datastore与VM数据

【真实案例，信息脱敏】
客户现场服务器出现异常，VM会无规律的假死需要重启服务器才可以解决。起初是怀疑VMware存在Bug引起，客户平台是VMware ESXi, 6.5.0, 10175896。

2019年7月初，VMware推出6.5 Update 3版本想着朝此方向修复。不过，从客户现场反馈情况，问题越发严重基本上瘫痪状态。我通过远程查看硬件信息，发现Slot4硬盘出现许多Media Error，热备盘处于Copyback状态，而不是Rebuilding状态。

至此判断问题与VMware关系不大，首先解决硬件故障的。硬件更换遇到的故事不是重点忽略，简单记录是Raid卡更换、Slot4磁盘更换问题解决。

重头戏开始，硬件更换完毕可以正常开启VMware虚拟化界面，不过…

数据存储是空的，31台虚拟机全部无法启动…如果要我重建这些VM，我相信会脱很惨的…

针对此问题，我迅速给VMware发出SR要求工程师介入，不过工程师只是要求收集日志，然后就没有然后的…

我通过日志观察到如下的日志信息：
2019-07-24T07:23:01.140Z cpu39:73200)LVM: 11158: Device naa.6003005701ee29e0ff00002b02a7b1ac:3 detected to be a snapshot:
2019-07-24T07:23:01.140Z cpu39:73200)LVM: 11165: queried disk ID:
2019-07-24T07:23:01.140Z cpu39:73200)LVM: 11172: on-disk disk ID:
2019-07-24T07:23:01.142Z cpu32:66519)ScsiDeviceIO: 2954: Cmd(0x439d05d23ec0) 0x1a, CmdSN 0xc0f from world 0 to dev “naa.6003005701ee29e0ff00002b02a7b1ac” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.
2019-07-24T07:23:01.325Z cpu24:73205)FSS: 5764: No FS driver claimed device ‘mpx.vmhba0:C0:T0:L0’: No filesystem on the device
2019-07-24T07:23:01.325Z cpu39:73200)VC: 4511: Device rescan time 111 msec (total number of devices 5)
2019-07-24T07:23:01.325Z cpu39:73200)VC: 4514: Filesystem probe time 183 msec (devices probed 4 of 5)
2019-07-24T07:23:01.325Z cpu39:73200)VC: 4516: Refresh open volume time 0 msec

没有办法，自己动手检查尝试死马当活马医，最终通过如下方法解决问题。

[root@vsphere02:~] partedUtil getptbl /vmfs/devices/disks/naa.6003005701ee29e0ff00002b02a7b1ac
gpt
546867 255 63 8785428480
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 8785428446 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
[root@vsphere02:~] df -h
Filesystem Size Used Available Use% Mounted on
vfat 249.7M 206.7M 43.1M 83% /vmfs/volumes/ccc23a73-6a9f97a1-d924-075b1fcc4203
vfat 249.7M 8.0K 249.7M 0% /vmfs/volumes/83cddc7d-79404364-4f5c-0578c75b601a
vfat 4.0G 33.4M 4.0G 1% /vmfs/volumes/5c6d4e9f-dc539db4-01a1-4c5262168013
vfat 285.8M 209.1M 76.8M 73% /vmfs/volumes/5c6d4e80-e57c8bde-369b-4c5262168013
[root@vsphere02:~] esxcfg-volume -l
Scanning for VMFS-3/VMFS-5 host activity (512 bytes/HB, 2048 HBs).
VMFS UUID/label: 5c6d4e9c-7bf9c11a-6f43-4c5262168013/vSphere02-Datastore01
Can mount: Yes
Can resignature: Yes
Extent name: naa.6003005701ee29e0ff00002b02a7b1ac:3 range: 0 - 4282111 (MB)
[root@vsphere02:~] esxcli storage vmfs snapshot list
5c6d4e9c-7bf9c11a-6f43-4c5262168013
Volume Name: vSphere02-Datastore01
VMFS UUID: 5c6d4e9c-7bf9c11a-6f43-4c5262168013
Can mount: true
Reason for un-mountability:
Can resignature: true
Reason for non-resignaturability:
Unresolved Extent Count: 1
[root@vsphere02:~] esxcli storage vmfs snapshot mount -u 5c6d4e9c-7bf9c11a-6f43-4c5262168013

问题至此，服务器重启各种问题都迎刃而解，虚拟机全部都可以正常运用的。VMware工程师致电回来时，我告诉他问题已经解决，请关闭Case并指导他此问题的解决方法。

[2019年7月31日 VMware邮件反馈]
如果 ESXi/ESX 主机不通过预期会在 VMFS 元数据中看到的内容来确认 LUN 身份，将出现快照 LUN 问题。
更换 SAN 硬件、固件升级、SAN 复制、DR 测试和一些 HBA 固件升级后会出现此问题。

参考链接：
https://kb.vmware.com/s/article/1011387?lang=zh_CN