I've talked to a lot of customers lately who are wrestling with their virtual infrastructure, especially with storage. Trying to chase performance issues is like sorting out a bowl of spaghetti because its hard to know where your storage is coming from, or who you are sharing it with.
For example, what if you have a performance issue on a VM and suspected the disk? How would you diagnose the issue and decide how to fix it? First, you need to know if you have contention issue by looking to see what VMs are on the same datastore, then drill down to LUN, and then find the Raid Group and see what other LUNs are on it.
In the VMware Logical Mapping report, Profiler can do the leg work for you with drill downs to the details. You can access the Logical Mapping report at any level of virtual infrastructure (VC, DC, Cluster, ESX, VM) by clicking the storage tab, then clicking the Logical Mapping link. The report correlates VMWare data (ESX, Datastore, VM) to the Array data (LUN, Array) for fibre channel, iSCSI or NFS connectivity.
The VM level Logical Mapping report for VM "D3TMPVT4" tells us it lives on Datastore LSI04_FIB_DS22_Migrate_Dev (VM > Storage > Logical Mapping).
The Cluster level Logical Mapping report (below) tells us there are 10 other VM's on that datastore.
You can look at the Datastore and drill down to the individual VMs to review contention, or jump across to the Array and LUN, with further drill downs to the RAID group to reivew LUN performance.
In this case, if we run a ranking report for the VMs on this datastore (Quick Reports > VMware VM > Disk Performance), you can see one VM is much busier than the rest.
At this point, your options are to diagnose the problem on QA-test box, or move the VM to another Datastore. The logical mapping reports shows the other datastores available in the infrastructure (and the available space), and you could review the performance of these both on the virtual side and the Array side. Looking at the performance of the LUNs on the array:
We can see that LUN "Migrate1" is a lot less volatile from a performance perspective, and has the required amount of space available 10GB.
So you now decide which way to solve your disk issue, either further diagnosis of the offending VM or migrate your VM to another datastore.