“2的操作2”
“擦盘”
有人可以就这个项目是什么提出建议吗？
关于这个谜团的一些信息：
现在有许多VM受影响.症状是在重新启动“OS not found”消息出现后.
> VM正在ESXi上运行. VM正在特定数据存储上运行
> Netapp NFS在工作框中挂载磁盘显示没有分区表,尚未能进行十六进制转储.
> VM没有硬复位,必须是OS启动的软复位
>没有安装iso没有“非访客”访问VM,所以
需要是RDP或类似的
>使用netapp备份软件进行备份过夜
>有问题的NFS在后端(阵列级别)进行了精简配置,并在我们看到这些问题后用完了空间.
http://support.seagate.com/kbimg/flash/laptop/Laptop.swf似乎是与实际应用程序最接近的匹配,@ MosheKatz发现.
如果将来发生这种情况,调查应如下：
>您注意到一些但并非所有虚拟机都崩溃了.您怀疑这是由于存储问题(因为它通常是最可能的原因)
>首先尝试隔离一个共同因素.所有崩溃的虚拟机是否共享相同的数据存储区？在这种情况下他们是,但有些机器没问题,所以我们排除了明显的硬件问题.
>检查所有损坏的VM以查看是否存在公共因素(时间,功能等).在这种情况下没有.
>检查其他异常事件.有人举起一面旗帜：
>
> NFS存储是瘦备份的(在阵列级别上).这意味着虽然例如.向ESXi主机提供200GB,实际上只有100GB可用.但是只有阵列具有这方面的知识.我们发现,由于磁盘空间不足,许多虚拟机暂停了.我们虽然这可能是根本原因,但我们的第一步是在后端分配更多存储,以解决这个问题.
>一旦解决了这个问题(简单的UI更改),并且暂停的虚拟机成功重启,我们就回到了原始问题.我们将虚拟磁盘从损坏的虚拟机安装到工作虚拟机,并发现磁盘上没有分区表.我们没有可用的十六进制查看器,因此不得不假设磁盘现在是空的.
>监控系统警告新的虚拟机没有响应.这很棒,因为由于磁盘空间问题,VM的负载只有几分钟而没有响应,所以这个新VM被迅速找到的事实表明良好的监控管理.
>我们打开一个控制台并检查了客人,看到了上面的屏幕抓取.
>
>在这个阶段,我去了服务器故障聊天室,看看是否可以识别程序,而我的存储同事检查了所有虚拟层日志和事件,以确保没有从我们的区域运行存储操作.
>我们应该做的是暂停VM,允许挂起文件被写出来,并分析转储以查看是否可以识别正在运行的程序. Suspend VM to core PDF VMware KB
在一天结束时,我们知道并且虚拟基础架构工具不会像上面那样在客户中报告.我们可以看到没有安装ISO,也没有针对VM记录的事件.
我们可以看到VM不是“硬循环”,只是软重启(这对底层基础设施是不可见的).
我们知道这不是存储方面,因为我们已经排除了这一点.
我们怀疑它不是自动化的,因为它在特定VM上的几个小时内发生.
我们猜测它不是恶意的,为什么控制台会报告Disk Wipe,如果它是:)
因此,结论是用户启动的磁盘擦除.
这就是我的调查,但我希望你发现它很有用.
得到教训：
>备份并测试还原>确保所有用户,特别是管理员用户都知道他们在精简配置环境中工作,并且应该避免写出磁盘格式化(即写入1的负载)>有一个良好的监控系统.>对我来说是一个新的：在任何大型虚拟环境中,安装了诊断工具,准备好工具VM,甚至关闭电源;性能,网络存储.如果这是可用的,我们可以在损坏的磁盘上安装并执行十六进制转储,以查看它是否真的是空的,或者只是缺少一个mbr.我们也可以看到它是用1写的.
