DanieleF Asked: 2010-02-10 09:01:36 +0800 CST2010-02-10 09:01:36 +0800 CST 2010-02-10 09:01:36 +0800 CST 增量文件未删除 772 我发现我的虚拟机正在使用快照管理器中不可见的快照运行。我还发现机器正在一个 delta 文件上运行（可能是一个旧的快照） 我看到有合并快照的程序，但我现在想了解的是： 有一个 50gb 的 VMDK-flat 磁盘 => 这实际上是一开始创建的 vdisk 现在我有一个 38 GB 的 DELTA 文件……而且这个文件每天都在增长。 我的问题是：为什么增量文件正在增长？这正常吗？ virtual-machines vmware-vmdk 3 个回答 Voted Matt Simmons 2010-02-10T09:14:38+08:002010-02-10T09:14:38+08:00 我敢肯定，更多精通 VM 的人会在这里加入，但听起来 delta 文件正在做它应该做的事情。 据我所知，快照通过写时复制工作，您从原始图像（即您的虚拟磁盘）和一个空文件（即增量文件）开始。每次发生任何更改时，都会在增量磁盘上进行更改。原始磁盘不会被触及，这样如果您需要恢复到快照，增量文件将被丢弃，并且所有内容都从原始虚拟磁盘中读取。 随着时间的推移，这会导致增量文件随着事物的更改、添加和删除而大量增长。据我了解，如果添加一个 10MB 的文件，增量文件会增长 10MB。删除那个文件，它又增长了 10MB，因为有 10MB 的差异。我可能是错的，它实际上可能会缩小 10MB，但我不这么认为。（请有人纠正我）。 如果您将更改合并到快照中，您将恢复到原来的 50GB 磁盘映像。 当然，我可能大错特错，在这种情况下我会被否决，你应该听谁进来知道更多。 Phosdex 2010-02-13T12:31:39+08:002010-02-13T12:31:39+08:00 增量文件增长是正常的。Matt 所说的关于快照的工作原理是正确的。不正常的是快照没有显示在快照管理器中。我怀疑您也无法为该虚拟机拍摄任何新快照。这听起来像一个孤立的快照。 如果可以的话，您需要备份并关闭该虚拟机。 如果可以检测到快照，此KB可能会有所帮助。否则，我过去解决此问题的唯一方法是手动删除快照文件，重写 .vmx 文件并使 VM 处于崩溃状态，从而丢失快照中的所有更改。 如果 VM 不会关闭，您需要在主机上找到正确的进程并从服务控制台中 kill -9 它。 然后你需要重命名或删除所有 [guestname]-######-delta.vmdk, [guestname]-######.vmdk, [guestname]-Snapshot###.vmem.WRITELOCK 文件. 然后编辑 vmx 文件。查找行 scsi0:0.fileName。它应该将其中一个快照文件列为硬盘。将其更改为原始 vmdk 文件。当你启动虚拟机时，它会告诉你它已经崩溃了。您丢失了快照的内容，但至少您将恢复服务器。 这是一个苛刻的解决方案，但如果 ESX 说那里没有快照并且 VM 拒绝关闭，那么您无能为力。 Helvick 2010-02-13T15:33:56+08:002010-02-13T15:33:56+08:00 这种事情会变得非常混乱。Phosdex 和 Matt 几乎涵盖了最坏的情况。 我建议按照此VMware KB1002310故障排除文档中的说明进行操作，它涵盖了与 Phosdex 链接到的方法相同的方法，但它提供了一些有关如何确定您正在查看的快照是否实际上与您认为的 VM 相关联的提示他们是。有时他们不是，我已经看到当人们移动虚拟机以努力使用数据存储浏览器“整理”事情时发生这种情况。 如果仍然失败，您可以采取一些开箱即用的方法，并使用 VMware Converter 在 VM 上执行 P2V 迁移。即使它是一台虚拟机，如果您将其视为物理目标，Converter 也会从客户操作系统的上下文中提取当前状态，并且不会关心是否存在处于某些无法管理状态的可疑快照。然后它将VM的当前状态复制到一个干净的干净目标，留下快照混乱。一旦您运行了转换后的副本（尽管与生产网络隔离），您可以安全地以任何您喜欢的方式杀死原始副本并将副本连接到生产。一旦确定副本没问题，您就可以完全删除旧 VM。
我敢肯定，更多精通 VM 的人会在这里加入，但听起来 delta 文件正在做它应该做的事情。
据我所知，快照通过写时复制工作，您从原始图像（即您的虚拟磁盘）和一个空文件（即增量文件）开始。每次发生任何更改时，都会在增量磁盘上进行更改。原始磁盘不会被触及，这样如果您需要恢复到快照，增量文件将被丢弃，并且所有内容都从原始虚拟磁盘中读取。
随着时间的推移，这会导致增量文件随着事物的更改、添加和删除而大量增长。据我了解，如果添加一个 10MB 的文件，增量文件会增长 10MB。删除那个文件，它又增长了 10MB，因为有 10MB 的差异。我可能是错的，它实际上可能会缩小 10MB，但我不这么认为。（请有人纠正我）。
如果您将更改合并到快照中，您将恢复到原来的 50GB 磁盘映像。
当然，我可能大错特错，在这种情况下我会被否决，你应该听谁进来知道更多。
增量文件增长是正常的。Matt 所说的关于快照的工作原理是正确的。不正常的是快照没有显示在快照管理器中。我怀疑您也无法为该虚拟机拍摄任何新快照。这听起来像一个孤立的快照。
如果可以的话，您需要备份并关闭该虚拟机。
如果可以检测到快照，此KB可能会有所帮助。否则，我过去解决此问题的唯一方法是手动删除快照文件，重写 .vmx 文件并使 VM 处于崩溃状态，从而丢失快照中的所有更改。
如果 VM 不会关闭，您需要在主机上找到正确的进程并从服务控制台中 kill -9 它。
然后你需要重命名或删除所有 [guestname]-######-delta.vmdk, [guestname]-######.vmdk, [guestname]-Snapshot###.vmem.WRITELOCK 文件. 然后编辑 vmx 文件。查找行 scsi0:0.fileName。它应该将其中一个快照文件列为硬盘。将其更改为原始 vmdk 文件。当你启动虚拟机时，它会告诉你它已经崩溃了。您丢失了快照的内容，但至少您将恢复服务器。
这是一个苛刻的解决方案，但如果 ESX 说那里没有快照并且 VM 拒绝关闭，那么您无能为力。
这种事情会变得非常混乱。Phosdex 和 Matt 几乎涵盖了最坏的情况。
我建议按照此VMware KB1002310故障排除文档中的说明进行操作，它涵盖了与 Phosdex 链接到的方法相同的方法，但它提供了一些有关如何确定您正在查看的快照是否实际上与您认为的 VM 相关联的提示他们是。有时他们不是，我已经看到当人们移动虚拟机以努力使用数据存储浏览器“整理”事情时发生这种情况。
如果仍然失败，您可以采取一些开箱即用的方法，并使用 VMware Converter 在 VM 上执行 P2V 迁移。即使它是一台虚拟机，如果您将其视为物理目标，Converter 也会从客户操作系统的上下文中提取当前状态，并且不会关心是否存在处于某些无法管理状态的可疑快照。然后它将VM的当前状态复制到一个干净的干净目标，留下快照混乱。一旦您运行了转换后的副本（尽管与生产网络隔离），您可以安全地以任何您喜欢的方式杀死原始副本并将副本连接到生产。一旦确定副本没问题，您就可以完全删除旧 VM。