VMFS Recovery

Recovers data from ESX server

ESX error: "Inaccessible virtual machines"

When the ESX server boots or restarts the host agent, it reads the host configuration file called “Virtual_Machine_name.VMX”. If there is an issue reading the VMX file, VM’s name is switched to defaults “Unknown VM” and therefore this error is also known as the "ESX\ESXi Server: Unknown VM" issue.
A lot of different issues can cause this message to appear. Let’s explore all possibilities:


  • Incorrect or VMX configuration file

  • Network issue if NAS used as datastore

  • Datastore issue where VMX files are stored

  • Issue inside VM caused by software or OS


Incorrect or VMX configuration file

VMX files store VM configuration. It’s a simple text file with a structure inside similar to INI files. I.e. “Parameter=Value”.
ESX server reads all present VMX files after the start-up and initialization phase. After boot, ESX starts all validated VMs like scheduled, skipping virtual machines with incorrect VMX files.

Normally *.VMX files don’t intend any manual edits, but sometimes manual interference happens. In this case, any syntax error will make a virtual machine to be inaccessible after the next ESX boot.

Overall, the easiest way to fix a corrupt VMX file is to create a new VM with the same configuration as the corrupt one and specify to use its existing VMDK files from the old virtual machine.

Network issue if NAS used as datastore

This type of issue is well known to any system administrator and hardly our field of expertise. Normally consists of checking the power, physical network links, software protocols, and pairs of server-client responding for data transfer. As NAS is practically an independent PC. Its testing may bring us to another common issue: damaged disk system.

Datastore issue where VMX files are stored

A disk dropped from an array, a broken RAID controller, failed RAID reconstruction, formatted datastore, deleted VMDK file, issues during copy or move operations with virtual machines or standalone VMDK files. These cases are what VMFS Recovery™ was developed for.

First things first.

Naturally, all disk issues are traditionally resolved by re-deploying data from backup.
Estimate this variant and proceed with it if necessary. Unlike back-up, data recovery is much harder to estimate in success and amount of time. So if you need to be 100% sure, back up is your choice.

If the back-up is out of options, data recovery is the only choice left.

To recover lost data from the ESX server, you need to figure out what data storage level encountered a problem. Here is a scheme of data layers in a typical NAS datastore.

NAS data layers significant for data recovery

Please note that it’s not exact disk structure. This scheme was created to ease system administrators' data recovery process and I’ve skipped insignificant layers.

You need to start recovery from the top to bottom and reconstruct all following data layers as they are. Do not try to skip any. Watch carefully to use proper file system setting for each layer.

If you don’t use NAS\RAID or else, you should start from the lower layer.

If you have a RAID disk without a NAS, where VMFS datastore resides, please ignore the second layer called EXT volume.

Therefore, to recover data from NAS with broken RAID disk, we should reconstruct RAID, then find and enter EXT file system, locate files with iSCSI targets (for example sorting data by size), mount them in VMFS Recovery™, locate VMFS partition, browse to required VMDK file, also mount it in VMFS Recovery™ to check the integrity of the guest OS data.

Normally it’s not as scary as may look, because VMFS Recovery™ automatically detects volumes on RAID disks, disk images, and virtual disks. All you have to do is to dig through file systems.

Should you need to recover deleted VMDK file, just connect to datastore using iSCSI or SSH connection, or plug VMFS disk to Windows PC. Scan VMFS partition in Uneraser or Full Recovery-VMFS mode to locate missed VMDK file and you are ready to check VMDK integrity before purchase.

Issue inside VM caused by software or OS

Caused by kernel panics (like Windows blue screen of death), misconfigurations in network settings, various server malfunctions when servers lost their configurations or simply fail to start.

Use your own experience and discretion to check and resolve such issues or visit official vmware help for more options and ideas if the virtual machine still won’t start and you are out of options.




Return to contents