Home     Documentation       VM-Sickbay        MOA        News        About   

 


VMDK Handbook - Basics

              by Ulli Hankeln

In emergencies visit Sickbay   

[ <<< = back to Table of Content ]


This chapter explains the basics.
It is recommended to read it completely - as it describes the terminology
used throughout this handbook.

<<<



About ...

This is an updated summary of a lot of pages scattered all over sanbarrow.com

Target audience: VMware powerusers , Forensic Investigators , Data recovery

To avoid confusion I do not use terms like growable disk or preallocated disk. Instead I use the internal VMware names.
Most of the times when I mention Workstation the results also apply to other hosted platforms such as VMserver , VMplayer or Fusion. But do not count on that - Workstation is state of the art as far as vmdk-handling is concerned.
Other platforms may lack some of the newest features.

Part of this was copied from older sites I made so the style of writing may differ - this will be corrected later.

If you right now look for help in an emergency also visit my site

or contact me at VMTN or via email.

Hope you find this useful

Ulli Hankeln

<<<


Is this info trustworthy ?



Well you have to judge that yourself.
All I can say is that when ever somebody calls me to rescue his data I use the know how I summed up here.
So if it works ... enough said.

The usual disclaimer: if you reproduce anything explained here and it goes wrong it is your responsibility.

When you have to recover mission critical data ask VMware or Ontrack first.
Come back when both can not help you or in case you do not want to pay their service.

If you ask for help with data recovery from vmdks at VMTN or the german VMware-forum chances are high
that someone tells you to ask me so you can as well read on ...



<<<


What is a vmdk-file ?

When ever a virtual machine accesses a virtual or physical disk it uses an indirect way.
The virtual machine itself only "sees" a small text file which is a detailed description of the virtual disk.
The VMware program no matter if it is Workstation or ESX then links from this description to the actual data.

This small text file with the extension *.vmdk uses an ini-like format.
It needs no strict syntax - and it does not use section names.
To comment lines use #
Optional parameters and comments can be ommitted.
This ini-like file is stored as human readable plain text-file.

The actual data of a virtual disk is stored in a binary format in a file or directly in a physical disk.
In the description file the VMware program - not the virtual achine - then looks up the path to the actual data.
The actual data can be inside any of this ...
*-flat.vmdk , *-s001.vmdk , *-f001.vmdk , *-delta.vmdk
*.dd , *.img , *.v2i , *.spf
\\.\PhysicalDrive0 , /dev/sda

Most of the different virtual disk types uses the description.vmdk file plus external data stored in various formats.
Only one type - known as "one piece growable" combines both "parts" in one file.
In this case the description in plain text is embedded in the large binary data file.


<<<


How to identify the vmdk-type ?



The most reliable way to identify the vmdk-type is to look it up in the description itself.
The "createType" parameter lists the exact type.

You can guess the type by looking at the size and extensions of the files that are present.

a 1 Kb small *.vmdk is probably the description text file used by most types
a 1 Kb small *-00000*.vmdk is probably the descriptor of a snapshot
a max 2Gb large *-s00*.vmdk is probably part of twoGbMaxExtentSparse
a max 2Gb large *-00000*-s00*.vmdk is probably part of snapshot on hosted platforms

a 2Gb large *-f00*.vmdk is probably part of a twoGbMaxExtentFlat

a *-f00*.vmdk smaller then 2 Gb is probably the last slice of part of a twoGbMaxExtentFlat
a large *-flat.vmdk is probably part of a monolithicFlat or vmfs
a large *-delta.vmdk is probably part of a ESX-snapshot
a large *-00000*.vmdk is probably a snapshot with embedded descriptor used on hosted platforms

A note for ESX-users:

Do not use Datastorebrowser to identify vmdks or download them for editiing.
The Datastorebrowser does not display vmdks correctly.
It usually hides *-flat.vmdks and *-delta.vmdks.

To copy vmdks from ESX to a Windows host for editing I recommend WinSCP , VEEAM FastSCP , TRIlead VMXexplorer.

<<<

Sparse and Flat - Thin and Thick

