Shulou(Shulou.com)06/02 Report--

VMware virtual machine device information:

1. VMware virtual machines (quantity: 40-50 groups; occupied space: 1.8TB)

2. VMware virtual machine-- ESX SERVER shares an IBM DS4100 storage

VMware virtual machine failure description:

In the course of using it, due to the loss of the virtual disk reported in vc, execute fdisk-l to check the disk through ssh to ESX, and storage has no partition table. After rebooting all devices, ESX SERVER cannot connect to the STORAGE where the DS4100 is located.

Through the consultation with the administrator, we learned that a windows 2003 server had been connected in this storage network.

VMware virtual machine failure analysis:

From this, we can speculate that it is possible that the windows 2003 caused the vmfs volume corruption through its exclusive operation on storage.

1. Based on the analysis of the whole storage, it is found that the partition table is clear 0, there is a 55aa valid end flag, and there is a hard disk ID flag.

2. Looking from front to back, I found a NTFS volume without any data. Through the BITMAP analysis of this NTFS volume, we know that the size is about 1.8T (all space), the 3G position takes up part of the space, and the space around 0.9T takes up part of the space, but the total space is not more than 100m.

3. Based on the analysis of the VMFS volume, it is found that there are two groups of VMFS partitions in the original 1.8TB disk. The second group is about extend for the first group, the first group is about 1.5T, and the second group is about 300GB. Because the NTFS partition does not write data to the second VMFS partition (the DBR backup of the last sector does not cover the useful data), so the focus is on the first VMFS partition. According to the analysis of the first group of VMFS, the header structure is lost, the first-level index and the second-level index exist, and the data area covered by NTFS happens to be the temporary memory mirror of a group of virtual machines. VMware virtual machine data recovery steps:

Step 1: mirror backup the entire STORAGE.

Step 2: after analysis, connect two VMFS partitions and extract all VMDK and configuration files directly according to the organization of VMFS analysis.

Step 3: migrate back to ESX SERVER directly through nfs.

Note: since the fault storage has been securely backed up in this example, the first set of VMFS volume headers, index lists, partition tables and other information are directly rebuilt during the repair, which is directly attached to the ESX SERVER environment, which is regarded as the second solution. VMware virtual machine data recovery results:

After two days, the data has been successfully extracted, after user acceptance, the data can be read correctly, so that the data recovery work is over.

Tips for operating VMware virtual machines:

1. In this example, the problem is still caused by improper mutual exclusion in the optical fiber environment. In fact, the volume should be repartitioned on the WINDOWS system and formatted into NTFS, and then the partition is deleted. Because the mutex of ESX VMFS does not depend on hardware, it only depends on the driver layer of the operating system, so we must be careful when other servers connect to the storage network and try our best to consider the storage allocation permissions.

2. Because of the convenient centralized management of information, ESX data is often very important in real use. We must do a good backup and consider the convenience of migration in case of damage.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.