Jun
23

Recreating Missing VMDK Descriptor Files!

Paul Shannon ESX, VMware, Virtualisation 2008-06-23

A few times over the years VMDK files have been ‘lost’ when a customer has had to shutown their storage in a less than graceful fashion.

In every case so far, touch wood, it is only the desciptor files that have been deleted so the raw data is still present in the *-flat.vmdk file.

It is actually quite simple to rescue the situation you simply restore from backup. Ahaha what if you do not have a backup, then there is another way.

Firstly, identify the size of the *-flatvmdk file using putty or something similar. Once you know how big it is, 250GB for instance, either find another flat-vmdk file the same size or create a new one that size.

Once you have created or identified the 250GB *-flat.vmdk you’ll notice it has an accompanying *.vmdk file, run a cat against it, and you’ll notice something like this:

cat rescue_me.vmdk

# Disk DescriptorFile
version=1
CID=7131fc31
parentCID=ffffffff
createType=”vmfs”

# Extent description
RW 419430400 VMFS “rescue_me-flat.vmdk”

# The Disk Data Base
#DDB

ddb.virtualHWVersion = “4″
ddb.geometry.cylinders = “26108″
ddb.geometry.heads = “255″
ddb.geometry.sectors = “63″
ddb.adapterType = “lsilogic”
ddb.toolsVersion = “7201″

Now make a copy of this file to the folder that has the original *-flat.vmdk file:

cp rescue_me.vmdk /vmfs/volumes/mysan/rescued/rescued.vmdk

Using your favourite editor change the following line as below from:

RW 419430400 VMFS “rescue_me-flat.vmdk”

To:

RW 419430400 VMFS “rescued-flat.vmdk”

Obviously making sure that the name of the .vmdk file corresponds to the scis*:*.fileName field in the Virtual Machine vmx file.

You should now be able to power on the VM with all the original disks intact.

Clear as mud, I hope.

,
Address: http://www.vm-aware.com/2008/06/recreating-missing-vmdk-descriptor-files/
« Re-enable Non-VDM Client RDP Connections
Customising RDP Dialogs »
Trackback

11 comments untill now

  1. VMware: Recreating Missing VMDK Descriptor Files! « ICT-Freak @ 2008-06-23 11:27

    [...] de rest van de post hier: http://www.vm-aware.com « VMware: ESX Whitebox [...]

  2. Vikash Kumar Roy @ 2008-09-08 21:19

    Hey Paul thanks for your blog , it was really helpful

    Thanks,
    Vikash

  3. Arcom @ 2008-09-17 15:25

    Excellent tip, thanks!

  4. Serge @ 2009-01-13 16:22

    What if the drive with the original *-flat.vmdk doesnt have enough space?
    SD

  5. Paul Shannon @ 2009-01-15 17:58

    If I understand you correctly, you could create the new VMDK on any volume that has enough space, because all we are interested in, is the small pointer file. Once the VMDK has been created on the other datastore simply copy the pointer file over to the desired location using something:

    cp /vmfs/volumes/FreeSpaceLUN/myhelperVM/myhelperVM.vmdk /vmfs/volumes/NotMuchFreeSpaceLUN/brokenVM/brokenVM.vmdk

    Hope this all makes sense

  6. Mike Laskowski @ 2009-03-11 13:01

    Hey what would cause the VMDK pointer file to disappear? I had couple VM’s that all the sudden lost the VMDK’s? It started about 2-3 weeks ago when we updated all the ESX servers with the lasts updates and also Virtual Center to Update 4. The first time it happen the VM tried to v-motion and it failed, then it got powered off on its own for whatever reasons. After that when I browse the datastore all I see the –flat.vmdk, I know how to resolve the issues by re-creating the pointer file, but I’m trying to figure out all the different reasons that can cause this. I got another VM that had a similar issue, I was on it 2 days ago, I shut down the VM and today it’s missing the C:\ VMDK pointer file. Nothing really changes no storage outages etc.. ? Any tips would be great on why or what can cause this.

  7. Paul Shannon @ 2009-03-12 11:03

    Hi Mike

    Thanks for posting.

    I have to be honest I have only seen this occur under three different sets of circumstances:

    * – Unreliable iSCSI connection to back-end storage
    * – Power/Connectivity outages to back-end storage
    * – Excessive I/O causing long time outs

    If you know that you are not suffereing these problems, then I would suggest that you may want to log a call with VMware, because it could be a metadata issue on the affected LUNs.

    If you do pursue this further let me know how you get on.

    Thanks

    Paul

  8. George @ 2009-04-16 17:24

    “Firstly, identify the size of the *-flatvmdk file using putty or something similar. Once you know how big it is, 250GB for instance, either find another flat-vmdk file the same size ”

    If we copy an existing descriptor file from another VM having the same disk size attached to the same LUN, don’t we have to change the “CID” and/or the “parentCID” values in the descriptor file ?

  9. Paul Shannon @ 2009-04-16 21:34

    You only really need to worry about the CID/Parent CID if you have existing snapshots associated with the problematic VM. If you do have snapshots then you need to set the CID in the new descriptor file to the Parent CID value found in the first snapshot.

    Hope this helps

    Paul

  10. George @ 2009-04-16 21:42

    Thanks for the reply. It worked, although I will have to wait for afterhours to make sure the VM powers on fine.

  11. Manuel Arrington @ 2009-06-04 05:36

    Paul you saved our skins tonight. My network manager and I used this article to recover from “DISASTER.”

    If you are ever in Largo, MD we will buy you a cold one or two.

Add your comment now