Controlling Lab Management VM Placement Policy
Lab Management is part of Visual Studio 2010 and it’s a great way to virtualize your test laboratory. In a simplistic way, we can say it allows you to test your applications without having to have a multitude of physical machines and different installations (multiple OS versions, multiple languages, multiple browsers. Whatever matrix of configurations you have to test your applications in).
It does this by allowing your to virtualize your environments in an easy way. Specially it allows your testers to easily launch virtualized test environments without having to have knowledge of virtualization (not only launch but also self provision), your lab administrators to easily provisions new environments based on VM templates. It also reduces the gap between developers and testers since when tests are being executed data can be automatically recorded (Intellitrace, video, event log events,etc,etc) and attached to a bug for easier reproduction of issues.
It also fully integrates the testing activities into your development practices, since it is very easy to automatically deploy an application into a fresh VM from your build process or even run automated functional UI tests automatically.
By I digress, today I merely wanted to show you a little “trick” for configuring your lab management to allow you to deploy more machines then your hyper-V can theoretically hold.
Lab managements deploys your virtual machines into the hosts that you have configured on your System Center Virtual Machine Manager (SCVMM), in fact it can also support multiple hosts and multiple group of hosts.
When you are provisioning environments on your lab, after defining the VM(s) that compose your environment (you can have as many environments as you want. An environment represents a set of machines eg: Web Server, Database Server,…) you have to deploy them before it can be used.
The act of deploying a environment means lab management is going to provision the environment by creating the actual VMs on a host (or more).
When you deploy an environment, lab management scorches your Hyper-V hosts (in the group) to see which one has enough resources to host your VMs. It can deploy your environment across more than one host (unless your require network isolation which mandates that the entire environment needs to be hosted on a single host).
The VMs needs two kind of resources. Memory and Disk. In order to deploy an environment you need an host that has sufficient memory and sufficient disk space. Disk space is easy to figure it out, but what does mean mean sufficient memory?
By default sufficient memory means: The memory the machine has minus the memory reserved for the virtual machines already deployed (either they are running or not) is bigger than the memory for all VMs of the environment being deployed.
This means that if you have environments which are rarely running they are accounted for and this can prevent you to deploy new environments even if your machine has enough resources to run a given environment,
This is called the Conservative Placement Policy and it basically assumes that all your deployed environments need to be running all the time (so in order to have more environments you may need to free up space by removing environments)
If on the other hand you want to have multiple environments and you don’t need to be running all of them at the same time and you can afford to stop/start them when you need them, it is perfectly fine if you over allocate the required VM over your physical resources (or you are using Hyper-V SP1 Dynamic memory feature). Lab management supports a policy that only considers memory occupied by running VMs at deployment time.
This would mean you want to have an aggressive placement policy.
By default lab management is configured in Conservative mode (on a host group by host group basis)
You can configure the placement policy on a host group by using tfsconfig.exe lab command (located on %programfiles%Microsoft Team Foundation Server 2010Tools)
For example:
TfsConfig.exe lab /hostgroup /CollectionName:
Possible values for policy: Aggressive or Conservative
You can easily spot an host group configured with conservative policy when you try to deploy an environment and are presented with the error: