Obvious check to start with is to check if there are any other VMs that may be accessing the disk. If there are none, the one VM using the disk is powered off and not powering back on due to an error message similar to the one below then the issue may be with either corrupted or missing descriptor file for the VMs disk.
First step is to obviously connect to the host where the VM is registered with Putty or simmilar application and log in with root account and navigate to the VMs directory.
If you do not know the location of the VMs files, you can find these in the VM Options/General Options for the VMX file (VM settings file) or through checking the individual disks locations if they are located in different directories on different datastores.
Of course you can also get that from the VMX file.
Once you are certain, where the disk in question is located you need to get the full size of all the disks in bits by running a command:
[firstname.lastname@example.org]: ~>$ ls -la # note: do not use the human-friendly option: -h
Once there you need to rename the old descriptor file to avoid any confusion to something obvious like
[email@example.com]: ~>$ mv AffectedVM.vmdk AffectedVM.old
...and create a new disk - i.e.
temp.vmdk - with exactly the same size as the one in question. Obviously, that is assuming that the datastore file system is not corrupted and the original binary "flat" file is not corrupted, but this we will discuss on another occasion.
[firstname.lastname@example.org]: ~>$ vmkfstools -c <size> temp.vmdk -d thin
The new disk should be created as "Thin provisioned" so to not have all of the space reserved straight up when the
temp-flat.vmdk for the new disk is created. Thin provisioned disk will not take practically any space on your datastore and will be allowed to be created even if you have just a few GB left on the datastore.
Once done remove the
temp-flat.vmdk as it is not required any further.
[email@example.com]: ~>$ rm temp-flat.vmdk
What we are interested in is the
temp.vmdk file which we are going to edit and use as our new description file for the affected VM
At this point, we are almost done. But dont let that get to you as you need to be very careful as if you rename your
AffectedVM-flat.vmdk file, all of your data in that disk will be gone.
What is left for us to do is to rename the
temp.vmdk and point it in the right direction.
[firstname.lastname@example.org]: ~>$ mv temp.vmdk AffectedVM.vmdk
As I am a firm believer in understanding what is happening, what things are used for and how, we may discuss descriptor files in a little more detail some other time.
Today however, we need to get our VM back up and running.
Re-point the new descriptor file from
AffectedVM-flat.vmdk. To do this you need to edit the file with any text file editor and change the section
Extent descritpion from
AffectedVM-flat.vmdk. Remember to change the
ddb.thinProvisioned flag if required (1 - for true, 0 for false).
Once the file's saved, the VM should power on as normal. In some cases, it may be required, however not necessarily, to reload the VMX file:
[email@example.com]: ~>$ vim-cmd vmsvc/getallvms # note down the relevant VMID from the above # command's output and reload the vmx by running: [firstname.lastname@example.org]: ~>$ vim-cmd vmsvc/reload VMID
At this point the VM should power on and detect the drive correctly.
I hope this helped at least a littlebit and I will continue the subject in the next post about recreating a descriptor file for a snapshot of a VM.
I am really happy to have joined Paul "The IT Wiz" and hope you will enjoy the content from me - please send me your feedback (if any) @vNowakB or #sshguru