What is it?

UML (User Mode Linux) is sort of like an emulator. It's a tiny little self-contained Linux system that runs as a normal user process.

UML is a standard Linux kernel configured to run as a normal user process. Instead of booting up and talking directly to hardware, it runs as a process and its device drivers use the C library and standard system calls to ask the parent system for anything (memory, network, disk I/O) it needs. (The UML process then hands out memory and timeslices to any child processes it starts, and handles all their system calls.)

Why is it cool?

UML gives a normal user the ability to run programs with simulated root access, and in the virtual environment perform loopback mounts, chroot, create device nodes, change file ownership, and so on. This can be used as a more powerful replacement for packages like "fakeroot", as a way to experiment with system administration without screwing up your real system, as a security measure further isolating different users' processes from each other on a common server, as an administrator tool grouping different processes at different "nice" levels and allowing hard limits on physical memory usage...

UML lets kernel developers test changes to the Linux kernel without rebooting all the time. Just build a UML, run it, and try out the change. UML has its own process scheduler, I/O scheduler, page tables, filesystems, network stack, virtual memory, software suspend, and so on. You can even stick "printf" calls into this kernel to see what it's doing, just as with any other user space program. (It's not quite as good for debugging device drivers: configuring a UML instance to talk directly to the hardware is possible, but is an advanced feature we won't talk about here.)

UML also has features such as "copy on write" partitions. In addition to the ability to treat any normal file on the host system as a block device using the User Block Device (UBD) driver, UML can be configured to save any changes made to a given block device into a separate file, allowing several UML instances to share the same block device while keeping their changes to it (if any) separate.

For normal users, UML is extremely easy to get started with. If you can compile a kernel, you can run UML.

Quick Start

The following creates a fairly minimalistic User Mode Linux kernel, builds it, and runs it. It gives you a shell prompt where the shell process is running inside UML.

The easy way to run UML is to mounts the existing Linux filesystem to be the User Mode Linux system's root filesystem as well. (This way we don't have to set up a special root directory to try out hostfs, we just borrow the existing one from the host system.)

Feel free to switch on more features and rebuild. "make ARCH=um menuconfig" works. The above configuration includes loopback mount and EXT2 support, which gives you some fully writeable space. (Note if you run UML as a normal user, you can't do anything to the hostfs mount you couldn't do as the user running UML, so things like chown will give you an error even as root. The hostfs mount is more like a network mount with restricted permissions than normal fully writeable space. Inside a loopback mount, you have normal fully writeable space to play with.

The UBD driver is another way to get fully writeable space, associating a host file with a UML block device (/dev/ubda is major 98 minor 0, see www.lanana.org for details). If you use UBD as your root device then you may not need hostfs at all (and since a UBD is not a loopback device, you can stick a swap partition on it if you enable swap in menuconfig). This lets you play with software suspend, and yes you can then save the resulting kernel, UBD file, and swap partition and resume from them at will later.

Note: if you run UML as root and share the existing Linux system's rootfs via hostfs, it will be normal fully writeable space. This can cause problems. For example, if your host system uses an old version of the mount command that maintains an mtab file (instead of the modern way, where /etc/mtab is a symlink to /proc/mounts), then running mount inside UML will modify /etc/mtab for the host system as well. You probably don't want to do this.