「VMware ESXi」- 虚拟机冷迁移失败(虚拟磁盘文件位于坏扇区上) @20210315

问题描述

使用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
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

上一篇:20210315 GBDT 梯度下降树


下一篇:npm install 安装依赖的时候卡主不动