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

vSphere上的Windows 2008 R2 VM的控制台视图显示以下屏幕:

程序的屏幕抓图

“2操作2”“擦盘”

有人可以build议这个程序是什么?

关于这个谜的一些信息:

现在有一些虚拟机受到影响。 症状是重新启动后出现“操作系统找不到”消息。

  • VM正在ESXi上运行。 虚拟机正在特定的数据存储上运行
  • Netapp NFS在一个工作箱中挂载磁盘显示没有分区表,还不能hex转储。
  • 虚拟机不是硬重置,将不得不是一个操作系统启动软重置
  • 有没有iso安装没有“非客户”访问虚拟机,所以需要是RDP或类似的
  • 备份是通过netapp备份软件过夜进行的
  • 所讨论的NFS在后端(数组级别)上进行了精简configuration,在我们看到这些问题之后就耗尽了空间。

不幸的是,看起来我们可能没有深入到应用程序的底部,但为了从这个事件中获得一些价值,我想创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。

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