Last week I was asked to make 2 copies of a virtual machine. The machine in question was a Ubuntu VM with a 250 GB datadisk in thin format. When I checked, the data disk wasn’t so thin anymore. While there was only 21 GB data written to the disk, 240 GB was provisioned. It appeared that, at some point in the history of the machine, someone had written 240 GB data to it and then deleted most of it. I didn’t want to clone the machine (twice) as is, but wanted a lean (thin) datadisk. I thought storage vmotion could provide that, but, as it turns out, there is more to it than just that.
Firstly, when data is deleted, only the pointer to this data, in the filesystem, is removed. The data itself is still present. To really get rid of the data, you have to zero out the disk. This can be done by SDelete by Sysinternals on Windows machines and by using dd on Linux machines. If your disk is thin, you have to remember that zeroing it out will provision the entire disk space, so you have to check if there is enough space left in your datastore before zeroing.
Secondly, a regular sVmotion to another datastore, as a thin disk, will not do the trick. You have to sVmotion it to a datastore with a different Blocksize. The reasons for this is the different Datamover used to sVmotion between disks with the same Blocksize and between disks with different Blocksizes. As explained by Duncan Epping in his blogpost Blocksize impact?. So I created a Datastore with a different Blocksize vMotioned the disk there, zeroed it out and moved it back. This did the trick and I could now create my two clones.
There is a drawback however, as also explained by Duncan, the legacy Datamover (fsdm) is much slower than the newer Datamover (fs3dm and fs3dm – hardware offload). Wich would plead for uniform datastores in a cluster. For now, I will keep my extra Datastore for thinning purposes only.