Site Home Page
The UML Wiki
UML Community Site
The UML roadmap
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Compiling
Installation
Skas Mode
Incremental Patches
Test Suite
Host memory use
Building filesystems
Troubles
User Contributions
Related Links
Projects
Diary
Thanks
Contacts
Tutorials
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Resizing filesystems
Virtual Networking
Management Console
Kernel Debugging
UML Honeypots
gprof and gcov
Running X
Diagnosing problems
Configuration
Installing Slackware
Porting UML
IO memory emulation
UML on 2G/2G hosts
Adding a UML system call
Running nested UMLs
How you can help
Overview
Documentation
Utilities
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)
WVU 2002 (html)
Security Roundtable (html)
OLS 2002 slides
LWE 2005 slides
Fun and Games
Kernel Hangman
Disaster of the Month

The Management Console

The UML management console is a low-level interface to the kernel, somewhat like the i386 SysRq interface. Since there is a full-blown operating system under UML, there is much greater flexibility possible than with the SysRq mechanism.

There are a number of things you can do with the mconsole interface:

  • get the kernel version
  • add and remove devices
  • halt or reboot the machine
  • send SysRq commands
  • pause and resume the UML
  • make online backups without shutting down the UML
  • receive notifications of events of interest from within UML
  • monitor the internal state of the UML

You need the mconsole client (uml_mconsole) which is present in CVS (/tools/mconsole) in 2.4.5-9um and later, and will be in the RPM in 2.4.6.

You also need CONFIG_MCONSOLE (under 'General Setup') enabled in UML. When you boot UML, you'll see a line like:

              mconsole initialized on /home/jdike/.uml/umlNJ32yL/mconsole
            
If you specify a unique machine id one the UML command line, i.e.
umid=debian
you'll see this
              
mconsole initialized on /home/jdike/.uml/debian/mconsole

            
That file is the socket that uml_mconsole will use to communicate with UML. Run it with either the umid or the full path as its argument:
host% uml_mconsole debian
or
host% uml_mconsole /home/jdike/.uml/debian/mconsole
You'll get a prompt, at which you can run one of these commands:
  • version
  • halt
  • reboot
  • config
  • remove
  • sysrq
  • help
  • cad
  • stop
  • go
  • log
  • proc
version
This takes no arguments. It prints the UML version.
                
(mconsole)  version
OK Linux usermode 2.4.5-9um #1 Wed Jun 20 22:47:08 EDT 2001 i686

              
There are a couple actual uses for this. It's a simple no-op which can be used to check that a UML is running. It's also a way of sending an interrupt to the UML. This is sometimes useful on SMP hosts, where there's a bug which causes signals to UML to be lost, often causing it to appear to hang. Sending such a UML the mconsole version command is a good way to 'wake it up' before networking has been enabled, as it does not do anything to the function of the UML.
halt and reboot
These take no arguments. They shut the machine down immediately, with no syncing of disks and no clean shutdown of userspace. So, they are pretty close to crashing the machine.
                
(mconsole)  halt
OK

              
config
"config" adds a new device to the virtual machine or queries the configuration of an existing device.

Currently the ubd and network drivers support pulling devices. It takes one argument, which is the device to add, with the same syntax as the kernel command line.

                
(mconsole)  
config ubd3=/home/jdike/incoming/roots/root_fs_debian22

OK
(mconsole)  config eth1=mcast
OK

              
Querying the configuration of a device is handy when you don't know before the boot what host device the UML device will attach to. This is a problem with attaching consoles and serial lines to host pty or pts devices. You have no way of knowing how to access them without parsing the kernel messages. So, the syntax for this is the same as above, except you don't specify a configuration
                
(mconsole)  config ssl0
OK pty:/dev/ptyp0
(mconsole)  config ubd0
OK /home/jdike/roots/cow.debian,/home/jdike/roots/debian_22

              
This is supported by the console, serial line, and ubd drivers. As yet, the network drivers don't support this.
remove
"remove" deletes a device from the system. Its argument is just the name of the device to be removed. The device must be idle in whatever sense the driver considers necessary. In the case of the ubd driver, the removed block device must not be mounted, swapped on, or otherwise open, and in the case of the network driver, the device must be down.
                
(mconsole)  remove ubd3
OK
(mconsole)  remove eth1
OK

              
sysrq
This takes one argument, which is a single letter. It calls the generic kernel's SysRq driver, which does whatever is called for by that argument. See the SysRq documentation in Documentation/sysrq.txt in your favorite kernel tree to see what letters are valid and what they do.
help
"help" returns a string listing the valid commands and what each one does.
cad
This invokes the Ctl-Alt-Del action on init. What exactly this ends up doing is up to /etc/inittab. Normally, it reboots the machine. With UML, this is usually not desired, so if a halt would be better, then find the section of inittab that looks like this
                
# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

              
and change the command to halt.
stop
This puts the UML in a loop reading mconsole requests until a 'go' mconsole command is recieved. This is very useful for making backups of UML filesystems, as the UML can be stopped, then synced via 'sysrq s', so that everything is written to the filesystem. You can then copy the filesystem and then send the UML 'go' via mconsole.

Note that a UML running with more than one CPU will have problems after you send the 'stop' command, as only one CPU will be held in a mconsole loop and all others will continue as normal. This is a bug, and will be fixed.

go
This resumes a UML after being paused by a 'stop' command. Note that when the UML has resumed, TCP connections may have timed out and if the UML is paused for a long period of time, crond might go a little crazy, running all the jobs it didn't do earlier.
log
This takes a string as its argument, and will cause the UML to printk the string so that it ends up in the kernel message log. This is intended for use in honeypots by allowing the UML-specific stuff in the kernel log to be replaced with messages that don't expose the machine as being a UML.
proc
This takes a filename as its argument. It will return the contents of the corresponding /proc file inside the UML. Example:
(mconsole) proc uptime
will return the contents of the UML's /proc/uptime.
Making online backups
It is possible to make a backup of a UML's data without shutting it down. The idea is to pause it, make it flush out its data, copy the filesystem to a safe place, and then resume it. This should usually take seconds, while shutting down and rebooting the UML could take minutes. The exact procedure is this:
(mconsole) stop
(mconsole) sysrq s
host% # Copy the UML's filesystem someplace safe
(mconsole) go
By causing UML to flush its data out to disk, the 'sysrq s' will cause the filesystem to be a clean image. Of course, no guarantees are made for process data which hadn't been written back to the kernel, but the filesystem itself won't need an fsck if it's booted.
Event notification
The mconsole interface also provides a mechanism for processes inside a UML to send messages to an mconsole client on the host. The procedure is this:
  • Create a unix socket and pass that to UML on the command line as the mconsole notification socket
    mconsole=notify:socket
  • A /proc/mconsole file will be created inside UML
  • Anything that is written to it will be turned into an mconsole notification which your mconsole client should be listening for on the notification socket
A common use for this mechanism is to have an rc script inside UML send a message out that the UML has booted to a certain stage, and that something on the host which depends on that can proceed. However, this is a completely general mechanism which can be used to communicate any information at all to the host.

There is a demo mconsole notification client in the utilities tarball in mconsole/notify.pl. This is only a demo, and as such, isn't very useful by itself. It should be customized to fit into whatever environment you are setting up.

Hosted at SourceForge Logo