Cannot power on a virtual machine because the virtual disk cannot be opened
Symptoms
The following are symptoms that can manifest itself with bad VMDK header files:
Virtual machine cannot be powered on.
Error message: Cannot open disk. VMDK file or one of the snapshot disks it depends on.
Virtual disk header file is missing.
Guest operating system fails when creating snapshots.
Windows guest operating system fails with a blue screen when a snapshot is created.
Guest operating systems exhibits strange behavior when a snapshot is created.
Purpose
This article assists you in resolving the situation where the base disk in a snapshot tree has been modified or the virtual disk header file is missing.
Resolution
Base disk was modified in a snapshot tree
A virtual machine modifying the base disk when there are snapshots present can occur when a virtual machine is manually imported and registered on a ESX host. As the VMware Infrastructure Client does not show snapshot files during the disk import process, you must add the base disk. When the virtual machine is powered on, you see that the data is old and that there was a snapshot. Attempting to point to the snapshot file now generates an error as the base disk has changed.
Warning: Following this procedure can result in data corruption. Perform this only if there is no alternative. Be advised that this may destroy the virtual machine. The longer the virtual machine has been running, the higher the chances of data corruption. Make a backup of the base disk.
To allow the virtual machine to power on using the snapshot:
Log in to the ESX host service console.
Type grep '^CID' <filename.vmdk> to see the content of the virtual disk header file. Do not use the <filename-flat.vmdk> as that is the actual content of the virtual disk.
The output appears similar to:
CID=fb183c20
Take note of the CID.
Open the snapshot header file with a text editor. If there is more than one snapshot in the tree, it is the first snapshot in the tree (usually the one with filename-000001.vmdk ).
Locate the line that contains the string parentCID=.
Replace everything to the right of the equal sign with the CID obtained from step 2.
Save and exit the file.
Power on the virtual machine.
Virtual disk header file is missing
These details are covered to address when the virtual disk header file is missing:
Create a header for an imported ESX 2 virtual machine
The procedure to recreate the header file for a migrated VMFS2 virtual disk is the same as that for the zeroedthisk case, except that the CID is set to 00000000 and in the DDB section the following values are used:
ddb.adapterType = "legacyESX"
ddb.virtualHWVersion = "3"
ddb.toolsVersion = "<version #>”
A migrated VMFS2 disk is obtained by running the command:
vmkfstools -M|--migratevirtualdisk <filename>
This converts the specified virtual disk file from ESX Server 2 format to ESX Server 3 format. The filename is reduced in length by 512 bytes and renamed to include the word "flat". A header file is also be created.
Create a virtual pass-through RDM pointer for an ESX 3 virtual machine
If the header file of a RDM is deleted, it is easier to delete the pointer file and recreate the RDM using vmkfstools. You can manually recreate the header file.
Instead of having a -flat.vmdk file you have a –rdm.vmdk file (for virtual compatibility mode) or a –rdmp.vmdk file (for physical compatibility mode). It is these files which point to the RAW LUN.
A Virtual Compatibility Mode Raw Device Mapping is created by:
This creates two files, the header file, mapfile.vmdk and the pointer file, mapfile-rdmp.vmdk .
The header file is the same as that for the (default) zeroedthick disk except that:
<filename> points to the rdmp.file
<create_type> is vmfsPassthroughRawDeviceMap
<TYPE> is VMFSRDM
<adapter_type> is buslogic
Create a Raw Device Descriptor for an ESX 3 virtual machine
When a Raw Device Descriptor File is created, only a header file is created. If this header file is deleted, create another Raw Device Descriptor File by running:
The header file is the same as that for the (default) zeroedthick disk except that:
<filename> points to the absolute path of the device starting with /vmfs/devices/
<create_type> is vmfsRaw
<TYPE> is VMFSRAW
<adapter_type> is buslogic
Create a header for a 2gbsparse virtual disk
For a disk which is obtained as a result of a cloning with -d 2gbsparse the value of <create_type> is twoGbMaxExtentSparse. There are usually multiple extents with names in the format, first_part_filename-sN.vmdk, where N is a three digit integer with loading zeroes displayed. The value of <TYPE> is SPARSE.
The value of <num_sectors> for all the extents (except possible the last) is 4192256. This corresponds to 2GB less 1MB.
For a snapshot disk;
parentCID=<the CID of the parent disk>
parentFileNameHint="<the delta disk of the parent snapshot or the base disk>"
createType="vmfsSparse"
<TYPE> is VMFSSPARSE
<filename> is the -delta.vmdk file
Additional Information
A zeroedthick disk (monotholitic preallocated zeroed_out_later) is the default type of disk. Space required for the virtual disk is allocated during creation. Any data remaining on the physical disk or LUN is not erased during creation, but is zeroed out at a later time during virtual machine read and write operations. This is called “lazy zero” operation which means that the next time the guest operating system starts I/O on the virtual disk, the unallocated blocks (from the guest operating system perspective) are zeroed out in the background. The I/O operation is just the triggering event for the lazy zero to start.
For a thick disk (monotholitic preallocated zeroed_out_never), the space required for the virtual disk is allocated during creation. This type of formatting does not zero out any old data that might be present on this allocated space of the physical disk or LUN.
For an eagerzeroedthick disk (monotholitic preallocated zeroed_out_now), the space required for the virtual disk is allocated at creation time. Any data remaining on the physical disk or LUN is zeroed out during creation of the virtual disk. This process takes a lot longer to complete than for a thick disk.
For a thin disk (monotholitic growable), the space required for the virtual disk is not allocated during creation, but is supplied and zeroed out on demand at a later time. The size of the corresponding flat file, as shown by ls –l , is the not necessarily the current size of the file but it is the maximum size that the file can have.
You can check the true size of a thin provisioned disk by using the command from the ESX Server console: du -h filename-flat.vmdk
