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
<<<
Could not open virtual machine: test.vmx.
"test.vmx" is not a valid virtual machine configuration
file.
Check for missing files failed.
Snapshots are not allowed on this virtual machine.
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
<<<
Cannot open the disk test-000001.vmdk or one of
the snapshot disks it depends on.
Reason: The specified virtual disk needs repair.
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
<<<
Check for missing files failed. The file specified
is not a virtual disk.
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.
<<<
Cannot open the disk test-000001.vmdk or one of
the snapshot disks it depends on.
Reason: The parent virtual disk has been modified since the child
was created.
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.
<<<
The destination file system does not support large
files
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"
<<<
The version of the virtual disk is newer than the version supported
by this program
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.
<<<
The SVGA mode stored in the snapshot cannot be restored on this display
...
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.
<<<
The suspended image contains a virtual machine
that uses floating point features that do not match the supported
features on the real machine ...
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.
<<<
|