Host Allocation

When reserving a timeslot, the system calculates the availability of all the requested hosts and, in the case of a Performance Test timeslot, Vusers. A timeslot can be reserved successfully only if all of the requested hosts can be allocated, and in the case of a Performance Test timeslot, if all the requested Vusers are available.

Performance Testing. You must request at least one Controller and one Load Generator. If you have linked a test to the timeslot, the hosts and Vusers defined in the test are automatically requested for the timeslot.

Hosts are allocated as follows:

  • A specific host defined in the Testing Host grid can be allocated for testing as long as it is available and operational. A specific host can be allocated for maintenance even if it is non-operational.

    Note: You can make specific hosts available only to specific users. For details, see the ALM Lab Management Guide: .

  • An Automatch host is matched up with a specific host that has the requested properties. A host is allocated after the following criteria have been checked:

    • Lab Management and ALM create a list of all the hosts in the host pool of the project that are operational and available, and that match the requested properties of the automatch host.

    • From this list of candidate hosts, the system allocates the host that best fits the requested properties, taking into account the host priority, the number of pools the host belongs to, the purposes assigned to the host, and the host's attributes. The hosts are then allocated in such a way that other hosts with similar but also additional properties may still be available for allocation to other test executions.

    Note: You can block hosts from being included in the automatch selection. For details, see the ALM Lab Management Guide: .

It is important to note that many conditions and changes in the system can occur that can affect host allocation. At such times, the system attempts to optimize the overall resource usage by reshuffling the hosts that are available among the timeslots.

It is not always possible to shuffle the hosts appropriately. When this happens, a timeslot might become partially allocated, and thus invalid. As soon as the requested host becomes available again or another host can be allocated instead, the timeslot becomes valid again.

Example:  

  • If an allocated host becomes non-operational, then the system will try to find another host to replace the non-operational host.
  • In a version-enabled project, if a test is linked to an automatic timeslot and is checked out, modified, and checked in again before the timeslot starts, the timeslot recalculates the availability of the updated resources.

To view an example of how hosts are allocated, and how they are reshuffled when necessary, see Example of Allocating and Reshuffling Hosts.

Parent topic: Reserving Timeslots Overview