Site Home Page
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Compiling
Installation
Building filesystems
Troubles
User Contributions
Related Links
The ToDo list
Projects
Diary
Thanks
Contacts
Tutorials
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Virtual Networking
Management Console
Kernel Debugging
gprof and gcov
Running X
Diagnosing problems
Configuration
Installing Slackware
Porting UML
IO memory emulation
How you can help
Overview
Documentation
Utilities
Kernel bugs
Kernel projects
Screenshots
A virtual network
An X session
Transcripts
A login session
A debugging session
Slackware installation
Reference
Kernel switches
Slackware README
Papers
ALS 2000 paper (html)
ALS 2000 paper (TeX)
ALS 2000 slides
LCA 2001 slides
OLS 2001 paper (html)
OLS 2001 paper (TeX)
ALS 2001 paper (html)
ALS 2001 paper (TeX)
UML security (html)
LCA 2002 (html)
Fun and Games
Kernel Hangman
Disaster of the Month

What are people using it for?

Kernel development and debugging
This kernel allows developers to write and debug code using the normal process-level tools, like gdb, gprof, and gcov. Also, developers who are away from their normal environment can carry on development, using a UML virtual machine as their kernel testing box. There is more information here on building this kernel from source and debugging it, plus a debugging session transcript.
Process debugging
Perhaps surprisingly, UML is also occasionally useful for debugging user-level processes. Ever get a odd error from a system call and have no idea why it's happening, either because there are a dozen reasons that errno could be returned and the documentation doesn't list the one you're hitting or, according to the documentation, the errno is completely inexplicable? Well, fire up UML, set a breakpoint on the system call in question, run your program, and you'll see very quickly why it's failing.
Safely playing with the latest kernels
Since the user-mode kernel is not running directly on the hardware, it has no access to it unless you provide it. So, if the kernel contains any nasty bugs, like file corruption bugs, it can't hurt any data that you care about.
Trying out new distributions
Its filesystems are contained in files in the underlying filesystem, so any time you want to boot a new distribution, you only need to dedicate a file to it, not an entire disk partition. The project download page has a number of ready-to-go root filesystems loaded with various distributions, including SuSE, Slackware, Debian, and Red Hat.
Education
UML is a great teaching tool, especially in courses where students need a dedicated machine in order to get the most out of it. I know that UML is being used to teach OS development, network administration, and more general system administration. These are all cases where having a virtual machine to practice on is far more convenient for everyone than using physical boxes.
Experimental development
The kernel runs in a virtual machine that can be configured in ways that your physical machine can't. It can have more memory, more devices, and, soon, more processors. So you can do development and testing of hardware capabilities even when you don't have the relevant hardware.
Poking around inside a running system
Since you have a full OS running outside the user-mode kernel, it's pretty easy for the terminally curious to find ways of looking inside this kernel that are impossible for a native kernel.
As a secure sandbox or jail
Processes inside the user-mode kernel have no access to the hosting machine or to the outside world that's not explicitly provided. So, a malicious application running inside it can do no harm to anything that matters. Should viruses like those now plaguing other, inferior operating systems ever start appearing on Linux, the environment provided by this kernel can provide pretty solid protection against them.
Virtual networking
UML virtual machines are networkable, to each other, to the host, and to other physical machines. So, UML can be used to set up a virtual network that allows setting up and testing of experimental services. See the networking tutorial and virtual network screenshot for more information.
As a test environment
Testing of some types of software requires booting up a machine. With UML, this can be very easily automated. There is a small test harness available , consisting of a small perl module implementing a UML object which provides methods to boot a virtual machine, log in to it, run commands, and shut it down.
Disaster recovery practice
Do you know what you would do if your machine suddenly didn't boot one day? With UML, you can set up virtual disasters and practice recovering from them. This doesn't have to be serious business - it can also be fun. Ever wonder what happens when you run
rm -rf /
but been afraid to try it? Now you can with impunity.
A Linux environment for other operating systems
This is more a potential use, since UML only runs on Linux right now. But once it's ported to another OS, it is a completely authentic Linux environment - it will run any Linux executable. This would be an interesting shortcut for an OS vendor looking for Linux binary compatibility.
See the
projects page for more information on porting UML to other operating systems.
Virtual hosting
Another potential use - I don't know of anyone who's doing this. UML provides a fine environment for virtual hosting. Just give each user a virtual machine and the root password, and they can do whatever they want inside it without bothering anyone else.
It doesn't need to be good for anything. It's fun!
Hosted at SourceForge Logo