Unaligned I/O can reduce storage performance un-necessarily, as it results in more I/O operations than necessary.
Whilst you can utilise performance policies, unless you need to, for the purpose of simplicity and avoiding the risk of errors, the general recommendation is to set all VMFS volumes to use the relevant Nimble ESXi performance policy (e.g. ESXi5).
Additionally create a copy of the ESXi5 policy but set it to not cache, and use that performance policy to create datastores to use exclusively for where there is no requirement for caching (i.e. write only volumes such as SQL/Exchange log files).
To utilise performance policies for maximum performance (SQL used as an example here, you can do the same for Exhange):
Put the OS drive on a nimble datastore that has the ESXi5 performance policy, put the data drives on a VMFS volume that is on a datastore that has the Nimble SQL (the right version of SQL) data perf policy, and put the log drives on a VMFS that has the SQL log perf policy - this is how I have mine configured, with no issues.
i.e. the perf policy matches the workload, not VMFS, but the data stored on that datastore must exclusively be the type of data that matches the Nimble performane policy.
If you accidentally put the wrong type of data on those volumes it could lead to unaligned IO.
I have mine set up with all ESXi5 datastores in a VMware datastore cluster, and keep the datastores with application specific nimble performance polices outside of that cluster to minimise the risk of this happening. I also name the app specific datastores to indicate that they are just that, to minimise human error).
Explanation here: https://connect.nimblestorage.com/thread/1717
which also includes a link to:
It is less of an issue now that Windows 2008+ does this automatically when creating new volumes, but if you have alignment issues check that your drives within the guest are aligned (https://technet.microsoft.com/en-us/library/dd758814(v=sql.100).aspx), and check that your windows volumes holding SQL data and logs are using a 64k NTFS allocation unit size.
