Changing the allocation unit size is more about optimising small file access times, limiting file fragmentation, and reducing file slack, space that is unused because a small file does not fully fill a disk cluster and results in a large number of small files effectively "wasting" disk space. For every 1kB file in a 16kB cluster you have wasted 15kB of disk space.
VM software and pretty much every program that needs to access files larger than 4kB will already have methods to tell the operating system "read a 1MB block" and thus avoid any small cluster based performance penalty. There might be some skipping around the disk due to fragmentation, but unless you have a file that is hilariously badly fragmented that is still going to be a small fraction of time lost.
On top of the operating system being able to queue up requests it was also built into SATA protocol in a feature called NCQ or Native Command Queuing. It allowed the operating system to send a series of requests and let the drive reorganise them based upon more intimate knowledge of disk and platter geometry and performance characteristics, allowing an optimisation of small reads and writes and seeks.
Between them the operating system and drive are going to make any cluster size optimisation nearly meaningless. The drive doesn't care about OS cluster sizes because it works with sectors, and the OS can do large reads and writes however the application tells it to.
Just go with the default and leave it at that. It's really not going to make any significant difference to speed.