Timeslots can be reserved for immediate use or they can be reserved in advance for future use. This section describes these two types of timeslot reservations.
Scheduling an immediate timeslot reserves resources for a task at hand.
Administration: If you want to perform administrative tasks on particular hosts, such as installing patches, when you start the task—and provided that the hosts are currently available—ALM automatically reserves the requested hosts in a maintenance timeslot so that the hosts cannot be used for any other purpose for the duration of your task.
Testing: When you execute a test using server-side execution (such as from within a functional test set), before the test starts to run, you specify the time and resources you need for the test. ALM checks if the required resources are currently available for the required amount of time. If the resources are not available, you cannot run the test at that time and need to try again later.
When running a performance test, ALM checks if the required number of hosts and Vusers exceeds the license/project limits. If the limits are exceeded, you will not be able to run the test.
When running a functional test set which includes a VAPI-XP test instance, ALM checks if there is a currently available testing host with the VAPI-XP purpose assigned. If there is no VAPI-XP testing host, you will not be able to run the test.
Data Processing: When working with LoadRunner Enterprise projects, tasks such as test result analysis, SLA status publication, and trending are performed on a data processor host. ALM estimates how long a data processor host is needed for the task at hand. As soon as a data processor becomes available for this task, an immediate timeslot reservation is automatically made.
If you know which testing resources you need for running a test, or you know the hosts on which you need to perform maintenance, you can reserve the resources for your test in advance for a specified amount of time.
When reserving resources for a testing timeslot, there are three types of timeslot reservations:
- Functional Test Set. Enables you to reserve the resources needed for running a single functional test set containing several automatic test instances. The tests are executed consecutively.
- Performance Test. Enables you to reserve the resources needed for running a single instance of a performance test.
Build Verification Suite. Enables you to reserve the resources needed for running several functional test sets together with a single instance of a performance test with the purpose of checking the overall status of your build. The tests in the test set are executed consecutively, followed by the single performance test. This type of timeslot reservation enables you to integrate your system with Micro Focus Continuous Delivery Automation (CDA) for provisioning, deployment, and so on. For details, see Build Verification.
When reserving a testing timeslot, you can request either specific hosts or automatch hosts. That is, you can specify the exact hosts which will run your test or test set, and if those hosts are available, ALM reserves them for you. Alternatively, you can request automatch hosts, which allows ALM to allocate any available host with properties that match your selected criteria.
When you add a test instance to a test set in the Test Lab module, ALM automatically allocates automatch hosts to the test instance based on the test type. You can use the Test Lab module's Requested Hosts tab to change the testing host allocation before reserving the timeslot. Alternatively, you can change the allocation as part of the timeslot reservation.
For performance test timeslots, you must select at least one Controller and one load generator. For details, see the LoadRunner Enterprise documentation.
For functional test set and maintenance timeslots, you must select at least one host.
A timeslot can be reserved successfully only if all of the requested resources are available.
Tip: All users in your project can use the timeslot that you have reserved.
It is important to note that many conditions and changes in the system can affect host allocation, and can cause a shuffling around of the hosts. For more details about host allocation and examples of resource shuffling, see Host Allocation.