The actual size of a virtual disk can be as large as the nominal disk size or it can be as large as the actual used data.
In the first case the virtual disk data is stored in a way like a raw disk image - like it can be created with Linux dd -
would be stored. In fact both formats are the same. In VMware terms this way is called FLAT.
In the second case only changes to the disks are stored in a proprietary way and the files can not be handled by standard tools like Linux dd. In VMware terms this way is called SPARSE.

FLAT virtual disks do not grow when you add data inside the guest. Performance does not degrade over time.
SPARSE virtual disks grow when you add data inside the guest. Performance degrades the longer the disk is in use.

FLAT vmdks are large - but they do not need regular maintenance and monitoring and perform well.
SPARSE vmdks are small - but they do not perform as well and need maintenance to keeep the size small.

FLAT vmdks are quite safe. Data can be extracted with various non-proprietary tools.
SPARSE vmdks are more fragile. Special tools that understand the extra layer must be used to extract data.

Workstation can use FLAT or SPARSE for regular vmdks and it uses SPARSE for snapshots.
ESX always uses FLAT for regular vmdks and SPARSE for snapshots.

When ESX offers to store its FLAT files as thin provisioned this actually uses a feature of the VMFS filesystem.
This is no different vmdk-type. If you copy a thin provisioned vmdk from ESX to a filesystem that does not support
"thin provisioning" it arrives as regular FLAT vmdk - thick provisioned.

So do not mix SPARSE with thin provisioned - that is something really different. Only the effect is similar.

<<<

Regular vmdks

Regular vmdks means that this are complete virtual disks that can be used by a VM
or can be mounted by any of the third-party mount-tools.

The description text defines all parameters - including geometry, adapter type and used binary data files.

To recover data you need the text description and all referenced binary files.

VMware-name plat-
form
files max
size
desc-
riptor
as
text-
file
type

see *
extensions  

monolithicSparse
WS 1 950Gb
or 2 Tb
no 0 *.vmdk This is a growing disk in one piece - the only disk type that uses no external descriptor but an embedded one
monolithicFlat
WS 2 950Gb
or
2Tb
yes 2 *.vmdk
+
*-flat.vmdk
This is a pre-allocated disk in one piece
twoGbMaxExtentSparse
WS 1 +
x
2Gb slices yes 1 *.vmdk
+
*-s00*.vmdk
This is a growing disk split into 2Gb chunks
twoGbMaxExtentFlat
WS 1 +
x
2Gb slices yes 3 *.vmdk
+
*-f00*.vmdk
This is a preallocated disk split into 2Gb chunks
vmfs ESX
WS
2 depends on
block size
of VMFS
on ESX

256 = 1 Mb
512 = 2 Mb
1024 = 4 Mb
2048 = 8 Mb

on
Workstation
upto 2 Tb
yes 4

/

6
*.vmdk
+
*-flat.vmdk
This is a variant of the "monolithicFlat" format.
The max size depends on the block size used to format the VMFS-filesystem.

This type can appear as thin provisioned or thick provisioned.
For this discussion this subtypes make no difference.

Thin provision is a feature of VMFS - not of this disktype itself.

Don't mix thin provisioned VMFS-type with monolithicSparse
custom WS 2   yes   *.vmdk
+
third-part-image
Used to mount v2i-and other third party formats
streamOptimized   1   no   *.vmdk Used with ovf-xml files

actually this is a variant of the monolithiocSparse format

* = The type column shows the disktype that can be entered when creating vmdks with vmware-vdiskmanager on a Workstation host.. Note that older versions can only handle 0 - 3

<<<

vmdks used to access physical disks

this types use a small textfile to describe a physical disk.

VMware-name plat-
form
files max
size
desc-
riptor
as
text-
file
extensions  
fullDevice
WS description
+
physical disk
2kb yes *.vmdk this is a physical disk useing the full disk
this type is used by Workstation
partitionedDevice
WS description
+
copy of MBR
+
physical disk
2kb yes *.vmdk this is a physical disk and you can allow access per partition
this type is used by Workstation
vmfsRawDeviceMap ESX description
+
link
+
physical disk
      this is a physical disk used by ESX
also called Mapped RAW LUN

this type does NOT allow snapshots
vmfsPassthrough-RawDeviceMap ESX description
+
link
+
physical disk
? yes *.vmdk this is a physical disk used by ESX
also called Mapped RAW LUN

this type allows snapshots

<<<


