📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/7ujntwxN91j0cPrs1z4Gcw
【闫工的工具箱 · 第 14 弹｜实战】 #
我是闫工，数据中心搬砖的 CCIE。
今天讲个"心跳骤停"的场景：系统盘被格式化重装，重启后原数据盘上的虚拟机全部消失。
先翻译下标题里的词：ESXi 是服务器上跑的虚拟机管理系统，VMFS 是它存虚拟机文件（.vmx 配置、.vmdk 磁盘）的格式。不懂这些没关系，记住一个前提就够——
先说结论压压惊：只要一个前提成立——数据盘在重装过程中没被触碰——那里面存的虚拟机文件都还完好。三步就能把全部虚拟机救回来。
— — —
1. 为什么数据盘"看起来"丢了？ #
VMFS（Virtual Machine File System）是 ESXi 的集群文件系统，元数据写在磁盘分区头部。系统盘重装不会碰独立的数据盘，但有两个原因让 ESXi 重启后"认不出"原卷：
- 签名不一致：重装后 ESXi 把原 VMFS 卷当成"另一台机器留下的副本"，标记为 snapshot 卷（快照卷），不会自动挂载；
- 挂载状态变化：卷的签名和当前已知签名对不上，ESXi 干脆不挂。
数据没丢，只是没挂上来。
第一铁律：严禁对 NVMe 数据盘执行"新建 datastore / 格式化 / 写入数据"。VMFS 元数据一旦被覆盖，数据就真没了。只要 .vmdk 还在，就还有救。
2. 三步恢复：挂载 → 注册 → 开机 #
第一步：重装 ESXi（版本不能低于原版） #
用与原版本相同或更高的 ESXi 安装介质，重装到系统盘（只选系统盘！）。装完进入 Host Client。
版本过低可能无法识别原 VMFS 格式，这条踩过坑。
第二步：确认 NVMe 盘状态 #
# 列出存储设备，确认能看到原 NVMe 设备
esxcli storage core device list
# 查看文件系统，看是否自动识别出 VMFS 数据存储
esxcli storage filesystem list情况 1（自动识别）：/vmfs/volumes/datastore1 已经在列表里，直接进第三步。
情况 2（设备在，但卷没挂）：查快照卷：
esxcli storage vmfs snapshot list如下：
Volume Name: datastore1
VMFS UUID: 5f8b4b22-1234abcd-...
Can mount: true
Reason for un-mount: Detected previously mounted VMFS volumeCan mount: true，可以挂。执行：
# 按卷名挂载（持久化，重启后保留）
esxcli storage vmfs snapshot mount -l datastore1
# 或按 VMFS UUID 挂载
esxcli storage vmfs snapshot mount -u 5f8b4b22-1234abcd...
# 确认挂载路径存在
esxcli storage filesystem list或者用 Host Client 走图形界面挂载（适合不熟命令行的同学）：
图：当看到原本那块 447 GB 的 SSD 再次出现在设备列表里时，心里那块石头才算落了地——这说明数据盘完好，VMFS 分区结构还在。
第三步：重新注册虚拟机 #
- vSphere Host Client → 存储 → 进入 datastore1；
- 找到虚拟机目录 vmname/；
- 右键 .vmx 文件 → 注册虚拟机（Register VM）；
- 虚拟机会重新出现在清单里，开机验证。
若 .vmx 文件缺失：新建虚拟机，选"使用现有磁盘"，指向原 .vmdk 也能恢复。注册完选存储时就能看到原 datastore1 挂回来了：
图：新建虚拟机选存储时，datastore1 稳稳显示 318.5 GB 可用（VMFS6）——那一刻才真正确认：盘里的虚拟机文件一个没少，全都能用。
3. 进阶修复：卷挂不上怎么办？ #
⚠️ 高级操作警告：以下几步涉及命令行直接操作 VMFS 分区表与强制挂载，有一定风险，仅建议有一定命令行经验的运维同学尝试。如果你不确定，或者数据极其重要，优先使用第三方只读恢复工具（UFS Explorer / R-Studio Technician）在另一台主机上分析，或联系原厂 / 专业数据恢复支持——宁可慢一步，别把元数据写坏。
如果 snapshot mount 失败，一步步排查：
# ① 重新扫描所有存储适配器
esxcli storage core adapter rescan --all
# ② 查看分区表，确认 VMFS 分区还在（GPT 类型标识 AA31E02A...）
partedUtil getptbl /vmfs/devices/disks/naa.55cd2e404c123456
# ③ 强制挂载指定 VMFS 分区到自定义名称（:1 通常是分区号）
vmkfstools -M /vmfs/devices/disks/naa.55cd2e404c123456:1 /vmfs/volumes/MyVMFS
# ④ 重新扫描 VMFS
vmkfstools -V如果分区表也坏了，数据极其重要时，用第三方 VMFS 恢复工具（UFS Explorer / R-Studio Technician）在另一台 Linux/Windows 主机上只读分析 NVMe 盘并导出 .vmdk。
决策建议：snapshot mount 失败时怎么选？ #
| 你的状态 | 建议动作 | 理由 |
|---|---|---|
能看到 snapshot 卷，且 Can mount: true |
直接 snapshot mount，别犹豫 |
最安全，元数据零写入风险 |
卷挂不上，但 partedUtil getptbl 能看到 VMFS 分区 |
谨慎执行 vmkfstools -M 强制挂载，只此一次 |
分区表还在就有救，强制挂载比 resignature 侵入更小 |
分区表损坏 / getptbl 报错 / 强制挂载仍失败 |
立刻停手 ，转第三方只读工具或原厂支持 | 再写入只会覆盖元数据，数据真没了 |
| 数据极其重要、心里没底 | 先做只读镜像，再决定下一步 | 镜像在手，怎么试都不慌 |
一句话总结：能挂就挂，挂不上先看分区表，分区表坏了就别硬来——交给工具和原厂。
4. 恢复避坑清单 #
| 现象 | 可能原因 | 处理 |
|---|---|---|
| filesystem list 无输出 | VMFS 分区丢失/损坏 | partedUtil getptbl 确认；vmkfstools -V 扫描；必要时只读镜像 + 第三方工具 |
| snapshot list 为空 | 设备未识别 | esxcli storage core adapter rescan –all；检查 NVMe 盘是否在线 |
| 挂载报 “already mounted” | 卷已被挂载 | 直接用 esxcli storage filesystem list 看现有挂载路径 |
| 注册后虚拟机无法开机 | .vmdk 指向路径变化 | 编辑虚拟机设置，重新指向正确的现有磁盘文件 |
5. 安全红线（每条都是血泪教训） #
- 只读优先：操作前尽量对 NVMe 盘做只读镜像/备份，任何写入都可能破坏元数据；
- 禁止格式化数据盘：绝不在此盘上"新建 datastore"或写入测试数据；
- 版本一致性：重装 ESXi 版本不低于原版本，避免 VMFS 格式不兼容；
- 最小侵入：优先 snapshot mount 而非 resignature，保留原 UUID 便于回退；
- 记录在案：记下设备 naa ID、VMFS UUID、datastore 名称，便于追溯。
📖 推荐阅读
灯亮、端口Up、Ping通，但RDMA就是起不来：理线师傅的4根线全插错了