User-mode Linux on host "gateway"

The Project

Create a fast-startup, fast-teardown User-Mode Linux machine environment for users and students where they:

  • Have full root access to the machine,
  • Have access to their own system home directory as themselves (i.e., not as root),
  • Can install new software packages as they choose,
  • Can run servers on restricted ports (e.g., web servers),
  • Have full, transparent network access (i.e, no NAT).

User-Mode Linux (UML) uses a special Linux kernel built from standard Linux kernel source code. This kernel won't boot on physical or virtial hardware, but instead runs from the command line or from a script as a standard program under Linux.

Once started, the UML instance operates like a real Linux system. It can run web servers, database servers, SSH servers, X servers (and, therefore, XFCE4, Gnome, KDE, FVWM, etc., and LibreOffice, FireFox, Chromium, etc.) and so on, just like the real thing because it basically is the real thing.


We use a custom UML kernel where each running instance operates in a copy-on-write gaol created inside a btrfs filesystem. The gaol content comes, in the first instance, from archlinux subdirectory in the same btrfs filesystem.

The contents of this archlinux subdirectory are rsync'ed from an auto-updating ArchLinux master system at intervals.

This means that users inside one of the UML systems have apparent root access inside the machine, but when they change anything a separate copy(-on-write) instance of whatever-it-is is created both for security (so no user can change the master files) and for speed (of initially setting up the gaol).

Create btrfs filesystem and mount at /uml so we can use btrfs' clone-on-write via /bin/cp's --reflink option.

Create /uml/archlinux for the copy of the ArchLinux filesystem from the master system (runs on QEMU/KVM on vmfram5 [sic]). This is copied/updated using rsync.

Create /uml/bin for scripts, etc., including:

  • /uml/bin/startenv - run inside the gaol, this scripts sets up /proc, /dev, etc.; starts /usr/bin/haveged (to feed the kernel's random number generator code because without haveged bits of entropy get generated really slowly and sshd takes a very long time to start), /usr/bin/dhclient (so the virtual machine can get an IPv4 address) and /usr/bin/sshd with a custom /etc/ssh/sshd_configfile.