Storage Design is an important concept in virtualized environments.  You must be concerned about both the logical layout of your LUNs and the actual design and capabilities of of your array.  Let's talk briefly about issues you should consider when designing storage for a virtual environment.

How should I partition my VMs over LUNs?

One good way is to partition VMs is by IO type.  You can tier that with however much granularity you like, but the principle is to group VMs together by IO requirements with fewer VMs per LUN as the requirements increase.

How many VMs per LUN?

That depends almost entirely on the IO requirements of the VMs.  A few good numbers to keep in mind: most iSCSI volumes have a command queue with 32 slots.  That means that a given LUN cannot have more than 32 commands outstanding at one time.  You should also factor in the throughput requirements of your VMs and what your array can handle.  This is where VMWare's performance monitoring and reporting features really come into their own.  Important metrics include the read and write latency and command queue depth.

What kind of storage do I need?

In my opinion, storage is the heart of any virtual environment.  Without top notch, redundant, fast storage your virtualization project will die unborn.  That doesn't mean you have to go out and by a Dell EqualLogic array (although, I do love those things) or some other vendor solution.  You can build linux-based server that exports iSCSI targets for a fraction of the price and, if you know what you are doing, achieve comparable performance.

What kind of backup considerations are there?

Tons. What will you backup to?  How often? 

How many LUNs should I attach to a given server?

This is an interesting question.  ESX rescans it's LUNs every 5 minutes.  As you increase the number of servers that are attached to a given LUN you increase the amount of administrative overhead on that LUN.  On the other side of that, you cannot have universal vmotion without haveing a full mesh of storage connections.  What to do?

How can I enable vmotion if I don't have universal storage access?

Use Transfer Volumes between clusters.  Given clusters have full mesh storage interconnections, but the only storage in common between clusters is a single volume.  That volume is big enough to house VMs as they are storage vmotioned between clusters.  For more on this concept see http://www.yellow-bricks.com/2010/02/05/storage-masking/.