Snapshots or Redologs


Snapshots - I prefer to call them REDOlogs - can be stored in this 3 different formats.
You can mix different formats in one snapshot-chain but this is NOT recommended !
Usually you let VMware decide which format to use for the REDOlogs.

The description text of a snapshot does not define the disk geometry.
Instead it has a pointer to its parent-disk.

Snapshots can be expanded but this is not recommended - only use in emergencies.

The content of a snapshot vmdk can not be analysed directly.
To read data from a snapshot vmdk it must be attached to a parent disk.

VMware-name plat-
form
files max
size
desc-
riptor
as
text-
file
extensions comment
monolithicSparse
snapshot
WS 1 950Gb
or
2 TB
no *-00000*.vmdk monolithic snapshot - can grow to nominal size
twoGbMaxExtentSparse
snapshot
WS 1 + x 2Gb yes *-00000*.vmdk
*-00000*-s00*.vmdk
snapshot split in chunks - max size 2Gb
vmfsSparse
snapshot
ESX
WS
2 depends on
block size
of VMFS
on ESX

256 = 1 Mb
512 = 2 Mb
1024 = 4 Mb
2048 = 8 Mb
yes *-00000*.vmdk
*-00000*-delta.vmdk
monolithic snapshot used by ESX

<<<




Platform specifics ...


The different platforms can use different formats.

native format = this format can be created by using the GUI
native snapshots = this snapshot format can be created with the Snapshotmanager
native physical disk description = this type of physical disk description is used by the Add-hardware-wizard
import = lists which formats can be imported by the GUI
can handle = this formats can be used but may not be supported - experts only


Workstation

native format : monolithicSparse , monolithicFlat , twoGbMaxExtentSparse , twoGbMaxExtentFlat
native snapshots : monolithicSparse-snapshot , twoGbMaxExtentSparse-snapshot
native physical disk description: fullDevice , partitionedDevice
import: streamOptimized
can handle : vmfs and vmfsSparse

Workstation 7.0 typically uses ddb.virtualHWVersion = 7
Workstation 6.5 typically uses ddb.virtualHWVersion = 7
Workstation 5.5 typically uses ddb.virtualHWVersion = 6
Workstation 4.5 typically uses ddb.virtualHWVersion = 4
Workstation 4.0 typically uses ddb.virtualHWVersion = 3
Workstation 3.2 typically uses ddb.virtualHWVersion = 2

<<<


VMplayer 2

native format : not implemented
native snapshots : not implemented
native physical disk description: not implemented
import: streamOptimized
can handle : monolithicSparse , monolithicFlat , twoGbMaxExtentSparse , twoGbMaxExtentFlat , monolithicSparse-snapshot , twoGbMaxExtentSparse-snapshot

VMplayer 2 typically uses ddb.virtualHWVersion = 4

<<<

VMplayer 3

native format : monolithicSparse , monolithicFlat , twoGbMaxExtentSparse , twoGbMaxExtentFlat
native snapshots : monolithicSparse-snapshot , twoGbMaxExtentSparse-snapshot
native physical disk description: fullDevice , partitionedDevice
import: streamOptimized

VMplayer 3 typically uses ddb.virtualHWVersion = 7

<<<

VMserver 1

native format : monolithicSparse , monolithicFlat , twoGbMaxExtentSparse , twoGbMaxExtentFlat
native snapshots : monolithicSparse-snapshot , twoGbMaxExtentSparse-snapshot
native physical disk description: fullDevice , partitionedDevice

VMplayer 1 typically uses ddb.virtualHWVersion = 4

<<<


VMserver 2

native format : monolithicSparse , monolithicFlat , twoGbMaxExtentSparse , twoGbMaxExtentFlat
native snapshots : monolithicSparse-snapshot , twoGbMaxExtentSparse-snapshot
native physical disk description: not implemented
import: streamOptimized
can handle : fullDevice , partitionedDevice

VMplayer 2 typically uses ddb.virtualHWVersion = 4 or 7

<<<


Fusion 3

native format : monolithicSparse , monolithicFlat , twoGbMaxExtentSparse , twoGbMaxExtentFlat
native snapshots : monolithicSparse-snapshot , twoGbMaxExtentSparse-snapshot
import: streamOptimized

