Read here as well

http://www.experts-exchange.com/Storage/Storage_Technology/Q_22410495.html

From HP StorageWorks Best Practice

http://h20219.www2.hp.com/ActiveAnswers/downloads/VMware3_StorageWorks_BestPractice.pdf

Page 7

General SAN connectivity
VMware Infrastructure 3 and HP StorageWorks storage combine to provide a robust solution for
consolidation, reliability, and disaster recovery. This section provides general guidelines for
connecting VMware Infrastructure 3 to an HP StorageWorks SAN.
• Ensure each LUN has the appropriate RAID level and storage characteristics for the VMs that will
use it.
• Carefully determine the number of VMs you can place on a single LUN in your particular
environment. Note that, with new VMware Infrastructure 3 capabilities such as iSCSI and NAS, this
determination has become even more complex.
While VMware Infrastructure 3 supports up to 100 VMs per LUN, 32 VMs per LUN may often be
acceptable. However, HP recommends being more conservative and using 8 - 10 VMs per LUN.
In a NAS or iSCSI environment, HP recommends using 8 - 16 VMs per LUN.
If your VMs are not heavily impacting I/O, you may be able to exceed the conservative
recommendations above.
• To optimize array performance, spread I/O loads over the available paths to the storage.
• HP suggests configuring one Virtual Mirror File System (VMFS) volume per LUN. With VMFS-3 you
no longer have to set accessibility.
• In an environment with HP BladeSystem servers, a shared diagnostic partition is appropriate.
• Local SCSI controllers and Fibre Channel HBAs can be allocated to the VMkernel. However, it may
be preferable to use local RAID solutions for the Service Console and Fibre Channel HBAs for
external storage such as SANs.

Yes, I do agree entierly with Taxiwill. SAN Calculation for VMDK files is the best strategy and planning for your VMs. It's not only depends on the LUN Size and How many VMs per LUN? It depends on the Backup Strategy, Snapshot, logs. if they are stored to the same SAN Storage for Backing up to the Proxy Server and Tape Library. Blah Blah Blah.

Hello,

The math really does not change that much when you start to decide on how big a LUN you want..... The last calculation changes.

BTW, it was not 100 VMs per LUN in ESX 2 days it was 192 files per LUN.... + 32 Files for every Extent added. And the more Files on the LUN the slower the LUN went. If for example there were 6 files per VM (2 VMDK, 1 vMotion log file, 1 suspend file, 2 REDO files), you could not put more than 32 VMs per non 'extent'ed VMFS. And most people cut that in half even so. So 100s of VMs, never, but 100s of files, perhaps. You could perhaps have 192 VMDKs, but that does not necessarily translate to 100s of VMs.... At least I never once suggested more than 16 VMs per LUN even in v2 days.

For ESX v3, to calculate the size of a LUN based on a count of VMs, reverse the algorithm mentioned previously some:

Size of VM * # of VMs / 0.8 = Size of LUN required

Assume a 54.15GB VM, and 16 VMs.... = 1083 GBs or 1.083TBs of LUN space required.

Remember you want to fill a LUN no more than 80% just in case.

Also, it is often much better to have several smaller LUNs than one massive LUN. This will help with alleviate SCSI Reservation Conflicts. These conflicts are often what dictates the LUN count more than anything else. It depends on the storage used as well.


Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354, As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization