First things first. This is unsupported by Microsoft, VMware, Amazon, Google, AOL, Geocities, John Madden, Edgar Allen Poe and your mother. Also, not generally a good idea.
Please sign here x_______________________________
Storage providers (NAS, SAN, HCI, Cloud, etc.) typically have preferred block sizes for the volumes created on top of their file system. Alignment is also super critical within a VM and you can read a great post about alignment on Duncan Epping’s blog here. Applications also have some best practices around formatted volume cluster sizes (or allocation units, or block size) based on their default average IO size. For instance, for Microsoft MS SQL, Microsoft highly recommends using a block size (allocation unit, cluster size – will be used interchangeably here) of 64k on any volume containing a database. More detailed info here.
Most often, when deploying an application, you will install the binaries on the root drive (C:\) and place the data on a secondary disk. Most applications allow this, some do not. For those instances where the do not and the application has been installed on the boot drive (C:\), you’re stuck with the cluster size you chose on installation (default of 4k).
If the application cannot deal with it’s data on a different device/directory than its binaries, and the binaries cannot be moved, you’re typically stuck unless you want to re-install and migrate data.
If you want to live on the edge, you might be able to convert the boot drive’s block size using VMware’s free vSphere Converter.
This is a step-by-step for that process. Continue reading