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
The ToDo list
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 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)
WVU 2002 (html)
Security Roundtable (html)
OLS 2002 slides
LWE 2005 slides
Fun and Games
Kernel Hangman
Disaster of the Month

Setting up serial lines and consoles

It is possible to attach UML serial lines and consoles to many types of host I/O channels by specifying them on the command line.

You can attach them to host ptys, ttys, file descriptors, and ports. This allows you to do things like

  • have a UML console appear on an unused host console,
  • hook two virtual machines together by having one attach to a pty and having the other attach to the corresponding tty
  • make a virtual machine accessible from the net by attaching a console to a port on the host.

The general format of the command line option is device=channel.

Specifying the device

Devices are specified with "con" or "ssl" (console or serial line, respectively), optionally with a device number if you are talking about a specific device.

Using just "con" or "ssl" describes all of the consoles or serial lines. If you want to talk about console #3 or serial line #10, they would be "con3" and "ssl10", respectively.

A specific device name will override a less general "con=" or "ssl=". So, for example, you can assign a pty to each of the serial lines except for the first two like this:

ssl=pty ssl0=tty:/dev/tty0 ssl1=tty:/dev/tty1
The specificity of the device name is all that matters; order on the command line is irrelevant.
Specifying the channel
There are a number of different types of channels to attach a UML device to, each with a different way of specifying exactly what to attach to.
  • pseudo-terminals - device=pty pts terminals - device=pts

    This will cause UML to allocate a free host pseudo-terminal for the device. The terminal that it got will be announced in the boot log. You access it by attaching a terminal program to the corresponding tty:

    • screen /dev/pts/n
    • screen /dev/ttyxx
    • minicom -o -p /dev/ttyxx - minicom seems not able to handle pts devices
    • kermit - start it up, 'open' the device, then 'connect'
  • terminals - device=tty:tty device file

    This will make UML attach the device to the specified tty (i.e

    con1=tty:/dev/tty3
    will attach UML's console 1 to the host's /dev/tty3). If the tty that you specify is the slave end of a tty/pty pair, something else must have already opened the corresponding pty in order for this to work.
  • xterms - device=xterm

    UML will run an xterm and the device will be attached to it.

  • Port - device=port:port number

    This will attach the UML devices to the specified host port. Attaching console 1 to the host's port 9000 would be done like this:

    con1=port:9000
    Attaching all the serial lines to that port would be done similarly:
    ssl=port:9000
    You access these devices by telnetting to that port. Each active telnet session gets a different device. If there are more telnets to a port than UML devices attached to it, then the extra telnet sessions will block until an existing telnet detaches, or until another device becomes active (i.e. by being activated in /etc/inittab).

    This channel has the advantage that you can both attach multiple UML devices to it and know how to access them without reading the UML boot log. It is also unique in allowing access to a UML from remote machines without requiring that the UML be networked. This could be useful in allowing public access to UMLs because they would be accessible from the net, but wouldn't need any kind of network filtering or access control because they would have no network access.

    If you attach the main console to a portal, then the UML boot will appear to hang. In reality, it's waiting for a telnet to connect, at which point the boot will proceed.

  • already-existing file descriptors - device=file descriptor

    If you set up a file descriptor on the UML command line, you can attach a UML device to it. This is most commonly used to put the main console back on stdin and stdout after assigning all the other consoles to something else:

    con0=fd:0,fd:1 con=pts
  • Nothing - device=null

    This allows the device to be opened, in contrast to 'none', but reads will block, and writes will succeed and the data will be thrown out.

  • None - device=none

    This causes the device to disappear. If you are using devfs, the device will not appear in /dev. If not, then attempts to open it will return -ENODEV.

You can also specify different input and output channels for a device by putting a comma between them:
ssl3=tty:/dev/tty2,xterm
will cause serial line 3 to accept input on the host's /dev/tty3 and display output on an xterm. That's a silly example - the most common use of this syntax is to reattach the main console to stdin and stdout as shown above.

If you decide to move the main console away from stdin/stdout, the initial boot output will appear in the terminal that you're running UML in. However, once the console driver has been officially initialized, then the boot output will start appearing wherever you specified that console 0 should be. That device will receive all subsequent output.

Examples
There are a number of interesting things you can do with this capability.

First, this is how you get rid of those bleeding console xterms by attaching them to host ptys:

con=pty con0=fd:0,fd:1
This will make a UML console take over an unused host virtual console, so that when you switch to it, you will see the UML login prompt rather than the host login prompt:
con1=tty:/dev/tty6
You can attach two virtual machines together with what amounts to a serial line as follows:
Run one UML with a serial line attached to a pty -
ssl1=pty
Look at the boot log to see what pty it got (this example will assume that it got /dev/ptyp1).
Boot the other UML with a serial line attached to the corresponding tty -
ssl1=tty:/dev/ttyp1
Log in, make sure that it has no getty on that serial line, attach a terminal program like minicom to it, and you should see the login prompt of the other virtual machine.
Hosted at SourceForge Logo