Flat VMDK files after trying to delete files from datastore

[CesarTabares]

I tried to delete a VMDK file from a datastore, because I thought it wasn't in use, and I needed the space. I couldn't find the VM searching for the name of the VMDK file, so I thought the VM was gone. Turned out someone had renamed the VM, so it was actually in use, so I wasn't able to delete the VMDK file.

I searched with Powershell for the files in one datastore, and that is how I found this mysterious file in the first place.

After giving me the error that it could not be deleted, the file did not appear in the search anymore, and the filename was changed to ******-flat.VMDK I think, and the column specifying Type did just say File, instead of Virtual Disk. In addition, the files did not appear in the search anymore.

Today, one day after, everything is back to normal. Has anybody seen this behaviour before and could tell me what happened?

[unsichtbare · Accepted solution]

Every virtual disk is actually 2 files: VMname.vmdk and VMname-flat.vmdk

Unfortunately, the datastore browser only displays the VMname..vmdk, but gives it the properties of VMname-flat.vmdk. Use Putty, connect to the ESXi host via ssh, browse to the VM folder and use: la -lahtr to list authoritatively the contents. You can also run: du -ch to check actual usage.

[continuum]

Get used to this - it is an old bug of the Datastorebrowser:
Descriptor-vmdk and Flat-vmdk are displayed as one file - if Datastorebrowser considers the pair of them as healthy.
Descriptor-vmdk and Flat-vmdk are displayed as 2 files - if Datastorebrowser considers the pair of them as misconfigured.
The behaviour could not be more stupid : it can actually give you a few moments of pure terror and pain once you use Datastorebrowser to upload or download your first Flat.vmdk
The Flat.vmdk is without doubt the most important file of a VM - a Filebrowser that does a good job should never interprete the file content at all by it self.

[m3llow]

When this issue occurs, do not reboot the VM, until you can plan for an outage. This issue can be fixed by recreating the descriptor file(s) Ref Recreating a missing virtual machine disk descriptor file (1002511)

Easy way is to use WinSCP to browse the VMFS volume and download a copy of a descriptor file from a different VM. It must have exactly the same size disk. Right click and Edit that file to match the name, SCSI adapter etc and upload it into the folder of the problem VM.

After the new descriptor file is uploaded, open its properties and verify the Permissions are correct. You can simply type 0600 in the Octal: field, click OK and that should take care of it. The VM should now power on without issue.