Hi Tom, you could certainly house multiple VMs per volume - typical recommendation is to start out small, monitor performance when VMs are underload, and progressively add more VMs. One consideration to have in mind - if you have VMs that need regular backup (i.e., SQL, Exchange), then it'd be a good idea to keep the # of VMs relatively small (5-10), if you use VMDK. Reason is because the VMware VSS snapshot needs to be taken for each VM in the datastore prior to Nimble volume level snapshot.
If you choose to do in-guest attached iSCSI access, then you'd need one volume per VM.
Hope this helps.
I initially started using our CS220 with several (many) VMs on one 2 TB LUN. There weren't any specific performance issues that I could see, but it was definitely a hassle to manage. A lot of the VMs were "Tier 1" production and I couldn't shut them down to move them. Thankfully we upgraded to Vsphere 5.1 and I used storage Vmotion to move each VM (live) to its own LUN.
I'm not an expert, but I just find using one VM per LUN much cleaner and easier to keep straight in my small head.
As your environment grows, having one datastore per VM will become a nightmare to manage. The other consideration is the number of iSCSI connections that the array will have to support, especially if the number of vSphere hosts and iSCSI connections increases linearly.
I tend to group VMs on LUNs/datastores and have certain VM characteristics associated with each. For example, a small number of transactional application servers will reside on one LUN, perhaps with iSCSI RDMs to the guest with a volume collection snapping base VMDKs and data disks together. Having iSCSI RDMs for application data means we can snap using VSS natively which will provide better results than having to go through VM tools, and a more appropriate performance policy can be chosen. You can then scale out this approach, so have multiple smaller datastores with these types of VMs running. If we want to snap with vCentre integration, there's less of a load burden as there's only a few VMs having VMware snapshots taken.
For less transactional VMs, you can increase the size of the datastore and the grouping of VMs. So, DCs/NTP/File/Print/stateless apps which don't require quiescing can be snapped without vCentre integration which is ultimately kinder on all involved (VMs and storage).
Saying all that, there's nothing actually wrong with having a VM per datastore :-)
Currently I have individual VMs in their own volume and can confirm that there are benefits to doing it this way, but there are also drawbacks. We have two arrays and our production array replicates to the disaster recovery array. So far the biggest drawback pertains more towards the amount of labor involved in a disaster situation where we will have to manually connect all the volumes to the host machine and configure them appropriately for Round Robin (someone recently posted a VBscript here on Connect that helps automate this process), and then spin up the machines.
Even for a small environment, such as 20 VMs, you can see that there is a lot more work that you will have to do in a disaster scenario than if you minimize the number of volumes. I am currently contemplating grouping VMs into fewer volumes and am working with my local Nimble Engineer and VMware afficianodo to figure everything out.