You’ve just scheduled a week of vacation in a remote location near some sand, water and a wee dram of your favorite beverage. Your backup feels confident that he can handle the situation while you’re gone but just before you walk out that door; you pick up your phone to hear a hysterical voice on the other end explaining that the accounting department VM crashed and now it won’t start up. You discover that the vmdk file that describes your VM’s disks has corrupted itself and isn’t repairable. Nothing makes your palms clammy as fast as a corrupted virtual machine (VM) but if you have a clean pair of sweat bands or a towel handy, you’ll survive it I promise.
Don’t let the air out of your favorite floatation device just yet. There’s hope for your VM and your vacation. You can recreate those corrupted VMDK disk descriptor files with little effort and no sweat.
A typical virtual machine descriptor (VMDK) is a small (~300B) text file that describes its associated disk file and named for the VM to which it refers. For example, if you have a VM named â€œRHEL5.4â€ then your primary VMDK file has the name RHEL5.4.vmdk. The primary disk file name is RHEL5.4-flat.vmdk and its size corresponds to the amount of space allocated to the VM’s primary disk.
Let’s look inside a VMDK file and examine it more closely. The following listing (VMDK File) is an actual live VMDK file taken from a VMware ESX 3.x host.
# Disk DescriptorFile
# Extent description
RW 75497472 VMFS "RHEL5.4-flat.vmdk"
# The Disk Data Base
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "4699"
ddb.toolsVersion = "7201"
ddb.virtualHWVersion = "4"
The version=1 entry refers to the version of the Disk Descriptor File. VMware products all have version=1 in their VMDK files. The CID, also known as the Content ID, is a randomly generated value and changes each time a VM starts. The parent CID has a default value of ffffffff and only changes if the VMDK is part of a snapshot. The createType line describes the type of virtual disk that’s defined by the VMDK. There are 12 possible values for this parameter. The type vmfs type means that the disk file resides on an ESX server disk volume. Extent description provides information regarding disk access, size (sectors), extent type and filename. In our example, the disk is Read/Writable, 36GB in size, VMFS extent type and the name of the actual disk file that is 36GB. Finally, the Disk Database describes the virtual disk’s drive geometry and adapter type.
Since this file is an ASCII text file, you can edit it with any text editorâ€”a bit of trivia that will come in handy later. Each virtual disk, regardless of how many files compose the disk, has its own VMDK file.
I spent a lot of space going over VMDK anatomy to show you that VMDK files, while required, are not complex or cryptic. To recreate your corrupted VMDK file(s), you need to know one important piece of information: The original VM disk size(s). There are at least three ways to recreate the VMDK file (In order of increasing difficulty): Restore from backup, copy and edit a similarly configured VMDK file, Recreate a VM with same sized disks as the original and edit the disk filenames to which they refer.
There’s no substitute for a recent backup. Restore the VMDK to its original location and you’re back up and running in no time.
Since you don’t have a backup, you have to move to Plan B: Copy a similar file and edit the disk filenames. Often, VMs spring from a VM template, which means they all have the same disk configurations. If you have a VM with the same sized disk(s) as the corrupted one, copy the VMDK from a good VM to the corrupted VM’s directory. Edit the VMDK with a text editor only changing the name of the filename(s) to which it refers. Your VM should start without issue.
In the third scenario, either you don’t have any other VMs with similarly sized disks or you can’t figure out how to convert GB to sectors and calculate drive geometry. And you don’t have a good backup.
This procedure requires that you create a new VM with the same size disk(s) as your corrupted one (hopefully you have enough space to do so), and then follow the procedure described above in Plan B.
As you’ve seen, even the worst case scenario isn’t too horrible and none of these procedures will cause you to miss or postpone your much needed vacation. If you don’t remember the exact sizes of your disks, cd into the directory of interest and issue a ls â€“la command to examine the file sizes.
Have you averted disaster with a similar technique? Write back and let us know.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62