Restoring VM from virtual disk files

[mdvlinguest]

Hello

I have accidentally ried to delete a VM folder. Config files are deleted and have no backup of them. However because the VM was running vmdk and 3 other files could not be deleted. The following files are now available. How can I restore/create the VM using these files?

Saeed-flat.vmdk

Saeed.vmx.lck

vmx-Saeed-407251372-1.vswp

Saeed-184629ac.vswp

Please help me.

Thanks in advance.

[abhilashhb]

This will help you restore your VM

[mdvlinguest]

Hi

I just created a new VM and even installed an OS in order to initialize and fill its disk but it does have flat vmdk so I can simply replace my own flat vmdk file. In what situation a flat vmdk is create for a VM?

Regards.

[abhilashhb]

Before doing anything take a backup of the vmdk files you have left or you will lose them too if something goes wrong during recreation.

The flat.vmdk will be present for every VM you create.

To Find it login to ESXi using SSH and go to /vmfs/volumes/<datastore>/VM and you will find the flat.vmdk there.

Now you can take your actual one and replace it with the new one. Its all given in the blog post i shared with you. Do not try doing it from GUI.

[continuum]

Here is what I do ....

How to rebuild a lost vmdk descriptorfile if the flat.vmdk still exists

Plan A - create from scratch:
Good for single flat-files or dd-images for p2v

assume the size of the *flat.vmdk in bytes is X (use ls -l via ssh to get the size - do not read it from datastorebrowser
the name of the flat file is name-flat.vmdk

now open a calculator and do the math

N = name-flat.vmdk

W = X / 512
Y = W / 1008 ( round down the result )
Z = W / 16065 (  round down the result )

next open a texteditor and paste this snippet
( The snippet contains the required parameters - if you do not have a special reason to set the newer optional parameters exactly or in case you dont know about them at all - ignore them rather thjan guessing some values ! )

# Disk DescriptorFile
version=1
CID=12345678
parentCID=ffffffe
createType="vmfs"

# Extent description
RW W VMFS "N"

# The Disk Data Base
#DDB
ddb.geometry.cylinders = "Z"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

edit the variables marked in red.

Store the result as name.vmdk if you need a SCSI-vmdk.

If you need a descriptor for an IDE-vmdk use this snippet

# Disk DescriptorFile
version=1
CID=12345678
parentCID=ffffffe
createType="vmfs"

# Extent description
RW W VMFS "N"

# The Disk Data Base

#DDB

ddb.geometry.cylinders = "Y" or "16383"   #  - (  use  Y = W / 1008 ( round down the result ) if Y < 16383 - otherwise use 16383 )

ddb.geometry.heads = "16"

ddb.geometry.sectors = "63"

ddb.adapterType = "ide"

Store the result as name.vmdk if you need a IDE-vmdk.

The latest ESXi versions have descriptorfiles with more options.
Only use

encoding="UTF-8"

if necessary - everything else will be added on first start automatically.

Plan B:
necessary if you have a whole bunch off flat- vmdks and deltas
recommended if you assume you have a thin provisioned vmdk or if the size of the file does not match what you  expected or remembered
As in plan A start with a copy of the snippets from above but this time do not calculate the variables according to size of the found flat but read the variables from recent vmware.logs
have a look at VMDK-Handbook-Basics
- there I describe the procedure in details

Plan C:
my first choice when I have no vmware.logs to run plan B or when I have to deal with newly deleted files ...
dd if=/vmfs/devices/disks/yourdevice:1 of=/tmp/vmfs.dd bs=1M count=1500
download the file to a host that can run
strings vmfs.dd > strings.txt
grep "RW " strings.txt > extent-lines.txt

if the original vmdk descriptor was newly deleted extent-lines.txt probably has the variables you need for the line :

Plan 😧
if you do not have the slightest idea about the size of the vmdk and even assume that the file you have may be truncated ...
fdisk /vmfs/volumes/datastore/somedir/unknown.file
when fdisk complains something is wrong with the file - else enter p
The output looks like

#  fdisk  /vmfs/volumes/datastore/unknown.vmdk

***

*** The fdisk command is deprecated: fdisk does not handle GPT partitions.  Please use partedUtil

***

The number of cylinders for this disk is set to 3263.

There is nothing wrong with that, but this is larger than 1024,

and could in certain setups cause problems with:

1) software that runs at boot time (e.g., old versions of LILO)

2) booting and partitioning software from other OSs

   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /vmfs/volumes/datastore/unknown.vmdk: 26.8 GB, 26843545600 bytes

255 heads, 63 sectors/track, 3263 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

which will give you a good guess to calculate
W = X / 512

make W slightly larger and make sure X is a multiple of 512

Plan E:
as it takes longer than Plan A and is more likely to get bad results I dont use plan E and do not recommend it.
Details see VMware Knowledgebase and countless blogs.
It usually starts with ...
create new VM ...
rename file ...
make sure you do NOT ...
I dont repeat the details here...
this procedure will for example often fail to reconstruct the correct size if the original size was modified by a backuptool or comes from an imported P2V-candidate or an OVF

Test is this really a normal VMware flat.vmdk ?
hexdump -C -n 4 name-of-file
if the output contains COWD , KDMV , # Di , <xml it looks like this is not a real flat.vmdk or dd diskimage

How do I create and edit descriptor-vmdk files ?

IMHO the easiest way to create and edit files on VMFS is to use the buildin editor of WINSCP.
Naviagte to the correct subdir of /vmfs/volumes/...
Right click into empty space in the right panel of WinSCP - select NEW and then FILE.
This creates files with correct line endings and even handles copy and paste from VMTN correctly.

I have myvm-flat.vmdk and just created a new descriptor file for it. Can I upload myvm.vmdk into the directory where I already have myvm-flat.vmdk with the Datastorebrowser ?

No - dont even think about using Datastorebrowser.
Every filemanager worth mentioning displays 2 files as 2 files.
Datastorebrowser follows its own/different logic. If it assumes that a file named example-flat.vmdk and another file named example.vmdk belong together it starts to display them incorrectly.
It drops the "-flat" in the name of the large file and hides the small descriptor file completely.
Due to this strange behaviour the typical user experience with this tool is the sudden shock "will the vmdk descriptor I just upload delete the existing flat with the same name ? - merde ..."

If you want to do the task quickly without errors - just dont use Datastorebrowser.
In case there is ssh available and you have to use Datastorebrowser rename the *name-flat.vmdk BEFOR you upload name.vmdk to  "name-flat.vmdk.renamed"
When you doublechecked the uploaded files and the filenames reset  the original name.