Virtualization With LNST

LNST is targeted primarily at physical machines and testing on real hardware. However, sometimes you don't have the time and/or resources to prepare the desired networking setup. Or perhaps you would like to rapidly test a lot of various network configurations and setups without any manual intervention. These are the times when virtualization comes to play. LNST can work with virtual machines just as well as with your physical ones, and if you meet certain conditions, LNST can handle automatically many more tasks than it ever could with physical machines. This page will explain how to configure LNST to take the full advantage of this feature.

How does it work?

LNST is integrated with libvirt and in case you use it for running your guests, LNST is able to configure the entire network topology automatically, based on the requirements of the recipe being run. The implementation takes advantage from the fact, that libvirt allows dynamic hot-plugging of new network interfaces to already running domains. This means you only have to prepare the VMs and LNST will dynamically create and destroy connections between them as it executes different recipes. Pretty neat, huh? The next section will describe the few steps you need to take to get this working properly.

How to make it work for you?

To set LNST up with virtual machines, there are several conditions you will need to meet:

• All guest VMs must be all on the controller
• Each VM must have a controller interface configured properly
• Each slave must be marked as virtual using the libvirt_domain parameter
• lnst-ctl must be run as root
• allow_virtual option must be enabled for lnst-ctl

The most important part is marking the machines as virtual in slavemachine config files in the pool. Here is an example of such a configuration:

<slavemachine>
    <params>
        <param name="hostname"   value="192.168.122.13"/>
        <param name="libvirt_domain" value="Fedora18"/>
        <param name="os"   value="fedora18"/>
        <param name="type" value="virtual"/>
    </params>
</slavemachine>

The libvirt_domain allows LNST to control the machine conveniently through libvirt's API. It is also a good practice to set the type parameter to indicate that this slave is a VM, although the parameter is not required and doesn't have any special meaning (in contrast with libvirt_domain). Also note, that there are no test interfaces defined. This is not an error. LNST will configure these interfaces automatically.

You can actually configure some interfaces on the VM by hand, but this approach is discouraged, as you are doing unnecessary work.

Mixing VMs With Physical Machines

If your pool is mixed and contains both virtual and physical machines, lnst-ctl will first try to find a matching physical setup. In case it fails to do so, it will try to setup a virtual network based on the recipe requirements. Note, that LNST will never match a mixed setup in which a part would consist from VMs while other machines were physical. LNST works isolates these two types of slave machines, because it would be very hard to implement in a generic-enough way, while bringing only a small benefit in a few corner cases.