Steve,
That's really an ESX question, not storage.
Using FC, the volume design with be based on how locks are implemented in VMFS. VMWare do offer best practice numbers which, along with your VMDK sizes, will determine the optimum size of your volumes.
When we used FC, I think we aimed for 12VM's per store, and 150GB vols.
You'll obviously get potentially better dedup savings on larger volumes. Have you considered using NFS rather than FC (which uses it's own locking mechanism so the same constraints do not apply)?
Having said all that, I think SMVI generally works better with non-NFS stores; we're still having occasional issues due to NFS related issues.
Darren
On 05/03/2009 18:44, "steve klise" klises@caminomedical.org wrote:
I was always under the impression you wanted to put as many disks into an aggr, then setup the volumes inside the aggr.
Here is what we are doing, and I am just trying to see what others are doing, best practices, etc.
We have an AGGR that we use for VMware sitting on a 6030 running 7.2.4 FCP. The aggr is ~ 9TB or so, usable and we have 1 volume that is ~ 5TB or so. We do not currenlty use SMVI (waiting for the budget to open) :) but we will use SMVI and hopefully snapmirror over to another filer. All VM's are windows (for the most part) The primary storage is still on 7.2.4, so no dedupe, or thin provisioning until we upgrade to 7.3.2 sometime this year. This is coming btw to a store near you...
Pros/cons to creating smaller/bigger volumes: potentially easier to snapmirror less dedupe % if we create smaller volumes (less vm's, less dedupe)
Is there anything wrong with creating 1 volume to 1 aggr and grow the volume to 80%? Am I missing something here?
We are thinking of reducing our snap reserve as well.
Yes, I have read the vmware best practices doc. VERY GOOD BTW.
Thanks in advance