I recently responded to someone who was considering placing all of their VHDs onto one huge storage volume.
This might be easy for storage management and for backup management. But you have to consider the ancillary impacts that this might have on the overall environment.
The greatest impact will be the impact that each VM has upon another VM.
This is where we need to h ave a full understanding of all of the components involved in our virtualization infrastructure and how all of those components interact and affect each other.
Here is the statement that began the idea for putting this to blog:
"We were hoping to create a "big" LUN, store all our Hyper-V Guests on that LUN, assign the LUN to several HOSTS, and access the Guests that way."
Now, the response:
That is all fine, good, and noble - but you may want to reconsider.
Even VMware has had the recommendation (for a great number of years now) of no more than 10 VMs per LUN (they consider this a 'rule of thumb' that is taught in class).
Why? Disk IO.
You have to balance the disk IO demands of the VMs stored on the LUNs.
If you have VMs with a bunch of disk IO all happening at the same time they end up impacting each other.
For example - you always split out your SQL databases from the temp log, from the OS - for the same reason.
In this case you have different considerations - VM1 will impact VM2.
An easy test you can do at home:
With many VMs on a single LUN, boot one and wait for Integration Services to report some data from within the VM (Integration Services loads late in the stack so it is a good measure that the VM is nearly done booting).
Be sure to time it.
Now, repeat the test, this time with 4 VMs all at once.
Don't stop timing until all four are up, then get your average time to boot.
All that disk reading and page file building created massive disk IO.
Just something to think about as you plan your infrastructure.