Normally with sparse images, especially on disk-backed storage, you inherit a lot of bad performance issues, hammering your disks with useless IOs. OS installs take a lot longer during the formatting phase and initial install. Patching takes longer. Everything takes longer, and it gets worse with each byte added by any VM in the datastore.
But if you alternatively use full disks, you will waste incredible amounts of disk space.
Let's not pick a poison any more.
Combine the advantages!
Make the fully allocated base image
We're creating a 4GB image using dd.
4GB is vast for stripped down installs. I use Alpine Linux and CentOS, those come at about 200MB - 500MB. Use more space, i.e. 20GB for a "heavier" OS or a workstation.
This part will be exactly as fast as any "normal" thickly / fully provisioned image. And this is what is written to at start, meaning your OS and the "standard" binaries can go there. I use a second disk for the application data or custom applications.
Extend it to a half-sparse image
As you can see it's now a 11GB Image using 4GB.
This area is the "overflow", sparsely allocated and it'll only be used in exceptional cases.
Now you can do your OS installs and basic patching etc. at the full speed.
Formatting anything beyond the 4G boundary will be slow. In practice, only the filesystem structures will allocate some space there. Also, remember it will still be *less* slow than it would be if all your VMs had been fully sparsified and installing at the same time, multiplying fragmentation by the number of writers (==running vms)
I hope you like this, and I hope it also serves as a little insight why sometimes "crafting your own" can give you interesting options.
Do you know if there's a simple (1-2 lines of shell) way of converting this to a vmdk or qcow2 file?
How about doing the same on the ESXi shell? (i'm aware vmfs is less shitty with this in general)