Running UML (User Mode Linux)

patvdv — Fri, 20/06/2008 - 21:50

User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup. User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software.

Why use it

Above paragraph is an excerpt from the UML home page on SF. Personally I have started using UML to create sandbox environments that enable me to play around with different web/linux/distribution tools. The following paragraphs will describe the particular UML setup I am using.

UML setup

Preparing the system

1. Create the UML group

$ groupadd uml

2. Create the UML user:

$ useradd -m -g uml uml

3. Setup the UML repository structure under /home/uml:

$ mkdir -p /home/uml/fs/root_fs
$ mkdir -p /home/uml/fs/swap_fs
$ mkdir -p /home/uml/kernels
$ chown -R uml:uml /home/uml/fs /home/uml/kernels
$ chmod 2750 /home/uml/fs /home/uml/fs/root_fs /home/uml/fs/swap_fs /home/uml/kernels

4. Download the kernels and root_fs images from the UML home page (or other sites that make these available) and put them in the respective fs/root_fs and kernels directories. For example:

$ cd /home/uml/fs/root_fs
$ ls -l
-r--r----- 1 uml uml 1073742848 Jul 19 23:59 Debian-3.1-x86-root_fs
-r--r----- 1 uml uml 1610613760 Mar 21 01:44 FedoraCore5-x86-root_fs
-r--r----- 1 uml uml 2097742848 Jul 11 17:16 Gentoo-2006.0-x86-root_fs
-r--r----- 1 uml uml 1610613760 Jul 11 17:54 Mandriva-2006-x86-root_fs
-r--r----- 1 uml uml 2048000000 Jul 11 17:13 Ubuntu-Breezy-x86-root_fs

5. Create a default 256MB swap file system:

$ cd /home/uml/fs/swap_fs
$ dd if=/dev/zero of=25M6-swap_fs count=1 bs=1M seek=256
$ mkswap -f 256M-swap_fs
$ ls -l
-r--r----- 1 uml uml 269484032 Jul 17 09:01 256M-swap_fs

I am using separate swap file systems depending on the memory size allocated to an UML instance. By default I will use the swap file system that is at least double the size of the internal UML memory.

6. Set permissions on the root_fs images and UML kernels:

chmod 440 /home/fs/root_fs/*
chmod 440 /home/fs/swap_fs/*
chmod 440 /home/kernels/*

This will make sure that all system users that are part of the uml group are able to read the image files but not write to them! Instead of using the root_fs images to store UML data I use COW (Copy On Write) files (see below).

Creating the UML instance

I prefer to setup a new system user for each new UML instance and have the instance run under this user account. I do not use a chrooted environment even though that is also possible and documented. My experience with trying to run UML instances in a jailed environment has caused me too much grief and for making sandboxes security is not a major concern. Root jails have the massive drawback that all required device files, binaries and libraries must be present inside the actual new root environment. Making the required devices (such /dev/net/tun) and files available inside the jail is easily done by mounting them with the bind option. However, I have several times bumped into the situation whereby I remounted one of the required devices/files without unmounting them first. This painfully resulted in accidentally overwritten and thus zeroed root_fs images

Here are some pointers for setting up an UML instance in a jail:

Especially the umlazi tool looks interesting and I may give it a whirl in the future if diskspace is not a concern.

But let's continue with our non-chrooted UML setup:

1. Create the user account owning the UML instance and add it to the group uml:

$ useradd -m -g uml umltest

2. Set up the directory structure for the COW files and create them:

$ cd /home/umltest/
$ mkdir -p uml/root_fs.cow
$ uml_mkcow ./root_fs /home/uml/fs/root_fs/Debian-3.1-x86-root_fs
$ uml_mkcow ./swap_fs /home/uml/fs/swap_fs/256M-swap_fs

The COW files will be used to save any changes made inside the UML instance such as installing additional software, changing configuration files etc. The biggest advantage of using COW files is the possibility to share the original root_fs and swap_fs images as they are fully static in nature.

3. Set the correct ownerships and permissions:

chown -R uml:uml /home/umltest/uml
chmod 700 /home/umltest/uml
chmod 640 /home/umltest/uml/*

Configuring the UML instance

I use a couple of scripts to automatically stop and start any UML instance (see below). A configuration file detailing the required values to be used at UML start-up complements them. Create the configuration file as /home/<uml user>/uml/uml_config:

$ vi /home/umltest/uml/uml_config
#!/bin/bash
# Configuration file for the UML instance
 
# owner of UML instance
UML_OWNER="umltest"
 
# IP address of tap(x) interface on host side
TAP_IP="192.168.0.100"
 
# Path to read-only root fs
ROOT_FS="/home/uml/fs/root_fs/FedoraCore5-x86-root_fs"
 
# Path to read-only swap fs
SWAP_FS="/home/uml/fs/swap_fs/256M-swap_fs"
 
# Path to UML kernel
UML_KERNEL="/home/uml/kernels/linux-2.6.16"
 
# Size of UML memory
UML_MEM="128MB"
 
# Path to read-write root_fs COW file
COW_ROOT_FS="/home/${UML_OWNER}/uml/root_fs.cow"
 
# Path to read-write swap_fs COW file
COW_SWAP_FS="/home/${UML_OWNER}/uml/swap_fs.cow"
 
# Start UML detached or not? (yes/no). Default is 'no'
UML_DETACH="no"

The settings in the uml_config are pretty self-explanatory.

Note that the stop/start scripts I use come with some assumptions as to how the UML instance is set up:

only one UML instance per system user is supported
the UML networking uses TUN/TAP devices and the uml_net helper application for assigning the correct device settings. This requires the network command-line parameters at UML start-up not to include a TAP device specification, e.g.:

eth<n>=tuntap,,,<host IP address>

The uml_helper wil take care of all the required route and ARP settings after bringing up the network interface inside the UML instance. See the Virtual networking page on the UML site for more details.

Start/stop scripts

start_uml

Download start_uml.sh (shell script)

stop_uml

Download stop_uml.sh (shell script)

How to use the scripts

To start the UML instance run:

$ ./start_uml /home/umltest/uml/uml_config

To stop the UML instance use:

$ ./stop_uml umltest

Tips

How to check what instances are running?

Use the screen command to show a list of all screen sessions, as 'root' do:

$ screen -ls
There is a screen on:
        29237.umltest       (Detached)
1 Socket in /var/run/screens/S-root.

Why not run the screen session under the UML owner account?

That is possible but then you will struggle permission problems on the /dev/tty/pts devices, unless you log in directly onto the host OS as the user owning the UML instance. If you need to perform a 'su' first - which is applicable to me -, then permissions on the pts device will be too restrictive and the screen session will be unable to start. Setting very loose permissions on /dev/tty/pts is also not recommended to prevent snooping. Hence the option to allow the management of UML instances only by the system's 'root' user.

Bookmark/Search this post with: