Benito has been designed from the ground up to support multiple virtualization platforms. The interface for plugging new virtualization platform into Benito is described here.

It is useful to refer to BenitoPipeline, as this document will refer to various points in the pipeline where your scripts must be called.

Networking

All networking internal to Benito is done using ​VDE (Virtual Distributed Ethernet). If your virtualization platform natively supports VDE, your life is relatively easy. If not, plugging in should still be possible.

Networking configuration can be found in the following places:

• TopDL: IP address, netmask, MAC address, VDE switch/port
• /var/benito/config/route/$HOSTNAME: routes

Each interface on the experimental network will be assigned a VDE switch and port number. If your platform supports VDE natively, then you're done!

For platforms that do not have VDE support, TAP support is sufficient. vde_plug2tap acts as an adapter between a VDE switch port and a TAP interface. VDE also comes with vde_tunctl which can create TAP interfaces on the fly to be used by other apps.

The following example illustrates how one might do this with QEMU. QEMU has native VDE support, but we'll assume for a moment that we can't use it.

#!/bin/sh

SWITCH_SOCKET=$1
SWITCH_PORT=$2

vde_tunctl tap0
vde_plug2tap -d -s $SWITCH_SOCKET -p $SWITCH_PORT tap0
qemu -net nic -net tap,ifname=tap0 fs.img

If you don't even have TAP support.. get creative. Chances are if you can talk to a file descriptor pair vde_plug will work for you.

Interface Attributes

The info you care about will be attributes on each interface.

• ip4_address
• ip4_netmask
• benito:mac_address
• benito:vde_switch (switch socket full path)
• benito:vde_port (switch port)

Routes

Route information is in /var/benito/config/route/$HOSTNAME. Benito provides a script for automatically setting up routes:

/var/benito/launch/routes.py /var/benito/config [$HOSTNAME]

The hostname parameter is optional and will be auto-detected if it is not provided.

Control Net

FOREWORD: Control net bridging is currently a hack. It makes a lot of assumptions about the underlying platform (i.e., qemu) and many aspects of this are baked into the code. Best of luck..

You'll probably want to bridge onto the control net if that makes sense for your platform. If you see yourself wanting to SSH to a VM running on your platform, this is for you.

Due to DETER's controlnet separation, you must explicitly request IPs/MACs from boss. The setup script setup/15_control_net.py handles these requisitions. You'll need to hack this file a bit. Sorry!

On pnodes which host vnodes, the controlnet interface is bridged with TAP controlnet interfaces of its children. The bridge is brought up by launch/qemu/control_bridge.py. This script is currently tailored to QEMU. To support new VM infrastructure this will need to be hacked on.

File Systems

Guest OSes expect to be able to read:

• /users
• /proj
• /groups
• /share

If your system can directly access parts of the host file system then you're done! For an example of this, see view-os lightweight processes.

If not, you should probably use the npfs implementation currently being used by qemu. The npfs server is launched from launch/qemu just before inner-nodes are booted. This will likely need to move to a more general location.

Linux 9P support is excellent starting from the 2.6.20's series. Here's an example fstab entry, assuming the host machine's IP is 192.168.1.1:

192.168.1.1 /users 9p _netdev,aname=/users 0 1

For more bread crumbs look in setup/qemu/40_file_systems.py and setup/qemu/50_root_fs.py (look for 'fstab' in the latter).