Translation(s): none

(!) ?Discussion

There is not much info here yet. This page is devoted to describing how to configure debian to be able to use a virtual network on your system that lets different virtualization applications to work together and be able to talk to each other on the virtual network.

Virtual Networking

Getting User Mode Linux networked with VirtualBox


The method outlined below will help get user-mode-linux machines and VirtualBox machines working on the same "virtual network". In this routine, we will be creating a primary tap interface and bridging it. This is not the same as bridging the local ethernet interface, and the virtual machines will only be accessible from the host system.

In this guide, I will be using some abbreviations. The term "uml" will be used to refer to a user-mode-linux virtual machine. The term "vbox" will be used to refer to a virtualbox machine. The term "VM" (or "vm") will be used for an unspecified virtual machine (either uml or vbox). Also there will be some assumptions being made that you may want to change. It will be assumed that your local network interface will be called eth0. It will also be assumed that the virtual network that you'll be creating is on, with the host being and the main uml machine on .

This guide will also make use of a persistent uml machine to run the dhcp server and the nameserver for the virtual network. This is not really necessary, as you can choose to run those programs on the host system. It is useful, however, if you wish to keep the configuration on the host system at a minimum, and also to minimize the requirement for root access on the host system.

These instructions can be modified to use vde2. Doing this will allow you to also use qemu and kvm machines on the same network. Using vde2 would probably be the optimal setup for this guide, but since I'm not using it at the moment, these instructions will have to suffice.

One final note. These instructions will assume that you are either familiar with the programs and/or procedures detailed here, or are willing to read up on them. These instructions aren't meant to be howto's for using rootstrap, setting up a bridged network, configuring dhcp3-server, etc. I will try to provide links to places where you can learn how to do these things, but this guide isn't meant to be a replacement for those instructions.

Prepare Host System

Install Requirements

Required packages on host system:

You will need to add your user to these groups: uml-net and vboxusers

You will need to log out entirely and possibly kill every process being run by that user in order to finalize the addition to the groups (slay is a good command for this). The rest of the guide will assume that this has already been done.

Prepare TAP Interface

Edit /etc/network/interfaces and add these lines:

        auto tap0
        iface tap0 inet static
                tunctl_user uml-net

The ip address can be changed according to your needs, but the rest of the guide will assume that it's set to .

Edit /etc/default/uml-utilites and set UML_SWITCH_OPTIONS="-tap tap0".

Now you can stop uml-utilities:

sudo /etc/init.d/uml-utilities stop

Bring up the new tap interface:

sudo ifup tap0

Now start uml-utilities again:

sudo /etc/init.d/uml-utilities start

This should start the uml_switch on tap0.

At this point, you will probably want to enable masquerading to get the tap network access to the local network or internet. You will only have to do this once here, since later, we will write scripts to help manage this.

sudo su
 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo '1' > /proc/sys/net/ipv4/ip_forward

Prepare Rootstrap

You will need a directory to store your uml images. Make the directory, and copy /etc/rootstrap/rootstrap.conf to it. Change (cd) to that directory and edit the rootstrap.conf file. You can use mine as an example. The name of both the uml machine and the filesystem image will be "nethead". Feel free to change it, but remember that the rest of this guide will assume that the this uml's name is nethead.

my rootstrap.conf:

## I have about 100M or so free using a 1G 
## filesystem.  I'm not running much more than
## the standard, plus dhcp3-server, bind9 and 
## some extra stuff like xemacs, rsync, slay, etc.
modules=network mkfs mount debian uml umount
## we will set the memory back down to 32M once
## the rootstrap is over, but having it high is
## helpful for installing the system
## you don't really need this one, but it can be 
## informative, and will help when you run into problems

## the rest of the guide will assume that this
## hostname is being used, but you can change
## this, just be aware that this hostname will 
## be used in the guide.

## most of this was just uncommented from
## the example rootstrap.conf file and the
## ip's were modified.
## get the nameserver from /etc/resolv.conf
## and replace this option

exclude=pcmcia-cs setserial



Once you have prepared the rootstrap.conf file, you are ready to run rootstrap. Make sure that you are in the same directory as the rootstrap.conf that you just modified and type:

rootstrap nethead

