我有一些最初使用精简configuration磁盘创build的ESXi（4.1）虚拟机，但是物理迁移到不同的数据存储（全部是iSCSI）; 由于这些是独立主机，因此不存在可用于pipe理它们的vCenter Server，因此使用mv命令从ESXi命令行执行操作。
现在，虚拟机显示出一个相当有趣的行为：VM设置中的磁盘格式显示为“厚”，VMDK文件没有 ddb.thinProvisioned = "1"行，但实际文件大小远小于虚拟磁盘大小。 通过数据存储浏览器进行检查时，它会显示“大小”和“预置大小”两个不同的列，就像使用精简configuration的磁盘一样。
不过，这似乎不成问题，因为机器工作正常。
然后，另一份作为备份目的; 这个副本也是在命令行中使用cp命令在同一主机上的两个数据存储之间创build的（同样，这两个数据存储都是iSCSI）。
然后，我们失去了原来的虚拟机，并需要备份的虚拟机。
而这些不再工作，抱怨VMDK文件的腐败。
所以，回顾一下：
我尝试手动编辑VMDK文件来添加ddb.thinProvisioned = "1"行，但这并没有解决问题。 我试图膨胀虚拟磁盘，克隆和转换它：没有任何工作，每个命令抱怨磁盘被损坏。
我很难再把这些虚拟机装上去， 有人可以帮忙吗？
看起来像物理复制精简configuration的磁盘是一个坏主意 。 VMFS使用精简configuration的磁盘做了一些奇怪的事情，这是cp或mv无法应对的。 腐败随之而来。
不要这样做。 vmkfstools处理他们好得多（和更安全）。
我怀疑你的存储是一个VMFS数据存储，而不是NFS？
您可以尝试在安全的地方下载/复制有问题的vmdk，然后使用vmware-vdiskmanager或vmware-mount（VMWare Server / Workstation的一部分）或者作为独立下载IIRC提供。
如果全部失败，请尝试使用第三方工具 – QEMU软件包中的qemu-img或VirtualBox中的VBoxManage clonehd等工具可以将vmdks转换为原始文件 ，然后您可以简单地将其恢复到ESX guest 虚拟机 。
还有一个名为“vdk”的Windows 备用磁盘驱动器 （原始作者的页面看起来不太好，但有旧版本的下载和一个64位版本 ），据说它能够很好地读取部分损坏的vmdk文件 – 虽然我还不得不尝试一下。
至于可能的腐败原因，我猜测“cp”命令不是罪魁祸首。 有很多方法来破坏数据 – 使用不支持/实现SCSI保留的 iSCSI目标是其中之一。 无论如何，我认为最好的logging方式是使用vmkfstools – 你应该坚持这一点。