Traditional VMFS datastores hold individual files and VMDKs used by VMware and guest OS systems.
ASM disks are represented in VMFS as VMDKs, which are stored within datastores.
A datastore may reside on a single VMFS volume, or it may span up to 32 volumes by adding extents. If a data store is exhausted, it may be extended by adding extents on the same or a different VMFS volume.
If extending a datastore by adding extents on a new VMFS volume, ensure the new VMFS volume is created on a ScaleIO volume sharing the same size and performance characteristics as the primary datastore extent.
Datastores and VMDK sizes can be adjusted, but all VMDKs within a single Oracle ASM disk group should be the same size and reside on the same ScaleIO storage pool.
A VMFS volume may only be assigned to one datastore.
Datastores may be resized to use remaining free space on a VMFS volume. Volumes may also be resized, allowing VMFS volumes to be expanded and therefore datastores to be increased.
Adding extents to a datastore to allow it to span multiple VMFS volumes allows ESX to leverage multiple I/O queues to service I/O requests to a single data store but offers limited performance benefit as extents are concatenated.
For high performance environments, dedicate specific datastores to specific ASM diskgroups (e.g. +DATA, +FRA, +GRID etc.) and dedicate those ASM diskgroups to specific databases.
For very high performance environments, map VMDK’s to separate datastores to increase isolation and performance parallelism, but be aware this will increase management overhead.
For high performance environments, do not consolidate multiple VMs onto the same datastores. This is especially important where workloads differ, such as OLAP and OLTP workloads.
Reserve approximately 20 percent of available capacity on each datastore for VMFS overhead if you are planning to leverage advanced VMware features such as VM snapshots or vMotion.