Here, nethead is the name of the image file. I like to keep the image files named after the hostnames of the uml's (or prefixed with the hostname when using multiple images). This is a good habit, as it keeps things organized when you have a lot of testing machines laying around.

We will wait just a bit before we configure nethead.

Prepare TAP Bridge

We are now ready to start configuring the tap bridge. We won't bring this interface up until the we configure the nethead uml, but doing this now will help you see what is going to be happening, and how the nethead uml will be run.

You should add this to /etc/network/interfaces:

iface br0 inet static
        bridge_ports tap0
        bridge_stp off
        bridge_fd 2.5
        post-up /etc/network/br0-interface up
        post-down /etc/network/br0-interface down

Please note that there is no auto line here. This is because this interface would be brought up too early in the boot process, and the nethead uml would be able to connect to the switch. You can bring this interface up when you login to the desktop, or you can make an initscript for this that will run after the uml-utilities script runs.

The interface stanza above references a script to be run on enabling and disabling the tap bridge interface. This script is provided below. Save this script in /etc/network/br0-interface and replace username with the your user name. You will also need to set the ubd0 variable to the absolute path to the nethead uml image that you just made.

set -e

case "$1" in 
    # If you don't need ip forwarding or already have it, remove
    # or comment out the next two lines, and the corresponding lines for "down"
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    echo '1' > /proc/sys/net/ipv4/ip_forward
    # I don't really think it makes a difference whether the TERM variable is
    # set here, or left unset.  The uml kernel seems to complain either way.
    su -l -c "env TERM=console linux ubd0=$ubd0 eth0=daemon con=pts mem=32m umid=nethead" username &
    su -l -c "uml_mconsole nethead halt" username
    iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
    echo '0' > /proc/sys/net/ipv4/ip_forward

This script will enable/disable ip forwarding on your main ethernet device. If you already have another method for doing this, you can comment those parts out.

Configure Nethead UML Machine

Start Nethead UML Machine

Now we are ready to configure the nethead machine. You can start it up with a command similar to the one in the script above.

linux ubd0=/path/to/images/nethead eth0=daemon con=pts con1=xterm umid=nethead

Here we have con1=xterm which will bring up an terminal window for tty1. Normally, you won't be using a terminal window for the console, as the machine will be running in the background. We're doing it this time as a convenience to get it set up.

How to Connect to a UML Running in the Background

Before we set nethead up, I'll give some brief instructions on how to connect to the uml machine when it's running in the background. When your uml machine is running in the background you will need to use uml_mconsole to find a pts device to connect to. Here's an example of how to do it.

uml_mconsole nethead config con1

This will give you the device node for the pts console. It should return something similar to OK pts:/dev/pts/2 . Also note that the nethead argument to uml_mconsole corresponds to the umid argument to the "linux" command, not the hostname, nor the image name.

Now that you've found the device entry for con1, you can connect to the uml using screen. Here's how:

screen /dev/pts/2

You will probably see a blank screen. Just press "return" and a normal login should appear. You can log in normally now.

In order to disconnect, you should log out first. Then press <Ctrl-a> k and press 'y' to confirm killing the window. This will terminate screen.

Configuring the Nethead UML Machine

Now we are ready to start configuring the nethead uml machine. You should have a terminal window open with a login screen on it. You should be able to log in as root without a password. This is the default setup with rootstrap. If you don't feel comfortable with this, you can set the root password as soon as you log in.

Now that you're logged in as root, it's time to install the necessary packages. This command will install all the standard packages.

aptitude install ~prequired ~pimportant ~pstandard

Now we need to install bind9 resolvconf, and dhcp3-server .

aptitude install bind9 dhcp3-server

Now we need to configure the dhcp server. First, edit /etc/default/dhcp3-server and set INTERFACES="eth0". Next we need to edit /etc/dhcp3/dhcpd.conf and add this stanza:

subnet netmask {
    option domain-name-servers;
    option domain-name "vboxnet";
    option routers;

You can pick your own domain name and range of ip's. If you're not using, you will need to adjust the ip addresses accordingly.

Since this machine will be set to run the whole time that the tap network is enabled, we want to make it's memory footprint as small as possible. In the interface script above, the nethead uml is set to run at 32M, which is probably close to being as small as possible. I haven't tried anything smaller. This is not really enough memory for the machine, and you should expect to have memory problems unless you create a swap file. Below, we will create a 100M swap file and add an entry to the fstab so it will be enabled when the uml boots.

dd if=/dev/zero  of=/swap bs=1k count=100k
mkswap /swap
swapon /swap

add this line to /etc/fstab

/swap   none    swap    sw      0       0

You may want to create a swap "partition" instead by performing the dd command on the host.

dd if=/dev/zero  of=/path/to/images/nethead-swap bs=1k count=100k

You would then pass this file as ubd1=/path/to/images/nethead-swap on the linux command line. In the /etc/fstab file ubd1 will translate to /dev/ubdb .

While it's not strictly required, you may want to spend some more time configuring the nethead uml machine. I usually install these packages to most of my machines:

Now you should be ready to power off the nethead machine.


Starting the TAP Network

We're now ready to start the tap network we defined above. If you copied the "br0-interface" above, the nethead uml should start automatically when you bring the br0 interface up, and stop when you take it down.

sudo ifup br0

You will need to run this command everytime that you login. If you really want to have this interface running before you log in, you shouldn't use the "auto" option in the /etc/network/interfaces file. This will try to boot the nethead uml before the uml-switch is started. What you should do is create a script in /etc/init.d and use update-rc.d to run the script after the uml-utilities script runs.

Make VirtualBox Machine

Now, you're ready to make a VirtualBox machine to test the network. I don't really go through all the details on doing this. You can find some of that information on the VirtualBox page. Please read that page and pay special attention to the section on "Setting up bridged networking for VirtualBox". The instructions are the same, the only difference is that the tap interface is being bridged, instead of the ethernet interface. Instead of having the virtualbox vm's assigned ip's for the local network, they're assigned ip's for the tap network that the uml_switch is connected to. This will let your virtualbox machines talk to your uml machines.

The script below is practically identical to the one on the VirtualBox page. If you want to name the tap interfaces according to the name of the machine, use the script below. If you want to have the tap interfaces automatically numbered, use the script on the VirtualBox page. This script takes two arguments, the name of the interface (vbox_vmname), and (up|down). The script on the VirtualBox page only takes one argument (up|down).

set -e
case "$2" in
        # ensure that the TAP device is down
        sudo VBoxTunctl -d $IF >/dev/null 2>&1
        # Create a TAP network device
        sudo VBoxTunctl -u $LOGNAME -t $IF >/dev/null 2>&1
        # Bring it up (without IP address)
        sudo ifconfig $IF up
        # Add it to the bridge
        sudo brctl addif $BRIDGE $IF
        # Tell VirtualBox the name of the interface
        echo $IF
        sudo VBoxTunctl -d $IF >/dev/null 2>&1

Also consider adding the sudoers snippet on the VirtualBox page to your /etc/sudoers file. It really helps if you need to bring machines up and down frequently.


The setup described above is not the same as the setup on my machine. On my laptop, I have two bridges. One for the ethernet (br0) and one for the tap network (br1). This makes it easier for me to put a vbox machine on either interface. It's possible that the instructions above are slightly incorrect because of this. I've tried to make the instructions as accurate as possible, but that doesn't mean that they are. Feel free to make corrections, if they're needed.

The setup above precludes qemu and kvm machines from attaching to this network, unless there's a method that I'm unaware of. There is a package (vde2) that has a switch that's similar to the uml_switch used in these instructions. The qemu and kvm machines can attach to the vde2 switch through a wrapper provided by the vde2 package. The uml machines can also attach themselves to the vde2 switch by specifying the data and control sockets in the eth# arguments to the linux command.

It may be better for somebody who is more experienced in using vde2 to update this page and show how to get more virtualization programs to attach to the same network.

This page was made for the simple fact that one virtualization solution doesn't always "cut the mustard". For example, if you only need to run linux, the uml's are probably better than running vboxes. If you need to test another operating system, it's obvious that uml's won't be able to do that job. If you need to run linux, but test packages that work with hardware components, that's probably better done with virtualbox. If you need to test how windows clients interact with a samba server, that's a good time to use both uml and vbox and have a network that both of them can use.

CategoryNetwork | CategoryVirtualization