Geeks With Blogs


Dylan Smith ALM / Architecture / TFS

I was recently helping a client do some capacity planning for an upcoming TFS Lab Management deployment. I was being kind of lazy so I just sent them over the Capacity Planning Calculator spreadsheet that the great folks in the ALM Ranger team released with their LM guidance:

Less than a day later and they're calling me up telling me the spreadsheet doesn’t make any sense. So I fire it up, punch in some numbers for a fictional team, and sure enough the numbers it’s giving me don’t make any sense to me either. This blog post is my attempt to point out what I *think* are mistakes in the spreadsheet. I also created a modified version of the Capacity Planning Calculator that does the calculations I think are correct.

So first here’s my fictional scenario, and we’ll do the math by hand:


Let’s assume we have 3 Projects with the following team sizes:

  • P1 – 5 people
  • P2 – 3 people
  • P3 – 7 people

Each project will have 2 environments, a consolidated environment with all components on 1 VM, and a split environment with separate Web and DB Servers. Let’s assume that the Web/DB/Combined servers are each slightly different for each project so they can’t share VM or Environment templates [in the real world you would most likely be able to use your Web and DB VM Templates across most if not all environments, since a Web Server image is pretty much always the same].

  • VM1 – P1 Web
  • VM2 – P1 DB
  • VM3 – P1 Consolidated
  • VM4 – P2 Web
  • VM5 – P2 DB
  • VM6 – P2 Consolidated
  • VM7 – P3 Web
  • VM8 – P3 DB
  • VM9 – P3 Consolidated


  • E1 – P1 Consolidated (VM3)
  • E2 – P1 Web (VM1) + P1 DB (VM2)
  • E3 – P2 Consolidated (VM6)
  • E4 – P2 Web (VM4) + P2 DB (VM5)
  • E5 – P3 Consolidated (VM9)
  • E6 – P3 Web (VM7) + P3 DB (VM8)

Every team member will have a personal instance of the consolidated environment, the TFS Build will have its own consolidated environment, and we’ll say there are 2 instances of the split environment for each project (UAT, Demo, Staging, whatever).

All VM’s will be allocated 1 CPU. The Web Servers will get 2GB RAM, DB Servers 4GB, and Consolidated Servers 3GB.

Every VM will use 60GB disk, and every environment instance will have on average 4 snapshots.


First lets calculate the host requirements:

  • P1
    • 5 Personal (5xE1 = 5xVM3)
    • 1 Build (1xE1 = 1xVM3)
    • 2 Other (2xE2 = 2xVM1 + 2xVM2)
  • P1 Totals = 6xVM3 + 2xVM1 + 2xVM2


  • P2
    • 3 Personal (3xE3 = 3xVM6)
    • 1 Build (1xE3 = 1xVM6)
    • 2 Other (2xE4 = 2xVM4 + 2xVM5)
  • P2 Totals = 4xVM6 + 2xVM4 + 2xVM5


  • P3
    • 7 Personal (7xE5 = 7xVM9)
    • 1 Build (1xE5 = 1xVM9
    • 2 Other (2xE6 = 2xVM7 + 2xVM8)
  • P3 Totals = 8xVM9 + 2xVM7 + 2xVM8


  • Total = 18 Consolidated VM + 6 Web VM + 6 DB VM = 30 VM’s
  • Total RAM = 18x3GB + 6x2GB + 6x4GB = 90GB
  • Total CPU = 30
  • Total Disk = 60GB x 30 = 1800GB


The capacity planning calculator uses a rule of thumb of 10% additional disk for each snapshot. So we need to add 40% to our number resulting in 2520GB.

We should also account for the disk required to persist the RAM from each VM in case they were all paused, so that adds 90GB disk bringing us to 2610GB.

The capacity planning calculator uses some rule of thumbs for how much CPU/RAM/Disk buffer you should budget for. 10% CPU, 10% RAM, 20% Disk. This brings our totals to:

  • Host CPU: 33
  • Host RAM: 99 GB
  • Host Disk: 3132 GB


The library should have enough disk to store all VM templates, all Environment Templates, and a copy of each running environment to support team members storing them to the library. (Note: In reality you probably wouldn’t need/want enough library disk to store all running environments to it, but I prefer to do my capacity planning math for the worst case scenario then tweak from there.)

We have 9 VM templates at 60GB each = 540 GB

We have 6 Environment templates containing 9 VM templates at 60 GB each = 540 GB

*** I’m not sure if the Environment templates actually require their own storage, or if an environment template is a just some config data that says which VM templates go together to make an environment template (and as I mentioned at the start, I’m by nature a pretty lazy guy so I’m not going to check right now). I think it’s the latter, but I’ll do my math as if it’s the former to be safe.

From above we know that all 30 VM’s disk + snapshot = 2520 GB

If we assume the same disk space buffer of 20% this bring us to 4320 GB.

  • Library Disk: 4320 GB




When I punch these numbers into the Capacity Planning Calculator I get very different results (specifically disk) of:

  • Host CPU: 33
  • Host RAM: 99 GB
  • Host Disk: 12247 GB
  • Library Disk: 1134 GB


Here is a copy of the original spreadsheet with these results.


Here is an updated version of the spreadsheet with what I believe to be the correct formulas.


If I remember correctly, the main changes I made were the way it calculates host storage required for snapshots, and added library storage space to allow storing running environments to the library.

Posted on Thursday, October 13, 2011 4:34 PM | Back to top

Comments on this post: Lab Management Capacity Planning

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Dylan Smith | Powered by: