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.
Contents
Virtual Networking
Getting User Mode Linux networked with VirtualBox
Introduction
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 10.1.0.0/24, with the host being 10.1.0.1 and the main uml machine on 10.1.0.2 .
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:
screen (to access the main uml machine)
virtualbox-ose (you may need to build the modules with module-assistant, from virtualbox-ose-source)
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
address 10.1.0.1
netmask 255.255.255.0
tunctl_user uml-netThe ip address can be changed according to your needs, but the rest of the guide will assume that it's set to 10.1.0.1 .
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 exit
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:
[global] fstype=ext2 ## 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. initialsize=1024 freespace=0 modules=network mkfs mount debian uml umount PATH=/bin:/sbin:/usr/bin:/usr/sbin ## we will set the memory back down to 32M once ## the rootstrap is over, but having it high is ## helpful for installing the system umlargs=mem=128M ## you don't really need this one, but it can be ## informative, and will help when you run into problems debug=true [network] ## 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. hostname=nethead ## most of this was just uncommented from ## the example rootstrap.conf file and the ## ip's were modified. interface=eth0 transport=daemon uml=10.1.0.2 netmask=255.255.255.0 control=/var/run/uml-utilities/uml_switch.ctl data=/var/run/uml-utilities/uml_switch.data gateway=10.1.0.1 ## get the nameserver from /etc/resolv.conf ## and replace this option nameserver=10.1.0.1 [debian] dist=lenny mirror=http://10.1.0.1/debian exclude=pcmcia-cs setserial [base-config] root_password=rootstrap [uml] kernel_modules=copy kernel_modules_dir=/usr/lib/uml/modules
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
address 10.1.0.1
netmask 255.255.255.0
broadcast 10.1.0.255
bridge_ports tap0
bridge_stp off
bridge_fd 2.5
post-up /etc/network/br0-interface up
post-down /etc/network/br0-interface downPlease 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
ubd0=/path/to/uml/images/nethead
case "$1" in
up)
# 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 &
;;
down)
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
;;
esacThis 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 10.1.0.0 netmask 255.255.255.0 {
range 10.1.0.3 10.1.0.253;
option domain-name-servers 10.1.0.2;
option domain-name "vboxnet";
option routers 10.1.0.1;
}You can pick your own domain name and range of ip's. If you're not using 10.1.0.0/24, 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:
openssh-server (this will allow you to use ssh, instead of screen to connect to nethead)
rsync (helps to backup and restore all or parts of nethead)
xemacs21 (or vim, if you prefer)
sudo (this helps a lot if you make a user account)
Now you should be ready to power off the nethead machine.
poweroff
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
IF="$1"
BRIDGE=br0
case "$2" in
up)
# 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
;;
down)
sudo VBoxTunctl -d $IF >/dev/null 2>&1
;;
esacAlso 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.
Notes
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.