-
Notifications
You must be signed in to change notification settings - Fork 31
Set up Your Machine Pool
In this document, we will explain how to set up your own test lab with LNST and how to start using it for executing your tests. LNST uses machine pools for organizing machines available for testing, you can have several of these, normally you would represent a physical test lab with a separate machine pool. In this document we will walk you through creating such a machine pool from a single test lab.
Suppose we have the following lab configuration that we want to set up for LNST:
+-----------+ +-----------+ +-----------+
| Machine 1 | | Machine 2 | | Machine 3 |
+-----------+ +-----------+ +-----------+
| | |
A | B | C |
| | |
| +-----------+ |
+----------------| Machine 4 |----------------+
+-----------+
| | |
D | D | D |
| | |
+-----------+ D +-----------+
+----------------| Switch |----------| Machine 5 |
| +-----------+ +-----------+
D | | |
| D | | D
| +--+ +-------------------+
| | |
+-----------+ +-----------+ +-----------+
| Machine 6 | | Machine 7 | | Machine 8 |
+-----------+ +-----------+ +-----------+
There are eight (1-8) machines, one non-managed switch and four (A-D) network segments. We will use this example to guide you through the whole process.
To set up a test lab for use in LNST, you need to create a pool directory for your lab. This directory will contain configuration of all the machines in your lab. One machine per-file.
For our example we will create a directory called lab and populate it with one XML file for each machine. These files will contain machine configurations. The switch in the lab is not managed, so there
will be no configuration for it in the pool.
[admin@controller ~]$ cd lab/
[admin@controller ~/lab]$ ls -1
machine1.xml
machine2.xml
machine3.xml
machine4.xml
machine5.xml
machine6.xml
machine7.xml
machine8.xml
[admin@controller ~/lab]$ These XML files contain a root slavemachine tag of the respective machine, under which you describe the parameter of the machine and available interfaces. Here's an example configuration for machines 1 and 4:
<slavemachine>
<params>
<param name="hostname" value="192.168.100.10"/>
<param name="rpcport" value="9999"/>
</params>
<interfaces>
<eth label="A" id="1">
<params>
<param name="hwaddr" value="52:54:00:a7:32:15"/>
</params>
</eth>
</interfaces>
</slavemachine><slavemachine>
<params>
<param name="hostname" value="192.168.100.1"/>
</params>
<interfaces>
<eth id="1" label="A">
<params>
<param name="hwaddr" value="52:54:00:e4:75:16"/>
</params>
</eth>
<eth id="2" label="B">
<params>
<param name="hwaddr" value="52:54:00:91:01:9c"/>
</params>
</eth>
<eth id="3" label="C">
<params>
<param name="hwaddr" value="52:54:00:94:b7:32"/>
</params>
</eth>
<eth id="4" label="D">
<params>
<param name="hwaddr" value="52:54:00:f3:a1:2a"/>
</params>
</eth>
<eth id="5" label="D">
<params>
<param name="hwaddr" value="52:54:00:12:eb:07"/>
</params>
</eth>
<eth id="6" label="D">
<params>
<param name="hwaddr" value="52:54:00:78:dd:42"/>
</params>
</eth>
</interfaces>
</slavemachine>As you can see, there are two sections in a slavemachine config. The first section, <params>, contains
information about the machine itself, e.g. IP address or hostname, and any additonal information that can describe the machine. The parameter names are completely arbitrary and you specify any information you dem usefull, the only required parameter is the hostname parameter, which will be used to connect to the slave machine.
The other section contains information about physical devices that are available for testing. Each device must have a unique (with regards to the <interfaces> tag) ID string assigned (the id attribute). This is used by LNST for further reference to the device. Another important attribute is label, this attribute is mandatory. It gives the controller information about how the machines within the lab are connected to each other (interfaces that can talk to each other have the same label). It is then used to construct the lab topology. And finally as you can see from the example you can define additional parameters for the interfaces. The same rules apply about arbitrary names, only now the required parameter is hwaddr that is used to look up the interface on the slave machine.
When you have your pool directory set up and ready, you need to point LNST to its location. This is done
in the configuration file in ~/.lnst/lnst-ctl.conf. Here is an example of how it usually looks:
[environment]
mac_pool_range = 52:54:01:00:00:01 52:54:01:FF:FF:FF
rpcport = 9999
machine_pool_dirs += ./pool.d
test_tool_dirs += ./test_tools
test_module_dirs += ./test_modules
log_dir = ./LogsAll you need to do is to append the path to your new lab directory to the machine_pool_dirs option.
machine_pool_dirs += ./pool.d ~/labIf the file doesn't exist you can create it with the following content:
[environment]
machine_pool_dirs += ./pool.d ~/labWhen you have a working lab already set up to work with LNST, you can proceed directly to testing. The machine pools defined in your configuration files will be used automatically. LNST will also automatically check if the slave machines are available (lnst-slave is running and it's not used by a different controller), after that it will try to match your recipe with the available machines and inform about the chosen machines. Finally the recipe will be executed.
To learn how to write your own recipe read this page.