I was at a Dell EqualLogic training event and the speaker threw out the idea that it may not be a bad idea to create a single datastore to house a single VM rather than making a large datastore and putting several VMs on it. His reasoning was that a 1:1 ratio of VMs to datastores was a better option for managing snapshots created by Dell's Host Integration Toolkit Auto Snapshot Manager. He also threw out the qualifier that this is most beneficial for high-value VMs and not necessarily every VM you have.

The only reason I'm aware of why you wouldn't want to do this is because each datastore that vCenter has to scan adds to the total amount of time it takes to scan your SAN.


Well, it works in their case because for a normal VM snapshot, you need to keep extra space free on the datastore to house the data difference between the snapshot and the base; with their tools, it has the storage handle that instead. Not sure if it's snapshotting the whole LUN in the storage when it does this - if that is the case, then that would explain the benefit to splitting the VMs to different datastores.

There's also something to be said for the traditional argument for fewer VMs per data store: SCSI locking. With too many VMs on one store, their IO locks will step on each other.

The downside, of course, being the pain of managing all of this. Add a new disk for the VM? Gotta storage vMotion stuff around to make room. Expand a disk? Same thing. Migrate to new storage? You're provisioning a whole lot of new LUNs. It's certainly a whole lot simpler from a management perspective to use big bucket datastores.

  • Yes, you seem to understand the situation well. With regards to expanding a disk would it not work to expand the LUN then grow the VMDK to fit the LUN's new size? – Chris76786777 Sep 15 '11 at 19:19
  • +1 on the management part, I think I cried a little when thinking of how many LUNs I'd have to take care of. :( I mean the guy is going to talk about micro-management and then sell you an EqualLogic, a device that arguably takes a decent hit to its performance/cost ratio so that you don't have to micro-manage. – StrangeWill Sep 15 '11 at 20:28

People are currently running VM densities of 20-40 VMs per datastore and not having IO problems, to address one of your concerens. I play ultra cautious, I feel, and keep ~10-15 and have no IO latency/CPU ready problems. VMware is moving towards larger datastores to make fore easier management so really this is working in direct opposition to where the virtual environment is going. With vSphere5 you can have very large datastores so snapshots filling a DS shouldn't concern you because 1) You have more space available and more time before an out of space condition occurs 2) With SDRS enabled you can either have the VM automatically migrate to the next best DS based on IO/space projected 24 hours out.

Also snapshots shouldn't be kept open for long periods of time and are not a valid backup/recovery option. How many times have you had a snapshot fill a datastore and have 'bad things' happen? You can chip away at this possible blowup, if you don't use SDRS, and not use thin prov on a disk you plan to keep snaps open on for extended time.


If you plan to run more VMs than the number of LUNs per host shown in the Configuration Maximums doc for your version of VMware you wouldn't want to have one LUN per VM. For vSphere 4.1 that is 256. For ESX 3.5 it is only 62 (as I learnt yesterday when I couldn't see some new LUNs I was trying to attach).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.