Fusion typically uses ddb.virtualHWVersion = 7

<<<


ESX and ESXi

native format :vmfs
native snapshots : vmfsSparse
native physical disk description : vmfsPassthroughRawDeviceMap , vmfsRawDeviceMap
import: streamOptimized and twoGbMaxExtentSparse


ESX 3 typically uses ddb.virtualHWVersion = 4
ESX 4 typically uses ddb.virtualHWVersion = 7

<<<


The parameters used in a vmdk description

Syntax and valid options ...



Note that the parameters that are listed in a vmdk differ depending on the version of VMware that created them.

In all versions a vmdk description file MUST at least define the parameters listed
in the next boxto be recognized as a valid virtual disk:

version=1 always use 1 at the moment
do not use quotes
CID=fffffffe
parentCID=ffffffff
00000000 - ffffffff is the valid range
do not use quotes
for more info read
createType= monolithicSparse
monolithicFlat
twoGbMaxExtentSparse
twoGbMaxExtentFlat
fullDevice
partitionedDevice
custom
streamOptimized
vmfs
vmfssparse
vmfsPassthroughRawDeviceMap
# Extent description
RW 18432000 SPARSE "test.vmdk"

# Extent description
RW 63 FLAT "test-pt.vmdk" 0
RW 24579387 FLAT "\\.\PhysicalDrive0" 63
RW 131716935 ZERO
RW 5103 ZERO
# Extent Description
RDONLY 63 ZERO
RDONLY 156296322 V2I "import.v2i"
RDONLY 32130 ZERO
This section defines where the actual data is stored.
Each line defines - separated by spaces :
<access type> <size> <vmdk-type> <path to datachunk> <offset>

<access type> options are RW or RDONLY
<size> gives the nominal size in sectors
<vmdk-type> options are FLAT , SPARSE , VMFS , V2I , ZERO
<path to data-chunk> examples are "test.vmdk" or "\\.\PhysicalDrive0"
<offset> offset is given in sectors.

Paths can be absolute or relative - of course it is highly recommended to use relative paths.

for more examples inspect the disktype-example-list
ddb.virtualHWVersion = "4" = Workstation 4, VMserver , ESX 3
"6" = Workstation 5
"7" = Workstation 6 , VMserver 2 , ESX 4
ddb.adapterType = valid options are "ide" , "buslogic" , "lsilogic"
for all the newer types like LSI-SAS use "lsilogic"

Disk-geometry parameters only appear in regular vmdks - not in snapshots

ddb.geometry.cylinders = *
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.geometry.cylinders = *
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
first block shows the typical geometry for a IDE disk smaller than 8 Gb

second block shows the typical geometry of a IDE-disk larger thaan 8 Gb
- yes - for any larger IDE-disk you can use this fixed values !

last block shows a typical geometry for a SCSI-disk

The following parameter is only used by snapshots - not in regular vmdks

parentFileNameHint="test.vmdk" this sets the path to the parent disk
relative paths and absolute paths can be used

The following parameters are optional.

ddb.geometry.biosSectors =
ddb.geometry.biosHeads =
ddb.geometry.biosCylinders =
BIOS-geometry - often used by physical disk description
can skipped
encoding= Do not mess with the encoding parameter unless you really have to !
isNativeSnapshot=
 
ddb.uuid =
ddb.longContentID =
autogenerated values - do not change
if unsure do not use this parameters
in recovery scenarios you can ommit this
ddb.deletable = options are "true" or "false"
this parameter is used by VMware backup tools like VCB and VDR
in recovery scenarios you can ommit this
ddb.thinProvisioned = options are "0" and "1"
regard this as a "for your information only" parameter.
A disk stored on VMFS will use the setting "1" if it is currently useing thin provision.
Disk stored with thick provision don't have this setting or it is set to "0"

<<<


CID-parameters

VMware uses CID-values to verify if the snapshot chain is clean before starting a VM.
If a snapshot chain is corrupt the CID-chain is broken.

Snapshot chains may get corrupted when
- snapshots were deleted manually
- the host crashed
- the system run out of diskspace
- unwise manual edits of vmdk or vmx-files
- a virtual disk was attached to a different VM
- the basedisk was expanded
- ....
All those mentioned cases will be noticed by VMware at startup because of a break in the CID-chain..
As starting the VM in this conditions would further corrupt the virtual disks the VM will not be started.

