Better to create LUNs for each individual guest or one giant LUN for all guests?

---

What is considered best practice for this?

Brett,
In the show, I typically use one LUN for all of my VMs. That is a pretty standard practice in production environments, but it is not required. There are pros and cons to both methods. For most people, running all of your VMs on the same LUN is ideal. It makes clustering easier, management and monitoring is simplified and the VMs don't know the difference. However, there are some cases where you will not want to run the VMs on the same LUN. For example:

• If you are running Hyper-V on Windows Server 2008 (not R2). The original version of Hyper-V could not fail over an individual VM on a shared LUN. Instead, if one VM failed over, all of the VMs on that LUN had to fail over.
• If you have heavy disk I/O applications. Database and Email server application can generate a lot of disk I/O which can degrade the performance of other VMs running on the same LUN. Assigning separate LUNs allows you to move the LUNs to different physical disks within the SAN to improve throughput. It also allows you to restrict LUN access to specific HBAs to reduce switch fabric contention.
• If you have non-clustered VMs mixed with clustered VMs. The clustered VMs will typically perform fine on the same LUN, but when you throw a stand-alone VM into the mix things can get messy. It is best to separate them out.
• If you are doing a multi-site cluster. When your VM host cluster extends beyond one subnet you will need to rely on your SAN to replicate your VM storage. Most SANs (but not all) perform better with several small LUNs as opposed to one big one.
  Those are a few scenarios where separate LUNs are more appropriate, but by and large you will use a single LUN for each VM Host cluster in your environment.
  Hope that helps, and sorry for the delay.
  Thanks for watching,
  Don Pezet
  Host, ITProTV

Thanks for the informative answer Don! That's what makes this site so great. Just want to say that I'm really enjoying the smaller segments of the newer content, makes it a lot easier to go through a couple of them in my spare time.
Thanks for the help.

In addition to what Don mentioned, in some situations you can also get better performance by using multiple LUNs as extents inside a single datastore.
For example, many (most? all?) SANs that have dual controllers will assign a LUN to a single controller and it will only switch over in the event of a failover. This means, assuming you only have a single LUN, that the secondary controller is idle all the time. If you created two LUNs and assigned one to each controller (the SAN would probably do this automatically), you can have each one active on one controller and passive on the other, thus utilizing both controllers actively. If the second LUN is added as an extent to the same datastore, both of the volumes would show up as a unified one to VMware and you would have the total combined space in that datastore.
While this certainly isn't the best way to optimize VMDK/datastore/LUN/controller assignment, it does provide a somewhat passive approach to get some better performance and utilization out of your existing hardware. Kind of a set it and forget it method.
Granted this only applies to dual-controller SANs where there would be some benefit. With a single controller, there isn't a whole lot of performance benefit from creating separate LUNs for the same storage AFAIK.

It really is mostly based on personal preference minus the few key points brought up. I am a VMware VCP 3, 4 and 5 and have over 7 years experience as a VMware consultant at various partners. So I am jaded on a combination of old school and VMware based technology (as opposed to Xen or Hyper-V). But the rules I go by are:

1. Never use extents (or dynamic disks in MS's world). It is essentially a software-based RAID 0. You loose a LUN to an over-zealous admin trying to clean up and you lost the whole extent (well, to be accurate you lost a lot of data, but not all, but that's not a whole lot better)
2. Try not to mix workloads. I try to put disk intensive things like busy databases on their own LUN's and light workloads like domain controllers mixed on to larger LUN's. Even though most environments have a single SAN for multiple clusters, breaking out the heavy workloads still has advantages. One of the most important is that most SAN's these days do performance tracking and optimization per LUN. So that busy SQL DB can still get the SAN advantage if it is 1-to-1 DB to LUN. But if you busy that SQL server on a LUN with 10 other VM's of mixed loads, the other loads will mess up the SAN's performance numbers and the optimizations won't be as effective. It also gives you the flexability to move that LUN later on with less impact and the SAN based performance numbers of the business's main DB for their primary application can get you more money versus you struggling to figure out why your SAN seems to be performing badly.
3. Separate based on size needed. Large servers like file servers with TB or more of data get their own LUN. I'm not going to fight that space battle.
4. When in doubt, 750 GB is a good number. Leave an absolute minimum of 100 GB free for snapshots and logs.
5. Disaster Recovery considerations. As Don mentioned, don't forget to take into account SAN replication. Many SANs will do better with incremental replication than the software counterparts. So do your homework first but if your homework will take too much time or is inconclusive, default to using the SAN based replication. That is nearly always done per LUN which means dividing your VM storage into LUNs that will be replicated and LUNs that will not be replicated.

Hope that helps you somewhat too.