一个未知的工具是擦我们的虚拟机，我们不能识别它

不幸的是，看起来我们可能没有深入到应用程序的底部，但为了从这个事件中获得一些价值，我想创build一个参考答案。 这是VMware和虚拟层pipe理中心。 许多pipe理员都是隔离的，无法快速获取访客或存储访问权限，这是他们:)

http://support.seagate.com/kbimg/flash/laptop/Laptop.swf似乎是与@MosheKatz发现的实际应用程序最接近的匹配。

如果将来发生这种情况，调查应如下所示：

• 你注意到一些但不是所有的虚拟机都崩溃了。 您怀疑这是由于存储问题（通常是最可能的原因）
• 首先尝试隔离一个共同的因素。 所有的崩溃的虚拟机共享相同的数据存储？ 在这种情况下，他们是，但有些机器是好的，所以我们排除了明显的硬件问题。
• 检查所有的虚拟机，看看是否有一个共同的因素（时间，function等）。 在这种情况下，没有。

• 检查其他exception事件。 有什么东西在这里扬起了旗帜：

• • NFS存储是精简的（在数组级别上）。 这意味着虽然例如。 200GB提供给ESXi主机，实际上只有100GB可用。 但只有arrays有这个知识。 我们发现有一些虚拟机因磁盘空间不足而暂停。 我们虽然这可能是根本原因，所以我们的拳头行动是在后端分配更多的存储空间，以消除这个问题。

• 一旦解决了这个问题（一个简单的用户界面变更），暂停的虚拟机重新启动成功，我们回到原来的问题。 我们将虚拟磁盘从虚拟的虚拟机中挂载到工作的虚拟机上，并看到磁盘上没有分区表。 我们没有可用的hex查看器，所以不得不假设磁盘现在是空的。

• 监控系统提醒一个刚刚没有响应的新VM。 这真是太好了，因为由于磁盘空间问题，虚拟机的负载已经过了几分钟才刚刚变为不响应，所以这个新虚拟机很快被发现是一个很好的监控pipe理的标志。

• 我们打开了一个控制台，检查了客人，看到上面的屏幕抓取。

• • 在这个阶段，我去了服务器故障聊天室，看是否可以识别程序，而我的存储同事检查了所有的虚拟层日志和事件，以确保没有从我们的地区运行存储操作。
• 我们应该做的是挂起虚拟机，允许挂起文件写出来，并分析转储，看看是否可以识别正在运行的程序。 将VM挂起为核心PDF VMware KB

在这一天结束的时候，我们知道虚拟基础架构工具不会像上面这样在客户中进行报告。 我们可以看到没有安装ISO，也没有针对VMlogging事件。 我们可以看到虚拟机并不是“硬件重启”的，只是软重启（这对底层基础架构是不可见的）。 我们知道这不是存储方面，因为我们已经排除了。 我们怀疑它是不是自动化的，因为它在特定的虚拟机上发生了几个小时的过程。 我们猜测这是不是恶意的，为什么控制台会报告磁盘擦除，如果是的话:)

所以，结论是用户启动的磁盘擦除。 就我的调查结果而言，但我希望你觉得它有用。

得到教训：

• 备份和testing您的恢复
• 确保所有用户，特殊性pipe理员用户知道他们正在精简configuration环境中工作，并且应该避免像写出磁盘格式化（即写入1的写入
• 有一个好的监测系统。
• 对我来说是一个新的工具：在任何大型的虚拟环境中，安装一个工具虚拟机，甚至closures电源，安装诊断工具。 性能，networking存储。 如果这是可用的，我们可以挂载并执行损坏的磁盘上的hex转储，以查看它是否真的是空的，或只是缺less一个MBR。 我们也可以看到它是否写出1。

我认为你的问题是一个标准的VMware空间回收function。

本文可能会帮助您： 清理节省空间的虚拟磁盘问题