April 22, 2019

User Mode Linux: Coming to a Kernel Near You, Part 2 - page 2

When We Last Left Our Story...

  • March 18, 2003
  • By Dee-Ann LeBlanc

The first thing you probably want to do is convince your UML to talk to the outside world. If you're used to installing Linux with a nice neat graphical installer and having the system come up fully operational, this process might throw you for a loop. You'll have to do it by hand.

On a modern Linux system (running at least kernel 2.4), you'll be using TUN/TAP. TUN stands for TUNnelling in the sense of virtual networking, and is specifically for use with the IP part of TCP/IP. TAP is the Ethernet portion of the equation, so if you were using different networking hardware you would need a different driver (see http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO.html).

There are a number of methods available for setting up the networking, and some are more secure than others. I'm going to cover the simplest method here since the idea is to set up a system to play with. If you intend to use this system for serious hosting or other purposes, then see the HOWTO listed above and go to the section, 6.7 TUN/TAP with a preconfigured TAP device, and if you're doing so under Red Hat Linux then also
seehttp://sourceforge.net/mailarchive/forum.php?thread_id=1504983&forum_id=3647. This is a more secure method than what we're doing.

The first thing to do is to double-check to see what the permissions on /dev/net/tun are. By default, they're 700, but that means that only root can utilize the tun device. You'll need to change the permissions and perhaps the group setting to allow the users who need UML access to have networking.

Once you've done this, you also need to load the TUN module (named tun.o). You can do this by typing insmod tun.o, or by editing /etc/modules.conf (or /etc/conf.modules) and adding the line:

alias char-major-10-200 tun

The second option is the more permanent, and therefore recommended, solution.

Now we can rely on the uml_net utility that was installed with the UML RPM. If you built your UML kernel from source, then you'll have to get the uml_net package separately from the same page as the rest of the tools. Just as we typed the following to start up the UML with no networking:

linux ubd0=/path/to/unpacked/filesystem

We type this to start it with networking, using the uml_net helper:

linux ubd0=/path/to/unpacked/filesystem, eth#=tuntap,,,ipaddress

Here, the # refers to the virtual UML Ethernet interface you're initializing, for the first it's eth0. You're going to need a total of two IP addresses here. The IP address used in the above code has to be one that isn't assigned to the host machine's eth0, and won't be the one assigned to the virtual interface within the UML either. So, you might use something like:

linux ubd0=~/Downloads/root_fs.rh-7.2-server.pristine.20020312

Once your UML session boots, log in as root. Here's where it gets _interesting._ Some default, pre-made UML filesystems are more set up than others. Type ifconfig to see if any IP addresses are set at all. If not, then you need to begin by setting up local loopback by typing:

ifconfig lo up

If loopback is already set up, you can tell when you see an entry like the following:

lo Link encap:Local Loopback
inet addr: Mask:
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Once you are sure that loopback is set up, look at your ifconfig output or type ifconfig again and see if any other addresses are assigned. A number of the default filesystems available for download include bogus pre-assigned IP addresses for the virtual Ethernet device.

Therefore, on just about any pre-set filesystem, you'll need to assign the UML's internal eth0 IP address, to what makes sense for your network. In the case of the example I'm following, I want the address for the UML (it nicely matches the for the host), so I use:

ifconfig eth0 up

Typing ifconfig again should verify that the first virtual Ethernet interface now has the IP address you wanted. That doesn't mean your machine can reach out to the world, however. It needs to know how to talk to the rest of the machines on the network, and to the Internet.

To explain this to your machine, you need to set up a default routing gateway. This will point to the IP address you just assigned to eth0, so in the case of this example, I use:

route add default gw

Before we move on to setting up nameservice, it's a good idea to test your networking. A sequence like the following will make it apparent what's working and what isn't:

  1. Ping the virtual machine by IP address, from the virtual machine.
  2. Ping the host machine by IP address, from the virtual machine.
  3. Ping another machine on your network by IP address, from the virtual machine.
  4. Ping a machine on the Internet by IP address, from your virtual machine.

Now, who wants to have to remember IP addresses for everything? Let's set up nameservice. Try pinging a site by name if you want to test and see if nameservice is already working, but it likely is not.

To activate nameservice for your UML machine, make a backup of the file /etc/resolv.conf and then edit the original, adding one or more lines in the format:

nameserver ipaddress

Where ipaddress is the address of the nameserver in question. If you enter a name for the nameserver, the system won't be able to resolve it! Not all UML filesystems come with text editors. I'm not sure why this is, but it's true. Fortunately, when this is a problem, the UML does come with the sed stream editor. For an example of how to make the change using sed, I'll use a default /etc/resolv.conf file of:


Since my nameservice is done through for my internal machines, I use a command like the following to change (which is just some default included with the UML) to

sed 's/' < /etc/resolv.conf.old >

Once you've made this change, try pinging a site on the Internet using its full name.

Most Popular LinuxPlanet Stories