Getting the Right LUN Size: Storage for VDIs

On 23 January 2015 by Pete Petersen

Storage LUNs

Image source:

There have been numerous articles, forum threads, blog posts, and white papers around getting the LUN size right. While interviewing Citrix SEs, following forums, and reviewing white papers on this topic for a law firm as we embark on upgrading to XenDesktop 7.6, a Citrix SE recommended the following post.

After all the reading, this seems to be the most comprehensive post. The author links out to five more great reads and should be studied as part of this post.

As a bottom line, there are a few simple formulas that are helpful. But what is more helpful is to understand what needs to go into the calculations. Granted, the post was written in 2011 (now nearly four years old), but it all still holds true. Where you’ll need a new perspective is if you introduce some different types of storage, such as Atlantis USX or other RAM-based memory types. Those types of storage will require their own calculations as they become effectively host-based (or local) storage.

Knowing nothing else, you can use:

(VMs per LUN) x (Your Average VM Disk Size) + 30Gb VM swap + 15% of (VMs per LUN x Your Average VM Disk Size) = Calculated LUN size

or even simpler with nearly the same results:

Round((VMs per LUN) x (Average VM Disk Size) +20% (of VMs per LUN x Average Disk Dize)) [Rounded up to the nearest 25 GB]

The tricky part is coming up with the VMs per LUN number.

Machine Creation Services as Provisioning Tool

As it relates to Machine Creation Services, the VMs per LUN number in the studies, it seems to come down to somewhere between 10 and 30. Taking the conservative road, say 15, with an Average Disk Size of 30GB. we end up with a formula like this:

(15*30)+(0.2*15*30) = 540GB –> rounded up to the nearest 25GB = 550GB

Provisioning Services as Provisioning Tool

Provisioning Services is in some ways a little more complicated, but in other ways, the same. For the VMs per LUN number, we’ll continue to take the conservative road, 15, while using an Average Disk Size of 15GB for the WriteCache disk. The formula looks more like this:

(15*15)+(0.2*15*15) = 270GB –> rounded up to the nearest 25GB = 275GB

Now that being said, you will see the benefit of PVS RAM Cache, which will greatly reduce the IOPS to the LUN at all. In your own environment and testing, it will be worth measuring whether your conservative VMs per LUN number should be increased based on the amount of IOPS that happen to fall through to the disk.


For another perspective on why getting storage right is so important, see VDI Storage . The Secret Critical Component. Be sure to look through all the storage-related Trackback posts at the bottom as well.

Additional consideration:

Turbo Charging your IOPS with the new PVS Cache in RAM with Disk Overflow Feature!


Just this week (13 Jan 2016), the Citrix PVS development team were wondering why anyone would provision with PVS without using “Cache in RAM with Overflow to Disk,” or as they termed it, “CiRwOtD.” The indications are that there is better performance than with full Cache in RAM. Tests and charts to follow.