Good CID-chain

In this simplified listing of one basedisk and its two snapshots in all
cases the child references the CID-value of its parent correctly.

###################### Windows Vista.txt

CID=9a1f1a1f
parentCID=ffffffff
RW 104857600 SPARSE "Windows Vista.vmdk"
ddb.geometry.cylinders = "6527"

###################### Windows Vista-000004.txt

CID=5cdd6af0
parentCID=9a1f1a1f
parentFileNameHint="Windows Vista.vmdk"
RW 104857600 SPARSE "Windows Vista-000004.vmdk"

###################### Windows Vista-000002.txt

CID=c750afeb
parentCID=5cdd6af0
parentFileNameHint="Windows Vista-000004.vmdk"
RW 104857600 SPARSE "Windows Vista-000002.vmdk"

Broken CID-chain

In this simplified listing of one basedisk and its two snapshots
the parentCID in the first snapshot does NOT reference the correct CID-value of its parent.
This means that during the last use of the "windows Vista.vmdk" it probably was used
by another VM, or it was expanded or ...

###################### Windows Vista.txt

CID=a123b123
parentCID=ffffffff
RW 104857600 SPARSE "Windows Vista.vmdk"

###################### Windows Vista-000004.txt

CID=5cdd6af0
parentCID=9a1f1a1f
parentFileNameHint="Windows Vista.vmdk"
RW 104857600 SPARSE "Windows Vista-000004.vmdk"

###################### Windows Vista-000002.txt

CID=c750afeb
parentCID=5cdd6af0
parentFileNameHint="Windows Vista-000004.vmdk"
RW 104857600 SPARSE "Windows Vista-000002.vmdk"

Special CID-values:

CID=fffffffe
parentCID=ffffffff

This vmdk is a newly created basedisk

CID=fffffffe
parentCID=ffffffff

This vmdk is a newly created basedisk

CID=12345678
parentCID=12345678

When the parentCID-value matches the CID-value this snapshot may have
been created while the VM was powered off.
Using identical values when manually editing CID-chains is not recommended.

<<<


How to change the adapter-type of an existing vmdk

A vmdk can be connected to different controllers
- IDE
- Bus-logic-controller
- LSI-logic-controller
- LSI-logic SAS-controller
- new paravirtualised SCSI-controller

In the vmdk-description this is assigned in the parameter

ddb.adapterType =


The vmdk description only understands three values : "ide" , "buslogic" , "lsilogic"
For all the newer controllers like the LSI-SAS use "lsilogic".
If you need to change the adapter-type of a disk that is used to boot a guest it is recommended
to also change the disk-geometry.
If the disk is only used for data adjusting the geometry may not be necessary.
Keep in mind that the adapter-type for a VM is also configured in the vmx-file.
So if you rewrite a IDE-disk to a SCSI-disk do not forget to also change / check the vmx-file

ide0:0.filename = "ide-disk.vmdk"

to

scsi0.present = "true"
scsi0.virtualDev = "lsilogic"
scsi0:0.present = "true"
scsi0:0.filename = "changed-disk.vmdk"

<<<


How to calculate the disk-geometry

There are several reasons why you want to calculate the disk-geometry manually:
- change the adapter-type of an existing vmdk
- create a vmdk description for a dd-file
- create a vmdk description for a img-file like used by Starwind
- create a vmdk description for a *-flat.vmdk when the original description is lost

For all cases we first need the nominal size of the disk in sectors.
Look up the size of the image-file in bytes.

<size of image in bytes> / 512 = <size in sectors>

Next decide which type of geometry you want : IDE or SCSI

For SCSI-disks the typical geometry is * cylinders x 255 heads x 63 sectors

ddb.geometry.cylinders = *
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"

To get the number of cylinders calculate
<size in sectors> / 16065 = <number of cylinders>
When the vmdk uses adapertype buslogic or lsilogic this formula is valid for all disks larger than 1 Gb

For IDE-disks the typical geometry is * cylinders x 16 heads x 63 sectors

ddb.geometry.cylinders = *
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"

