我发现我的虚拟机正在快照pipe理器中看不到的快照。 我也发现机器运行在一个增量文件（可能是一个旧的快照）
我看到有程序来整合快照，但我现在想要了解的是：
拥有一个50GB的VMDK平面磁盘=>这实际上是在开始时创build的虚拟磁盘
现在我有一个38 GB的DELTA文件…这个文件每天都在增长。
我的问题是：为什么delta文件正在增长？ 这是正常的吗？
我相信有更多的VM精明的人会在这里发出响声，但听起来好像delta文件正在做它应该做的。
据我所知，快照是通过copy-on-write工作的 ，从原始映像（这是您的虚拟磁盘）和一个空文件（即增量文件）开始。 每当有任何改变时，改变是在增量磁盘上进行的。 原始磁盘没有被触及，这样，如果您需要恢复到快照，增量文件将被丢弃，所有内容都将从原始虚拟磁盘中读取。
随着时间的推移，这会导致delta文件的副作用随着事物的改变，添加和删除而大量增长。 据我了解，如果你添加一个10MB的文件，增量文件增长10MB。 删除那个文件，它增长了10MB，因为有10MB的差异。 我可能是错的，实际上可能缩小10MB，但我不这么认为。 （请有人纠正我）。
如果您将更改整合到快照中，您将自行回到原始的50GB磁盘映像。
当然，我可能是错的，错了，在这种情况下，我会被拒绝，你应该听谁进来，知道更多。
增量文件增长是正常的。 马特所说的快照是如何工作是正确的。 快照pipe理器中没有显示快照，这是不正常的。 我怀疑你不能采取任何新的虚拟机快照。 这听起来像一个孤儿快照。
如果可以，您需要备份然后closures虚拟机。
如果可以检测到快照，则此KB可能会有所帮助。 否则，我过去解决这个问题的唯一方法是手动删除快照文件，重写.vmx文件并使虚拟机处于崩溃状态，从而丢失快照中的所有更改。
如果虚拟机不能closures，你需要在主机上find正确的进程并从服务控制台中取消它。
然后，您需要重命名或删除所有[guestname] – ###### – delta.vmdk，[guestname] – ######。vmdk，[guestname] -Snapshot ###。vmem.WRITELOCK文件。 然后编辑vmx文件。 查找行scsi0：0.fileName。 它应该列出其中一个快照文件作为硬盘。 将其更改为原始vmdk文件。 当你启动虚拟机时，它会告诉你它已经崩溃了。 你失去了快照的内容，但至less你会让服务器回来。
这是一个苛刻的解决scheme，但是如果ESX说没有快照并且VM拒绝closures，那么你可以做的不是很多。
这样的事情可能会变得非常混乱。 Phosdex和Matt几乎涵盖了最坏的情况。
我build议按照这个VMware KB1002310故障排除文档中的说明进行操作，它涵盖了与链接到一个Phosdex相同的方法，但它提供了一些关于如何确定您正在查看的快照是否与您认为的虚拟机相关的更多提示他们是。 有时候他们并不是，我发现当人们移动虚拟机时，会发生这种情况，以便使用数据存储浏览器来“整理”事物。
如果仍然失败，您可以采取一些开箱即用的方法，并使用VMware Converter在VM上执行P2V迁移。 即使它是一个虚拟机，如果你把它当作一个物理目标，Converter会从Guest OS的上下文中提取当前状态，并且不会在意某些不可pipe理的状态下存在不可靠的快照。 然后，它会将虚拟机的当前状态复制到一个干净的目标上，从而将快照弄乱。 一旦转换后的副本运行（尽pipe与生产networking隔离），您可以按照自己喜欢的方式安全地杀死原始副本，并将副本连接到生产环境。 一旦你确定副本是确定的，你可以完全删除旧的虚拟机。