how to size vmware vols/luns

[#1]

I created a volume and then created a lun using all space. from the best practice doc, it says use one lun per volume.

but when i create a lun to use all volume space I get warning errors in ops mgr.

how should I size my volume/lun for vmware?

[#2]

You alerts are based off of percentage of volume space used.  Therefore, you either need to stop using space reserve and thin provision the LUN, but make sure you take any fractional reserve into account.  Or put your volume at x% bigger than your LUN to ensure you don't see the alerts.

If you are doing one LUN per volume, with guaranteed volume sizes, I would turn the space reservation off on the LUN, but we don't use fractional reserve either...

- Scott

[#3]

It's a bit complex question, as you can use so many different approaches.

Personally I like volumes to be thinly provisioned - you can make e.g. each volume 2x-3x times bigger than the LUN (depending whether you reduce fractional reserve to 0%, or keep it at 100%) & then either make your LUNs space reserved, or non space reserved (the latter would mean full thin provisioning, end to end).

Regards,
Radek

[#4]

Tdubb,

Are you going to be taking snapshots of the LUN? If so, you need to allocate additional space in the volume to accomodate. So if you have a 50 GB vol and create a 50 GB LUN, you will have no space for the snap. The additional space really takes in a few factors, such as thin provisioning and how many snapshots you plan to retain. My general rule of thumb is 2.5x the LUN size for the volume. So if I have a 50 GB LUN my vol is going to be 125 GB to accomodate for the snapshots and retention.

Wes

[#5]

wouldnt this be a lot of wasted space on the filer? 2.5x? Its good to have space reserved but most of the time I would not be taking any snapshots. Its nice to have them when I need to recover something but dont want to waste too much space for snapshots.

i really like the idea of disabling space reservation, that way the host and storage space availability looks the same and its consistent.  maybe I can leave fractional reserve at 20% or less for the snapshots.

also what does the -s option do for creating volumes?

-s none, volume, file

thanks

[#6]

wouldnt this be a lot of wasted space on the filer? 2.5x?

That's why I like thin provisioning. 2.5x factor probably comes from fractional reserve being kept at 100% - current official best practice recommends setting it to 0% (with a lot of caveats)

what does the -s option do for creating volumes?
-s none, volume, file

none -> thin provisioning, i.e. only actually used space is taken from the aggregate

volume -> fat provisioning, i.e. full space reserved upfront from the aggregate

file -> never use

[#7]

should i do a fat volume and a thin lun on a fat volume? I am more concerned about what actual lun usage are from both storage and host locations

[#8]

Are these going to be production VMs? If development then I would say no snapshots is fine. But if production. . .taking no snapshots is just asking to generate a resumé. 2.5x the LUN size is indeed excessive. Thin provisioning IS the way to go assuming you have the daily time to manage and make sure you are not approaching a situation where you are over committed. All this also depends on your daily duties and the amount of VMs you are running. We are approaching 200 VMs in our enviroment and my duties are such that I cannot currently devote the time every day to ensure that I will have no LUNs go offline and thus bring down a datastore.

I agree with Radek that a space guaranteed volume and thin provisioning the LUN is a safer way to go, but you still have to make sure you dont fill the volume as that datastore will go offline.

Wes

[#9]

Actually I was suggesting thin provisioning of a volume & then either thin provisioning of a LUN, or keeping LUN fat - in both cases volume is thin though.

It really doesn't make any good with just one LUN in a volume, if the volume is fat & LUN thin, as no savings will be seen in the containing aggregate anyway.

I am (vaguely) considering writing a blog post about thin provisioning, as the subjcect still seems to be confusing for many folks

Regards,

Radek