______________________________________________________________________
- 1\b1.\b. I\bIn\bnt\btr\bro\bod\bdu\buc\bct\bti\bio\bon\bn
+ 1. Introduction
Welcome to User Mode Linux. It's going to be fun.
- 1\b1.\b.1\b1.\b. H\bHo\bow\bw i\bis\bs U\bUs\bse\ber\br M\bMo\bod\bde\be L\bLi\bin\bnu\bux\bx D\bDi\bif\bff\bfe\ber\bre\ben\bnt\bt?\b?
+ 1.1. How is User Mode Linux Different?
Normally, the Linux Kernel talks straight to your hardware (video
card, keyboard, hard drives, etc), and any programs which run ask the
- 1\b1.\b.2\b2.\b. W\bWh\bhy\by W\bWo\bou\bul\bld\bd I\bI W\bWa\ban\bnt\bt U\bUs\bse\ber\br M\bMo\bod\bde\be L\bLi\bin\bnu\bux\bx?\b?
+ 1.2. Why Would I Want User Mode Linux?
1. If User Mode Linux crashes, your host kernel is still fine.
- 2\b2.\b. C\bCo\bom\bmp\bpi\bil\bli\bin\bng\bg t\bth\bhe\be k\bke\ber\brn\bne\bel\bl a\ban\bnd\bd m\bmo\bod\bdu\bul\ble\bes\bs
+ 2. Compiling the kernel and modules
- 2\b2.\b.1\b1.\b. C\bCo\bom\bmp\bpi\bil\bli\bin\bng\bg t\bth\bhe\be k\bke\ber\brn\bne\bel\bl
+ 2.1. Compiling the kernel
Compiling the user mode kernel is just like compiling any other
bug fixes and enhancements that have gone into subsequent releases.
- 2\b2.\b.2\b2.\b. C\bCo\bom\bmp\bpi\bil\bli\bin\bng\bg a\ban\bnd\bd i\bin\bns\bst\bta\bal\bll\bli\bin\bng\bg k\bke\ber\brn\bne\bel\bl m\bmo\bod\bdu\bul\ble\bes\bs
+ 2.2. Compiling and installing kernel modules
UML modules are built in the same way as the native kernel (with the
exception of the 'ARCH=um' that you always need for UML):
- 2\b2.\b.3\b3.\b. C\bCo\bom\bmp\bpi\bil\bli\bin\bng\bg a\ban\bnd\bd i\bin\bns\bst\bta\bal\bll\bli\bin\bng\bg u\bum\bml\bl_\b_u\but\bti\bil\bli\bit\bti\bie\bes\bs
+ 2.3. Compiling and installing uml_utilities
Many features of the UML kernel require a user-space helper program,
so a uml_utilities package is distributed separately from the kernel
patch which provides these helpers. Included within this is:
- +\bo port-helper - Used by consoles which connect to xterms or ports
+ o port-helper - Used by consoles which connect to xterms or ports
- +\bo tunctl - Configuration tool to create and delete tap devices
+ o tunctl - Configuration tool to create and delete tap devices
- +\bo uml_net - Setuid binary for automatic tap device configuration
+ o uml_net - Setuid binary for automatic tap device configuration
- +\bo uml_switch - User-space virtual switch required for daemon
+ o uml_switch - User-space virtual switch required for daemon
transport
The uml_utilities tree is compiled with:
- 3\b3.\b. R\bRu\bun\bnn\bni\bin\bng\bg U\bUM\bML\bL a\ban\bnd\bd l\blo\bog\bgg\bgi\bin\bng\bg i\bin\bn
+ 3. Running UML and logging in
- 3\b3.\b.1\b1.\b. R\bRu\bun\bnn\bni\bin\bng\bg U\bUM\bML\bL
+ 3.1. Running UML
It runs on 2.2.15 or later, and all 2.4 kernels.
- 3\b3.\b.2\b2.\b. L\bLo\bog\bgg\bgi\bin\bng\bg i\bin\bn
+ 3.2. Logging in
There are a couple of other ways to log in:
- +\bo On a virtual console
+ o On a virtual console
- +\bo Over the serial line
+ o Over the serial line
In the boot output, find a line that looks like:
- +\bo Over the net
+ o Over the net
If the network is running, then you can telnet to the virtual
down and the process will exit.
- 3\b3.\b.3\b3.\b. E\bEx\bxa\bam\bmp\bpl\ble\bes\bs
+ 3.3. Examples
Here are some examples of UML in action:
- +\bo A login session <http://user-mode-linux.sourceforge.net/login.html>
+ o A login session <http://user-mode-linux.sourceforge.net/login.html>
- +\bo A virtual network <http://user-mode-linux.sourceforge.net/net.html>
+ o A virtual network <http://user-mode-linux.sourceforge.net/net.html>
- 4\b4.\b. U\bUM\bML\bL o\bon\bn 2\b2G\bG/\b/2\b2G\bG h\bho\bos\bst\bts\bs
+ 4. UML on 2G/2G hosts
- 4\b4.\b.1\b1.\b. I\bIn\bnt\btr\bro\bod\bdu\buc\bct\bti\bio\bon\bn
+ 4.1. Introduction
Most Linux machines are configured so that the kernel occupies the
- 4\b4.\b.2\b2.\b. T\bTh\bhe\be p\bpr\bro\bob\bbl\ble\bem\bm
+ 4.2. The problem
The prebuilt UML binaries on this site will not run on 2G/2G hosts
- 4\b4.\b.3\b3.\b. T\bTh\bhe\be s\bso\bol\blu\but\bti\bio\bon\bn
+ 4.3. The solution
The fix for this is to rebuild UML from source after enabling
- 5\b5.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp s\bse\ber\bri\bia\bal\bl l\bli\bin\bne\bes\bs a\ban\bnd\bd c\bco\bon\bns\bso\bol\ble\bes\bs
+ 5. Setting up serial lines and consoles
It is possible to attach UML serial lines and consoles to many types
You can attach them to host ptys, ttys, file descriptors, and ports.
This allows you to do things like
- +\bo have a UML console appear on an unused host console,
+ o have a UML console appear on an unused host console,
- +\bo hook two virtual machines together by having one attach to a pty
+ o hook two virtual machines together by having one attach to a pty
and having the other attach to the corresponding tty
- +\bo make a virtual machine accessible from the net by attaching a
+ o make a virtual machine accessible from the net by attaching a
console to a port on the host.
- 5\b5.\b.1\b1.\b. S\bSp\bpe\bec\bci\bif\bfy\byi\bin\bng\bg t\bth\bhe\be d\bde\bev\bvi\bic\bce\be
+ 5.1. Specifying the device
Devices are specified with "con" or "ssl" (console or serial line,
respectively), optionally with a device number if you are talking
- 5\b5.\b.2\b2.\b. S\bSp\bpe\bec\bci\bif\bfy\byi\bin\bng\bg t\bth\bhe\be c\bch\bha\ban\bnn\bne\bel\bl
+ 5.2. Specifying the channel
There are a number of different types of channels to attach a UML
device to, each with a different way of specifying exactly what to
attach to.
- +\bo pseudo-terminals - device=pty pts terminals - device=pts
+ o pseudo-terminals - device=pty pts terminals - device=pts
This will cause UML to allocate a free host pseudo-terminal for the
log. You access it by attaching a terminal program to the
corresponding tty:
- +\bo screen /dev/pts/n
+ o screen /dev/pts/n
- +\bo screen /dev/ttyxx
+ o screen /dev/ttyxx
- +\bo minicom -o -p /dev/ttyxx - minicom seems not able to handle pts
+ o minicom -o -p /dev/ttyxx - minicom seems not able to handle pts
devices
- +\bo kermit - start it up, 'open' the device, then 'connect'
+ o kermit - start it up, 'open' the device, then 'connect'
- +\bo terminals - device=tty:tty device file
+ o terminals - device=tty:tty device file
This will make UML attach the device to the specified tty (i.e
- +\bo xterms - device=xterm
+ o xterms - device=xterm
UML will run an xterm and the device will be attached to it.
- +\bo Port - device=port:port number
+ o Port - device=port:port number
This will attach the UML devices to the specified host port.
- +\bo already-existing file descriptors - device=file descriptor
+ o already-existing file descriptors - device=file descriptor
If you set up a file descriptor on the UML command line, you can
- +\bo Nothing - device=null
+ o Nothing - device=null
This allows the device to be opened, in contrast to 'none', but
- +\bo None - device=none
+ o None - device=none
This causes the device to disappear.
- will cause serial line 3 to accept input on the host's /dev/tty3 and
+ will cause serial line 3 to accept input on the host's /dev/tty2 and
display output on an xterm. That's a silly example - the most common
use of this syntax is to reattach the main console to stdin and stdout
as shown above.
- 5\b5.\b.3\b3.\b. E\bEx\bxa\bam\bmp\bpl\ble\bes\bs
+ 5.3. Examples
There are a number of interesting things you can do with this
capability.
prompt of the other virtual machine.
- 6\b6.\b. S\bSe\bet\btt\bti\bin\bng\bg u\bup\bp t\bth\bhe\be n\bne\bet\btw\bwo\bor\brk\bk
+ 6. Setting up the network
There are currently five transport types available for a UML virtual
machine to exchange packets with other hosts:
- +\bo ethertap
+ o ethertap
- +\bo TUN/TAP
+ o TUN/TAP
- +\bo Multicast
+ o Multicast
- +\bo a switch daemon
+ o a switch daemon
- +\bo slip
+ o slip
- +\bo slirp
+ o slirp
- +\bo pcap
+ o pcap
The TUN/TAP, ethertap, slip, and slirp transports allow a UML
instance to exchange packets with the host. They may be directed
With so many host transports, which one should you use? Here's when
you should use each one:
- +\bo ethertap - if you want access to the host networking and it is
+ o ethertap - if you want access to the host networking and it is
running 2.2
- +\bo TUN/TAP - if you want access to the host networking and it is
+ o TUN/TAP - if you want access to the host networking and it is
running 2.4. Also, the TUN/TAP transport is able to use a
preconfigured device, allowing it to avoid using the setuid uml_net
helper, which is a security advantage.
- +\bo Multicast - if you want a purely virtual network and you don't want
+ o Multicast - if you want a purely virtual network and you don't want
to set up anything but the UML
- +\bo a switch daemon - if you want a purely virtual network and you
+ o a switch daemon - if you want a purely virtual network and you
don't mind running the daemon in order to get somewhat better
performance
- +\bo slip - there is no particular reason to run the slip backend unless
+ o slip - there is no particular reason to run the slip backend unless
ethertap and TUN/TAP are just not available for some reason
- +\bo slirp - if you don't have root access on the host to setup
+ o slirp - if you don't have root access on the host to setup
networking, or if you don't want to allocate an IP to your UML
- +\bo pcap - not much use for actual network connectivity, but great for
+ o pcap - not much use for actual network connectivity, but great for
monitoring traffic on the host
Ethertap is available on 2.4 and works fine. TUN/TAP is preferred
exploit the helper's root privileges.
- 6\b6.\b.1\b1.\b. G\bGe\ben\bne\ber\bra\bal\bl s\bse\bet\btu\bup\bp
+ 6.1. General setup
First, you must have the virtual network enabled in your UML. If are
running a prebuilt kernel from this site, everything is already
- 6\b6.\b.2\b2.\b. U\bUs\bse\ber\brs\bsp\bpa\bac\bce\be d\bda\bae\bem\bmo\bon\bns\bs
+ 6.2. Userspace daemons
You will likely need the setuid helper, or the switch daemon, or both.
They are both installed with the RPM and deb, so if you've installed
- 6\b6.\b.3\b3.\b. S\bSp\bpe\bec\bci\bif\bfy\byi\bin\bng\bg e\bet\bth\bhe\ber\brn\bne\bet\bt a\bad\bdd\bdr\bre\bes\bss\bse\bes\bs
+ 6.3. Specifying ethernet addresses
Below, you will see that the TUN/TAP, ethertap, and daemon interfaces
allow you to specify hardware addresses for the virtual ethernet
sufficient to guarantee a unique hardware address for the device. A
couple of exceptions are:
- +\bo Another set of virtual ethernet devices are on the same network and
+ o Another set of virtual ethernet devices are on the same network and
they are assigned hardware addresses using a different scheme which
may conflict with the UML IP address-based scheme
- +\bo You aren't going to use the device for IP networking, so you don't
+ o You aren't going to use the device for IP networking, so you don't
assign the device an IP address
If you let the driver provide the hardware address, you should make
- 6\b6.\b.4\b4.\b. U\bUM\bML\bL i\bin\bnt\bte\ber\brf\bfa\bac\bce\be s\bse\bet\btu\bup\bp
+ 6.4. UML interface setup
Once the network devices have been described on the command line, you
should boot UML and log in.
- 6\b6.\b.5\b5.\b. M\bMu\bul\blt\bti\bic\bca\bas\bst\bt
+ 6.5. Multicast
The simplest way to set up a virtual network between multiple UMLs is
to use the mcast transport. This was written by Harald Welte and is
- 6\b6.\b.6\b6.\b. T\bTU\bUN\bN/\b/T\bTA\bAP\bP w\bwi\bit\bth\bh t\bth\bhe\be u\bum\bml\bl_\b_n\bne\bet\bt h\bhe\bel\blp\bpe\ber\br
+ 6.6. TUN/TAP with the uml_net helper
TUN/TAP is the preferred mechanism on 2.4 to exchange packets with the
host. The TUN/TAP backend has been in UML since 2.4.9-3um.
There are a couple potential problems with running the TUN/TAP
transport on a 2.4 host kernel
- +\bo TUN/TAP seems not to work on 2.4.3 and earlier. Upgrade the host
+ o TUN/TAP seems not to work on 2.4.3 and earlier. Upgrade the host
kernel or use the ethertap transport.
- +\bo With an upgraded kernel, TUN/TAP may fail with
+ o With an upgraded kernel, TUN/TAP may fail with
File descriptor in bad state
- 6\b6.\b.7\b7.\b. T\bTU\bUN\bN/\b/T\bTA\bAP\bP w\bwi\bit\bth\bh a\ba p\bpr\bre\bec\bco\bon\bnf\bfi\big\bgu\bur\bre\bed\bd t\bta\bap\bp d\bde\bev\bvi\bic\bce\be
+ 6.7. TUN/TAP with a preconfigured tap device
If you prefer not to have UML use uml_net (which is somewhat
insecure), with UML 2.4.17-11, you can set up a TUN/TAP device
there is no need for root assistance. Setting up the device is done
as follows:
- +\bo Create the device with tunctl (available from the UML utilities
+ o Create the device with tunctl (available from the UML utilities
tarball)
where uid is the user id or username that UML will be run as. This
will tell you what device was created.
- +\bo Configure the device IP (change IP addresses and device name to
+ o Configure the device IP (change IP addresses and device name to
suit)
- +\bo Set up routing and arping if desired - this is my recipe, there are
+ o Set up routing and arping if desired - this is my recipe, there are
other ways of doing the same thing
utility which reads the information from a config file and sets up
devices at boot time.
- +\bo Rather than using up two IPs and ARPing for one of them, you can
+ o Rather than using up two IPs and ARPing for one of them, you can
also provide direct access to your LAN by the UML by using a
bridge.
Note that 'br0' should be setup using ifconfig with the existing IP
address of eth0, as eth0 no longer has its own IP.
- +\bo
+ o
Also, the /dev/net/tun device must be writable by the user running
devices and chgrp /dev/net/tun to that group with mode 664 or 660.
- +\bo Once the device is set up, run UML with 'eth0=tuntap,device name'
+ o Once the device is set up, run UML with 'eth0=tuntap,device name'
(i.e. 'eth0=tuntap,tap0') on the command line (or do it with the
mconsole config command).
- +\bo Bring the eth device up in UML and you're in business.
+ o Bring the eth device up in UML and you're in business.
If you don't want that tap device any more, you can make it non-
persistent with
- 6\b6.\b.8\b8.\b. E\bEt\bth\bhe\ber\brt\bta\bap\bp
+ 6.8. Ethertap
Ethertap is the general mechanism on 2.2 for userspace processes to
exchange packets with the kernel.
- 6\b6.\b.9\b9.\b. T\bTh\bhe\be s\bsw\bwi\bit\btc\bch\bh d\bda\bae\bem\bmo\bon\bn
+ 6.9. The switch daemon
- N\bNo\bot\bte\be: This is the daemon formerly known as uml_router, but which was
+ Note: This is the daemon formerly known as uml_router, but which was
renamed so the network weenies of the world would stop growling at me.
- 6\b6.\b.1\b10\b0.\b. S\bSl\bli\bip\bp
+ 6.10. Slip
Slip is another, less general, mechanism for a process to communicate
with the host networking. In contrast to the ethertap interface,
- 6\b6.\b.1\b11\b1.\b. S\bSl\bli\bir\brp\bp
+ 6.11. Slirp
slirp uses an external program, usually /usr/bin/slirp, to provide IP
only networking connectivity through the host. This is similar to IP
- 6\b6.\b.1\b12\b2.\b. p\bpc\bca\bap\bp
+ 6.12. pcap
The pcap transport is attached to a UML ethernet device on the command
line or with uml_mconsole with the following syntax:
git.openpandora.org / pandora-kernel.git / commitdiff