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 |
"monolithicSparse" native Workstation format Required files: Very convenient format as long as everything works fine. |
| # Disk DescriptorFile |
|
| # Disk DescriptorFile |
"twoGbMaxExtentSparse"native Workstation format Required files: Can be imported to ESX with vmkfstools Can be exported from ESX with vmkfstools |
| # Disk DescriptorFile |
|
|
# Disk DescriptorFile # Extent description # The Disk Data Base ddb.virtualHWVersion = "4" |
|
| # 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: this type is used along with an ovf file |
Examples for snapshots / redologs
|
# Disk DescriptorFile # The Disk Data Base ddb.toolsVersion = "7202" |
"vmfsSparse"
|
|
# Disk DescriptorFile # The Disk Data Base ddb.virtualHWVersion = "6" |
|
|
# Disk DescriptorFile # The Disk Data Base |
Snapshot used by Workstation
|
Examples for vmdks used for physical disks...
|
# Disk DescriptorFile |
|
|
# Disk DescriptorFile |
|
| # 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 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"
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 # Extent Description # The disk database |
|
|
# Disk Descriptor file # Extent Description # The disk database
|
"custom"
|
|
# Disk DescriptorFile .... # The Disk Data Base ddb.encoding = "windows-1252" |
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
|
© Ulli Hankeln 2010