We are laying out for Exchange and have planned for a dedicated VMFS and LUN for each of the databases. The VM files and boot luns are on other volumes. May we fill the entire datastore with a single vmdk, or is there a reason to leave free space on the dedicated disks? If so, how much?
Thanks!
I don't see a reason to not use all of the datastore space. If you take snapshots they will be on the disk where the .vmx file resides. Sorry...time to read more documentation.
Hi,
Best practice is to always have 20% free space.Becoz space is needed if you use snapshots. Delta file are stored in the same location as the guest disk files.
May we fill the entire datastore with a single vmdk
If you really want to utilise the space with a single vmdk with single datastore then best way is to attached LUN as a RDM disk to a VM and sync that LUN at storage level for backup purpose.
clarkwayne that was true with esxi4 and 3
with esxi 5 snaps are always with the base disk.
so you would want to leave 10-25% free if you would like snapshots
snapshot delta disks are now stored in the same directory as the base disk.
BigDaddy1 wrote:
We are laying out for Exchange and have planned for a dedicated VMFS and LUN for each of the databases. The VM files and boot luns are on other volumes. May we fill the entire datastore with a single vmdk, or is there a reason to leave free space on the dedicated disks? If so, how much?
Thanks!
I can see your logic.
It's easy to feel you've got no reason to leave capacity for snapshots and growth when you've allocated a dedicated LUN.
If nothing else though, you will need to leave free space for the volume journal:
In reality, I suspect you are making life difficult for yourself with no gain with a dedicated LUN for each database.
The issue is that the luns were laid out to exactly 1 or 2 TB for 1 and 2 TB virtual disks without leaving any additional space.
BigDaddy1 wrote:
The issue is that the luns were laid out to exactly 1 or 2 TB for 1 and 2 TB virtual disks without leaving any additional space.
I would suggest you are better off fixing that now by slightly shrinking those virtual disks, than later.