To get the number of cylinders calculate
<size in sectors> / 1008 = <number of cylinders>
When the vmdk uses adapertype ide the maximum value for <number of cylinders> is 16383.
So for all disks larger than that - 8Gb - you can use this geometry

ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"

<<<


Examples

Examples for regular vmdks ...

# Disk DescriptorFile
version=1
CID=fffffffe
parentCID=ffffffff
createType="monolithicSparse"

# Extent description
RW 18432000 SPARSE "test.vmdk"

# The Disk Data Base
#DDB
ddb.virtualHWVersion = "3"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.adapterType = "ide"


"monolithicSparse"

native Workstation format
This type uses an embedded descriptor - see


Required files:
"test.vmdk"


Very convenient format as long as everything works fine.
Tricky to handle if something goes wrong.

<<<

# Disk DescriptorFile
version=1
CID=fffffffe
parentCID=ffffffff
createType="monolithicFlat"

# Extent description
RW 27648000 FLAT "test-flat.vmdk" 0

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "3"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.adapterType = "ide"


"monolithicFlat"

native Workstation format


Required files:
"test.vmdk"
"test-flat.vmdk"


This type can be redefined as VMFS
so it is directly usable with ESX.

Instead of assigning a regular *-flat.vmdk
you can also assign *.img files like used with Starwind iSCSI - or assign dd-images created with Linux

<<<

# Disk DescriptorFile
version=1
CID=fffffffe
parentCID=ffffffff
createType="twoGbMaxExtentSparse"

# Extent description
RW 4192256 SPARSE "test-s001.vmdk"
RW 4192256 SPARSE "test-s002.vmdk"
RW 4192256 SPARSE "test-s003.vmdk"
RW 1759232 SPARSE "test-s004.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "3"
ddb.geometry.cylinders = "14222"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.adapterType = "ide"


"twoGbMaxExtentSparse"

native Workstation format


Required files:
"test.vmdk"
"test-s001.vmdk"
"test-s002.vmdk"
"test-s003.vmdk"
"test-s004.vmdk"


Can be imported to ESX with vmkfstools
Can be exported from ESX with vmkfstools

<<<

# Disk DescriptorFile
version=1
CID=fffffffe
parentCID=ffffffff
createType="twoGbMaxExtentFlat"

# Extent description
RW 3072000 FLAT "test-f001.vmdk" 0
RW 3072000 FLAT "test-f002.vmdk" 0
RW 3072000 FLAT "test-f003.vmdk" 0
RW 3072000 FLAT "test-f004.vmdk" 0
RW 3072000 FLAT "test-f005.vmdk" 0
RW 3072000 FLAT "test-f006.vmdk" 0
RW 3072000 FLAT "test-f007.vmdk" 0
RW 3072000 FLAT "test-f008.vmdk" 0

# The Disk Data Base
#DDBddb.virtualHWVersion = "3"

ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.adapterType = "ide"


"twoGbMaxExtentFlat"



native Workstation format
also called "preallocated split" or "fixed split" or ...


Required files:
"test.vmdk"
"test-f001.vmdk"
"test-f002.vmdk"
"test-f003.vmdk"
"test-f004.vmdk"
"test-f005.vmdk"
"test-f006.vmdk"
"test-f007.vmdk"
"test-f008.vmdk"

<<<

# Disk DescriptorFile
version=1
CID=7341dd22
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 16777216 VMFS "test-flat.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.toolsVersion = "0"
ddb.geometry.cylinders = "1044"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"


"vmfs"

native ESX and ESXi format


Required files:
"test.vmdk"
"test-flat.vmdk"


this type can be redefined as monolithicFlat
so it can be easily be used with Workstation.
Workstation can handle this format.

<<<

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=f19b298e
parentCID=ffffffff
createType="streamOptimized"

# Extent description
RW 16777216 SPARSE "test.vmdk"

# The Disk Data Base
#DDB
ddb.geometry.biosSectors = "63"
ddb.geometry.biosHeads = "255"
ddb.geometry.biosCylinders = "1044"
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "1044"
ddb.uuid = "60 00 C2 9f 9b b0 9d 17-15 6c 54 9c 40 8d 33 71"
ddb.virtualHWVersion = "7"
ddb.toolsVersion = "0"

"streamOptimized"

portable format


Required files:
"test.vmdk"


this type is used along with an ovf file
which can be regarded as an "obscured" version of the regular vmx-file - this time in xml-format.
This type uses an embedded descriptor - see

<<<

<<<


Examples for snapshots / redologs

# Disk DescriptorFile
version=1
CID=33333333
parentCID=22222222
createType="vmfsSparse"
parentFileNameHint="test.vmdk"

# Extent description
RW 146800640 VMFSSPARSE "test-000001-delta.vmdk"

# The Disk Data Base
#DDB

ddb.toolsVersion = "7202"

"vmfsSparse"



Snapshot used by ESX
Required files:

"test-000001-delta.vmdk"
"test-000001.vmdk"

used for snapshots on ESX.
Workstation can handle this format but it can not create it.

<<<

# Disk DescriptorFile
version=1
CID=fa4e4198
parentCID=77ae5c02
createType="twoGbMaxExtentSparse"
parentFileNameHint="test.vmdk"

# Extent description
RW 4192256 SPARSE "test-000001-s001.vmdk"
RW 4192256 SPARSE "test-000001-s002.vmdk"
RW 4192256 SPARSE "test-000001-s003.vmdk"
RW 4192256 SPARSE "test-000001-s004.vmdk"
RW 8192 SPARSE "test-000001-s005.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "6"
ddb.toolsVersion = "0"


"twoGbMaxExtentSparse"

Snapshot used by Workstation


Required files:

"test-000001.vmdk"
"test-000001-s001.vmdk"
"test-000001-s002.vmdk"
"test-000001-s003.vmdk"
"test-000001-s004.vmdk"
"test-000001-s005.vmdk"

<<<

# Disk DescriptorFile
version=1
CID=e1649e95
parentCID=e1649e95
createType="monolithicSparse"
parentFileNameHint="test.vmdk"

# Extent description
RW 16777216 SPARSE "test-000001.vmdk"

# The Disk Data Base
#DDB


"monolithicSparse"

Snapshot used by Workstation
Required files:

"test-000001.vmdk"

This type uses an embedded descriptor - see

You can extract the descriptor from this type of snapshots the same way as mentioned with "monolithicSparse"

<<<


<<<


Examples for vmdks used for physical disks...

# Disk DescriptorFile
version=1
CID=54bcc741
parentCID=ffffffff
createType="fullDevice"

# Extent description
RW 156296385 FLAT "\\.\PhysicalDrive0" 0

# The Disk Data Base
#DDB
ddb.virtualHWVersion = "6"
ddb.geometry.cylinders = "9729"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.geometry.biosCylinders = "9729"
ddb.geometry.biosHeads = "255"
ddb.geometry.biosSectors = "63"
ddb.adapterType = "lsilogic"
ddb.toolsVersion = "0"


"fullDevice"



physical disk used by Workstation


Required files:

"test.vmdk"
PhysicalDrive0

VMserver 2 can handle this format but it no longer can create it.

VMserver 1 can handle and create this format.

<<<

# Disk DescriptorFile
version=1
CID=526c949e
parentCID=ffffffff
createType="partitionedDevice"

# Extent description
RW 63 FLAT "test-pt.vmdk" 0
RW 24579387 FLAT "\\.\PhysicalDrive0" 63
RW 131716935 ZERO
RW 5103 ZERO

# The Disk Data Base
#DDB
ddb.adapterType = "ide"
ddb.geometry.biosSectors = "63"
ddb.geometry.biosHeads = "255"
ddb.geometry.biosCylinders = "1024"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "16383"
ddb.virtualHWVersion = "4"
ddb.toolsVersion = "0"



"partitionedDevice"



physical disk used by Workstation


Required files:

"test.vmdk"
"test-pt.vmdk"
PhysicalDrive0

"test-pt.vmdk" is a copy of the MBR of the original disk.



VMserver 2 can handle this format but it no longer can create it.

VMserver 1 can handle and create this format.

<<<

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=0dd6c4a4
parentCID=ffffffff
createType="vmfsPassthroughRawDeviceMap"

# Extent description
RW 156301488 VMFSRDM "iscsi-lun-rdmp.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "7"
ddb.longContentID = "32d4a0950fb635a71add77e10dd6c4a4"
ddb.uuid = "60 00 C2 93 7d 93 ff 85-b2 c0 9a 49 9b aa 70 88"
ddb.geometry.cylinders = "9729"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

