Search code examples
visual-studio-2015azure-devopsvisual-studio-2017msloadtest

Unable to find free machine on self-provisioned load test rig


We have recently been performing load testing as part of a build(using the Cloud Load Test build task) using a self-provisioned load testing rig deployed using the following quick start template -

https://github.com/Azure/azure-quickstart-templates/tree/master/101-vsts-cloudloadtest-rig

This has been working well for us, but something seems to have changed and this process no longer works. When the load test task starts we now get the following error:

2017-04-24T14:32:07.4831251Z [Message]This load test was run using self-provisioned rig 'default'. No virtual-user minutes (VUMs) will be charged for this run.
2017-04-24T14:32:07.4881254Z ##[error]Microsoft.PowerShell.Commands.WriteErrorException: Test run could not be started using the self-provisioned rig 0ebc4aad-33b2-495e-a75a-213d4607976b. Number of free machines available in the rig are less than the required number. (Requested – 1, Available - 0, In-Use – 0, Offline – 3).

Using the ManageVSTSCloudLoadAgent.ps1 script

https://blogs.msdn.microsoft.com/visualstudioalm/2016/08/23/testing-privateintranet-applications-using-cloud-based-load-testing/

I can see that there is an agent group called "LoadTesting" with my two provisioned VM's in it, which shows them both as Free. However the GUID for this LoadTesting group does not match the one in the error message that the build task is attempting to use. According to the script there is only one rig available so I dont know where the cloud task is getting this other one from.

How can I change the task to use the correct group? Or change the 'LoadTesting" group to be the default?

I can't find anywhere within the load test definitions or through the team services site where I can make changes to to which rig it uses.


Solution

  • Problem solved - No idea how this was working before, but the solution was to add the following context parameters to all of our load tests.

    This is actually specified on the link I posted in my question, but had been overlooked due to them having worked before.

    Context parameter name – UseStaticLoadAgents
    Context parameter value – true
    Context parameter name – StaticAgentsGroupName
    Context parameter value – <name of the agent group>