Allocate hosts

This topic describes host allocation and provides an example of how hosts are allocated and reshuffled among timeslots.

In this topic:

Host allocation overview

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.

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 Manage hosts.

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

  • A list of candidate hosts is created. This list contains all 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 runs.

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.

Back to top

Allocate and reshuffle hosts example

This section provides an example of how hosts are allocated and reshuffled among timeslots.

Overview

There are many factors that can affect the allocation of hosts among timeslots.

Consider the following scenarios which illustrate how hosts are allocated among performance timeslots and how changes in the available testing hosts can affect the host allocation.

LoadRunner Enterprise attempts to optimize the overall resource usage by reshuffling the hosts that are available among the timeslots.

Available host pool

Assume the following hosts belong to the host pool of the project:

Host	Properties
Host1	Controller
Host2	Controller + Load Generator
Host3	Load Generator with the following property: Priority = 1_Lowest
Host4	Load Generator with the following properties: Citrix. The host can run scripts based on Citrix protocols. Priority = 9_Highest

07:00 am: John reserves a timeslot

John reserves the following timeslot at 07:00 am:

Timeslot	Reserved at	Reserved for	Requested Resources, Properties
TS1	07:00	08:00am - 10:00am	1 Controller, Any 1 Load Generator, Any

John submits the request. The system allocates Host1 as the Controller, leaving Host2 available to serve as either load generator or Controller in other timeslots. Additionally, the system allocates Host4 as the load generator, because it has higher priority than both Host2 and Host3. The following hosts are allocated successfully:

Requested Hosts	Allocated Hosts
1 Controller, Any	Host1
1 Load Generator, Any	Host4

07:30 am: Sue submits a timeslot reservation

Sue submits the following timeslot reservation at 07:30 am:

Timeslot	Reserved at	Reserved for	Requested Resources, Properties
TS2	07:30	09:00am - 11:00am Autostart	1 Controller, Any 1 Load Generator, Citrix

Because Host4 is the only Citrix load generator, the system checks if it can allocate a different load generator to John's timeslot so that Host4 can be allocated to Sue's timeslot instead.

Hosts are reshuffled to accommodate Sue's request

The necessary hosts are available, so the following reshuffle occurs:

• Host3 is allocated to John; Host4 is allocated to Sue

• John's Controller, Host1 remains allocated to John; Host2, also a Controller, (not yet allocated), is allocated to Sue

Sue successfully submits the request. The new host allocation looks as follows:

Timeslot	Requested Hosts	Allocated Hosts
TS1	1 Controller, Any 1 Load Generator, Any	Host1 Host3 (replaced Host4)
TS2	1 Controller, Any 1 Load Generator, Citrix	Host2 Host4

07:45 am: Peter reserves a timeslot

Peter reserves the following timeslot at 07:45 am:

Timeslot	Reserved at	Reserved for	Requested Resources, Properties
TS3	07:45	10:00am - 12:00pm	1 Controller, Host2 1 Load Generator, Any

Peter is specifically requesting Host2 for his Controller, and any load generator. The system checks if the requested hosts can be allocated, taking into consideration requests and timing of the other timeslots:

• To allocate Host2 to Peter's timeslot, it must be available by 10:00.

• Sue is willing to have any Controller.

• John's timeslot ends at 10:00 and frees resources.

Hosts are reshuffled to accommodate Peter's request

The following reshuffle occurs so that all the timeslots can be accommodated:

• Sue's timeslot gives up Host2, and is allocated Host1 instead; Host4 (Citrix) remains allocated to Sue's timeslot

• Host2 is allocated to John's timeslot; Host3 remains allocated to John's timeslot

• Host2 and Host3 can then be allocated to Peter's timeslot because John's timeslot finishes by 10:00 when Peter's starts.

Peter successfully submits his request. The new host allocation looks as follows:

Timeslot	Requested Hosts	Allocated Hosts
TS1	1 Controller, Any 1 Load Generator, Any	Host2 Host3
TS2	1 Controller, Any 1 Load Generator, Citrix	Host1 Host4
TS3	1 Controller, Host2 1 Load Generator, Any	Host2 Host3

Hosts are reshuffled as they become available

Now let's say at 07:55 Host2 becomes non-operational. As a result, TS1 takes back Host1, and starts at 08:00. It follows from the information above, that TS2 and TS3 both become invalid as their resources have become partially allocated.

Then, at 09:05, Host2 becomes operational again. It is allocated to TS2, and TS2 starts, though five minutes late, but still during the specified retries period. (For details about configuring retries, see Manage projects.)

At 11:00, TS3 remains invalid (partially allocated) and is unable to start because Host2 is still being used by TS2.

Back to top

See also:

• Design a test
• Create test assets
• Reserve timeslots