问题描述

使用vSphere Client冷迁移失败，没有显示具体原因。虚拟机启动之后，在虚拟机中收到磁盘错误。猜测是磁盘损坏导致的。

使用ssh命令登录到ESXi中，尝试对.vmdk文件复制，当复制到2/3时（虚拟机迁移也是大约在这时），产生I/O错误。因此更加怀疑存在坏区。

问题排查

目前的情况是这样的：

	（1）由于ESXi中没有badblock命令。
	（2）虽然由smartd服务，但是我对smart并不是非常熟悉。
	（3）另外，也不知道ESXi有没有提供相关的坏块检测功能。

在条件允许的情况下，我们决定脱机处理（从安装到USB的Debian启动，在非ESXi系统中维护）。

初始化环境

从USB启动，进入Linux系统，执行apt-get install vmfs-tools命令。（详细步骤略过）

确定磁盘存在坏块

将U盘插入物理机，启动U盘中的Linux系统，对磁盘运行badblocks(1)命令：

#!/bin/sh

badblocks -v /dev/sda > /mnt/sda-bad-blocks.txt

然后，非常顺利的检测到四个坏块（使用smartmontools检测也显示存在坏块）。坏块被记录在/mnt/sda-bad-blocks.txt文件中。

既然磁盘存在坏块，那如何确定坏块影响了哪些文件呢？

确定坏块值

#!/bin/sh

# 获取文件系统块大小
debugvmfs /dev/sdb1 show # 输出中Block Size为1M大小

badblocks -b 1048576 -v /dev/sdb1 > /mnt/sda-bad-blocks.txt # 进入只读测试，并将坏块结果写入文件。

在运行结束之后，我们检测到一个坏块，621317。这与「检测到四个坏块」并不冲突，因为块大小不同（前者默认1024字节，后者指定1048576字节）。

受坏块影响的文件（未完成）

接下来就是确定受该坏块影响的文件。

底层技术向来复杂……事情是这样的，坏块检测是文件系统无关的，而文件定位是文件系统相关的。所以，不同文件系统要使用不同处理工具（例如，在ext2/ext3/ext4中使用debugfs命令），而ESXi使用VMFS系统，需要使用vmfs-tools中的debugvmfs命令，但是该命令版本过旧，而且手册描述与实际功能不符合。所以，指望不上debugvmfs命令。

而在ESXi中，内置debugfs工具，该工具可以用于调试文件系统，但是我不会用，也没有找到相关手册。

TODO 关于VMFS文件系统的调试方法

数据救援

如果文件损坏，单纯进行cp命令并不能成功，可能会返回I/O错误。可以尝试使用一些工具进行恢复：

#!/bin/sh

# 使用ddrescue命令
# 但是这需要从Linux启动，然后访问存储
ddrescue --direct --retrim --max-retries=3 /dev/hda1 imagefile logfile

在Windows下，可以使用「HDD Raw Copy Tool」工具。

！！！不建议使用dd if=fileWithBadBlocks of=recoveredFile bs=4k conv=noerror,sync命令。因为使用noerror选项后，在读取失败时，会用NUL进行填充。

相关文章

「VMware ESXi」- 虚拟机版本与主机“x.x.x.x”的版本不兼容

参考文献

List bad blocks and affected files
vmware.com/message/2657155#2657155" rel="noopener" style="margin: 0px; padding: 0px; color: rgb(0, 102, 204); background: none;">Solved: Disk with bad sectors -- how to get data out?
How can I find out which files are lost through a ddrescue recovery atempt?
Recovering a file with bad blocks in the middle