VMDK Handbook - Error-messages

              by Ulli Hankeln

In emergencies visit    



back to Table of Content

Error-messages

The next section list some common error-messages - together with the suggested fix

<<<

Sometimes a crash of the host - no matter if Windows, Linux or ESX - results in a blank vmx.
Not always the error message is useful.
Anyway - if possible restore the vmx-file from the last vmware.log if that is available.
If you restore the vmx from scratch you may easily assign the wrong snapshot and so do more harm than good.

Here is a howto on creating a new vmx-file from a vmware.log

<<<

This may happen with sparse disks on hosted platforms.
In the vmware.log this may appear as "Grain #* @* is orphaned. "
try -R parameter of recent vmware-vdiskmanager

vmware-vdiskmanager.exe -R corrupt.vmdk

if that does not work try to mount the vmdk with vdk or other mount-tools.
if that does not work either use Plan B

<<<

Sometimes a crash of the host - no matter if Windows, Linux or ESX - results in a blank vmdk descriptor.
So when ever this message appears first inspect the vmdk description.
In case you use a vmdk with embedded descriptor - read this first.
If the vmdk description is really blank - restore it by analysing the vmware.logs. Read how to do that ...

If the vmdk description looks fine and the disk in question is using a sparse format you can try to fix the problem
with vmware-vdiskmanagers repair function.

vmware-vdiskmanager -R corrupt.vmdk

If the vmdk description looks fine and the disk is using a split format check wether all referenced slices are present
and use appropriate file permissions.

<<<

There are several possible reasons for this message:
- a vmdk was used with a second VM
- unwise manual edit of the vmx-file
- unwise operations with vmware-vdiskmanager or vmkfstools
- failed operations with snapshotmanager
- bugs, host crashes ....
- buggy backup-software especially on ESX
- and finally the most probable : user-mistake

In all this cases the only thing that is sure is that something went wrong.
As long as you do not know what exactly was the reason ....

- do not trust the settings in the vmx-file

- do not trust the snapshot list in the vmsd file
- do not assume that 000002.vmdk is a child of 000001.vmdk and so on
- do not trust the person who reports the error

To analyse the case inspect all vndk descriptions that may have been in use by the snapshot-chain.
Look up the child to parent filename-hints.
Look up the CID-chain.
Read all last logs.
Then when you have all this info make an educated guess on the most probale reason for the damage.
Once you understood what went wrong you should be able to guess how the snapshot-chain should look like.

Read about the CID-chain here and an example on how to fix it here
In case you use a vmdks and snapshots with embedded descriptor - read this first.

In case a VM with snapshots does not start anymore because a basedisk was expanded you have two options:
- undo the expand of the basedisk
- expand the snapshot
Thesecond option only makes sense with VMs that only have one snapshot - I would not recommend this
In most cases it is very probably easier to undo the expand of the basedisk.



<<<

Did you move your VM to Fat32 ?
Are you using NTFS with Linux or EXT2 with Windows ?
Obviously it is a bad idea to copyvmdk- files larger than 2 GB to Fat32.
If you think your filesystem should support the files you use
you may try this entry in the vmx-file.
diskLib.sparseMaxFileSizeCheck= "false"

<<<

Older VMware versions do not understand this new parameters used with virtual Hardware type 7:

encoding=
isNativeSnapshot=
ddb.uuid =
ddb.longContentID =

It may be necessary to downgrade the version of a vmdk so that it can be used on older platforms - or older mount tools.
In this cases first remove the 4 listed parameters.
If that is not enough also change the

ddb.virtualHWVersion =

Most probably you want to go down from 7 to 6 or 4.

Changing this does NOT damage the vmdk - it can be changed back at any time later.

<<<

Read vmware.log - find out expected screen resolution - change host resolution and try again.
If that does not work remove *.vmss to force a fresh start.

<<<

Disable cpu-compatibilty-test in the vmx-file by adding this lines for the next start.
checkpoint.overrideVersionCheck = "true"

checkpoint.disableCpuCheck = "true"

If that does not work remove *.vmss to force a fresh start.

<<<