Just a quick note today, more of a reference than anything else.
I had the requirement recently to convert a load of VMs that had thin VMDKs to thick provisioned, however the client was not licensed for live Storage vMotion.
In an effort to minimise downtime I decided the best thing to do was use the “Inflate” option in the datastore for that VMDK - this requires the VM to be powered off.
However, Inflate - at least when i’ve tested it is very slow in comparison to Storage vMotion, to keep downtime to a minimum (some inflations were in the order of 200GB+) I wanted to minimise the data that the Inflate process had to fill out on the end of the drive.
The solution is to use sdelete ↗ in OS to fill the target disks with data in order to force the VMDK to full size.
However, there is an interesting caveat:
sdelete.exe -z
Zeros free space in OS, does not affect thin VMDK size when when drive is filled due to thin disk compression/dedupe algorithms.
sdelete.exe -c
Fills with random bits, expands disk to full size.
A little nugget there, the purpose of running sdelete is to fill all the space on the drive, however, when using non-random or zeroed bits, vmware’s thin disk technology dedupes the zeroed writes resulting in the wrong outcome (a disk that is NOT full size). Using the sdelete.exe -c trigger fills the disk with random bits and thus forces the VMDK to its full size.
The result? Inflate ran across a 5GB increase in 30 seconds rather than 7 minutes.
An extension of this is, if you want to do the above but don’t want to fill the whole drive (say a SQL server log drive) you can use a dd port for Windows ↗, this emulates Linux’s /dev/random and will let you specify bytesize and count, letting you set the size of random data to write to the drive.
The below will write a 3GB file filled with random bits to the D:\ drive then delete the file created:
dd.exe if=/dev/random of=D:\file.img bs=1M count=3000 --progress & del D:\file.img
Why not follow @mylesagray on Twitter ↗ for more like this!