XIA Linux Containers (XLXC)

It is useful to create many XIA hosts for debugging and testing purposes. Although virtual machines can be created to suit this need, simulating larger networks of dozens or hundreds of nodes requires a more lightweight virtualization solution. Linux Containers are perfect for this task, as they isolate system resources and namespaces to create virtual environments and do not require as many resources as true virtual machines do.

There is a repository that contains scripts for creating many containers that have the ability to run the XIA kernel, assuming the host machine is running XIA. These scripts can be obtained with this command:

 $ git clone http://github.com/cjdoucette/xlxc.git

Note that these scripts currently work only for Ubuntu 13.04 (Raring Ringtail).

Before the scripts can be used, the basic LXC package, Ruby, and tools for network bridges must be obtained:

 # apt-get install lxc ruby1.9.1 bridge-utils

Table of Contents Using the XLXC Scripts xlxc-create xlxc-destroy Further Using XLXC lxc-execute xlxc-start and xlxc-console

Using the XLXC Scripts

xlxc-create

The first script in this directory is xlxc-create. This script is capable of creating multiple XIA or IP containers, which are always named in the form "stacki" where "stack" is either "xia" or "ip" and "i" is the number container of that stack.

To create just a single Linux XIA container, while running an XIA kernel execute the following command:

 # ruby xlxc-create.rb

This would create a single container named xia1.

To create multiple containers at once, the --count option can be used:

  # ruby xlxc-create.rb --count=4

This would create four containers, named xia1, xia2, xia3, and xia4.

To create containers without XIA tools available, use the --ip option:

  # ruby xlxc-create.rb --count=2 --ip

This would create two containers, named ip1 and ip2.

xlxc-destroy

The second script in this directory is xlxc-destroy. The purpose of this script is to stop and destroy any containers specified, including any files that were bind mounted. To do this, the user needs to specify the name of the containers to be destroyed by listing the name of the relevant network stack and the indexes of the containers. For example, if there are four XIA containers (named xia1, xia2, xia3, xia4), to destroy the last three of them, use the following command:

  # ruby xlxc-destroy.rb xia 2 4

Further Using XLXC

It is recommended to use xlxc-create and xlxc-destroy in combination with lxc-execute, lxc-start, and lxc-console, which are programs built into the lxc package.

lxc-execute

lxc-execute is capable of running a container on a command. For example, if the user wants to make an XIA container and add an HID, then the following commands could be used:

 # ruby xlxc-create.rb
 # lxc-execute -n xia1 -- sudo xip hid new xia1 && sudo xip hid add xia1 && cat

This would create an XIA container, create a new HID, and add that HID to the container. The final command, cat, is a way of keeping the container running. Otherwise, the container will close.

An even more useful way of doing this would be to create a script that the container can run. For example, a bash script for the container to run may look like:

container.sh

 # Add HIDs to start NWP.
 sudo xip hid new xia1
 sudo xip hid add xia1
 # Keep container running.
 cat

Then, the script must either be bind mounted to the container or copied into the container. From the perspective of the host, the root filesystem for a container named xia1 is usually found in /var/lib/lxc/xia1/rootfs (on Ubuntu, at least). With this script, the commands could instead be:

 # ruby xlxc-create.rb
 # chmod +x container.sh
 # cp container.sh /var/lib/lxc/xia1/rootfs/container.sh
 # lxc-execute -n xia1 -- ./container.sh

This way, container.sh can contain any number of commands to be executed automatically without logging-in to the container.

xlxc-start and xlxc-console

Note: Containers share the kernel with the host. Therefore, a container cannot add or remove kernel modules. In order to use XIA, the host must first load any principals that are desired. However, containers are then free to use those principals in their namespace by, for example, adding entries to their routing table.