故障表现：虚拟化云平台自10月底份开始，有些虚拟机陆续出现死机与无法启动现象，工作人员发现后，有些不重要的测试环境系统的虚机删除后重建，平台维持运行至11月26日，出现大面积虚拟机宕机，发现其中一台物理机内存有问题，更换内存重启动后，发现在此节点所有虚拟机丢失。

现场处理：运维工程师发现问题后，及时把在其他节点运行的约60个虚拟机迁移到VmwareESXi平台，12月1日XenServer虚拟化平台停机，DD命令扇区对扇区备份vGate共享存储的所有共享卷至另外一台华三存储。

故障追溯：本XenServer虚拟化平台初期部署为6台4路512G内存浪潮服务器，配置为3个资源池，共享惠普3par存储的16个卷，在10月12日扩容增加4台相同配置4路浪潮服务器，后在11月26日因后来扩容的服务器中其中一台服务器更换内存，内存更换完毕后，重新启动，出现故障。

故障分析：分析从XenServer虚拟化备份出来的各个卷的数据，发现所有vGate共享存储不同程度存在问题，其中12个vGate共享存储卷被格式化，GIS01、GIS09等多个卷修复重建PV后LV起始位置冲突。

损坏严重的GIS09卷发现以下情况： 

1. 增量入库_81虚拟机VDI丢失（存储位置：28800Sec-420294784Sec）

2. 新建虚拟机一的VDI（虚拟盘1交换区存储位置：28800Sec-33665151Sec，系统虚拟盘：33665152Sec-54694015Sec-）

3. 新建虚拟机二的VDI（虚拟盘1交换区存储位置：54694016Sec-88330367ec，系统虚拟盘：88330368Sec-151384191Sec-）

4. 新建虚拟机二的VDI（虚拟盘1交换区存储位置：151384192Sec-181020543Sec，系统虚拟盘：181020544Sec-248074367Sec-）

5. 新建虚拟机二的VDI（虚拟盘1交换区存储位置：248074368Sec-281710719Sec，系统虚拟盘：281710720Sec-348764543Sec-）

6. 原本属于“增量入库_81虚拟机VDI”200GB的348764544Sec-420294783Sec区域为空闲状态。具体关系图示如下   

      

       
   以下为实际的GIS09的VDI分布截图     

第一个16号新建的Linux虚拟机的16G交换卷，覆盖了200VDI的VHD索引部分，造成关键数据覆盖损坏 

新建的30G容量的Linux系统 

第二个新建的Linux系统虚拟机的16交换卷

新建的30G的linux系统虚拟机的系统

新建的第四个Linux虚拟机的交换卷 

新建的30G第四个虚拟机的Linux系统

故障之前应该是这几个属于一个200G的需要恢复的增量81的虚拟机

虚拟内部数据（利用模板新建的Linux系统，四个一模一样的数据和更改创建时间）

虚拟内部数据（利用模板新建的Linux系统，四个一模一样的数据和更改创建时间）

虚拟内部数据（利用模板新建的Linux系统，四个一模一样的数据和更改创建时间）

虚拟内部数据（利用模板新建的Linux系统，四个一模一样的数据和更改创建时间）

经过修复后可见的残存的数据 

数据的内容，可见被破坏的200G系统内元系统的接受的报文内容，说明这一区域是原本属于期望恢复的增量入库_81虚拟机 

故障结论：部分虚拟机应为vGate共享写入冲突，造成不可逆的覆盖破环。 

故障事故总结原因：

1.增加后来扩容的物理机部署有问题（后来增加的物理机与原来的物理机对vGate存储不是共享关系或缺少仲裁关系）

2.清空数据的卷是否属于误操作（添加vGate时是否有格式化操作）

3.其他未知原因