"vmfsPassthroughRawDeviceMap"

physical disk used by ESX
compatibilty mode: virtual


Required files:
test.vmdk
and
test-rdmp.vmdk

The rdmp-file is a link to the physical disk.
In datastorebrowser or winscp it seems to have the same
size as the capacity of the physical device. In the virtual hardware editor of ESX this type is listed as Mapped Raw Lun.

To create this type click "add disk" - select LUN and select "virtual" compat mode.

<<<

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=0dd6c4a4
parentCID=ffffffff
createType="vmfsRawDeviceMap"

# Extent description
RW 156301488 VMFSRDM "iscsi-lun-rdm.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "7"
ddb.longContentID = "32d4a0950fb635a71add77e10dd6c4a4"
ddb.uuid = "60 00 C2 93 7d 93 ff 85-b2 c0 9a 49 9b aa 70 88"
ddb.geometry.cylinders = "9729"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

"vmfsRawDeviceMap"


physical disk used by ESX
compatibilty mode: physical


Required files:
iscsi-lun.vmdk
and
iscsi-lun-rdm.vmdk

The rdm-file is a link to the physical disk.
In datastorebrowser or winscp it seems to have the same
size as the capacity of the physical device. In the virtual hardware editor of ESX this type is listed as Mapped Raw Lun.

To create this type click "add disk" - select LUN
and select "physical" compat mode.

<<<

<<<



Examples for the other types ...

# Disk Descriptor file
version=1
CID=e323f28b
parentCID=ffffffff
CreateType="custom"

# Extent Description
RDONLY 63 ZERO
RDONLY 156296322 V2I "virtual-pc-diskformat.v2i"
RDONLY 32130 ZERO

# The disk database
# DDB
ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "9731"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "buslogic"


"custom"



used for v2i disk format
or other third-party images

note the usage of "RDONLY"



Required files:

"test.vmdk"
"virtual-pc-diskformat.v2i"

<<<

# Disk Descriptor file
version=1
CID=e323f28b
parentCID=ffffffff
CreateType="custom"

# Extent Description
RDONLY 63 ZERO
RDONLY 160521417 SPF "C_VOL-b001.spf"
RDONLY 2048 ZERO

# The disk database
# DDB
ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "9992"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "buslogic"


"custom"



used by


StorageCraft ShadowProtect backup


Required files:

the *.spf image itself and a vmdk descriptor like this one

<<<

# Disk DescriptorFile
version=1
CID=3a7b3c99
parentCID=e323f28b
createType="twoGbMaxExtentSparse"
parentFileNameHint="drive-0.vmdk.rdonly"

# Extent description
RW 4192256 SPARSE "drive-0-s001.vmdk"
RW 4192256 SPARSE "drive-0-s002.vmdk"

....

....
RW 4192256 SPARSE "drive-0-s037.vmdk"
RW 4192256 SPARSE "drive-0-s038.vmdk"
RW 1217800 SPARSE "drive-0-s039.vmdk"

# The Disk Data Base
#DDB

ddb.encoding = "windows-1252"
ddb.geometry.biosCylinders = "9992"
ddb.geometry.biosSectors = "63"
ddb.geometry.biosHeads = "255"

this is a snapshot for the Stoarge Craft Shadow protect from above

<<<

# Disk DescriptorFile
version=1
CID=77ae5c02
parentCID=ffffffff
createType="twoGbMaxExtentFlat"

# Extent description
RW 8388608 FLAT "multiple-expand-flat.vmdk" 0
RW 8388608 FLAT "multiple-expand-flat1.vmdk" 0

# The Disk Data Base
#DDB

ddb.toolsVersion = "0"
ddb.adapterType = "ide"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "16383"
ddb.virtualHWVersion = "4"

experimental


the data chunks of the type "twoGbMaxExtentFlat"
usually are upto 2Gb large.

You can also use custom size - in this case the chunks are 4 Gb.
The chunks can be created with fsz.exe - part of the dsfok-tools

fsz.exe multiple-expand-flat.vmdk 4294967296
fsz.exe multiple-expand-flat1.vmdk 4294967296

<<<


<<<


 



© Ulli Hankeln 2010