At this point, we've seen a UML from both the inside and the outside. We've seen how a UML can use host resources for its hardware and how it's confined to whatever has been provided to it.
A UML is both very similar to and very different from a physical machine. It is similar as long as you don't look at its hardware. When you do, it becomes clear that you are looking at a virtual machine with virtual hardware. However, as long as you stay away from the hardware, it is very hard to tell that you are inside a virtual machine.
Both the similarities and the differences have advantages. Obviously, having a UML run applications in exactly the same way as on the host is critical for it to be useful. In this chapter we glimpsed some of the advantages of virtual hardware. Soon we will see that virtualized hardware can be plugged, unplugged, extended, and managed in ways that physical hardware can't. The
Chapter 3. Exploring UML
Logging In as a Normal User
Consoles and Serial Lines
Adding Swap Space
UML Disks as Raw Data
Logging In as a Normal
Consoles and Serial Lines
In addition to the
UML% dmesg grep "Serial line" Serial line 0 assigned device '/dev/pts/13'
Now we can run a terminal program, such as
host% screen /dev/pts/13
we see a blank screen session.
Debian GNU/Linux 2.2 usermode ttyS0 usermode login:
in the banner, in comparison to the
we saw while logging in as root in the previous chapter and the
we just saw while logging in as
In contrast, there is almost no difference between the consoles and serial lines in UML. They plug themselves into the console and serial line
In fact, the serial line driver in UML owes its existence to a historical quirk. Because of a limitation in the first implementation of UML, it was
As time went on and limitations disappeared, I implemented a real console driver. After a while, it dawned on me that there was no real difference between it and the serial line driver, so I started merging the two drivers, making them share more and more code. Now almost the only differences between them are that they plug themselves into different
UML consoles and serial lines can be attached to the same devices on the host, and we've seen a console attached to
Finally, UML consoles and serial lines can be attached to host terminals, which can be host consoles, such as
, or the slave side of pseudo-terminals. Attaching a UML console to a host virtual console has the interesting effect of
Let's look at some examples. First, let's attach a console to a host port. We need to find an unused console to work with, so let's use the UML management console tool to query the UML configuration:
host% uml_mconsole debian config con0 OK fd:0,fd:1 host% uml_mconsole debian config con1 OK none host% uml_mconsole debian config con2 OK pts:/dev/pts/10 host% uml_mconsole debian config con3 OK pts
We will cover the full capabilities of
in Chapter 8, but this gives us an initial look at it. The first argument,
, specifies which UML we wish to talk to. A UML can be named and given a unique machine ID, or
. When I ran this UML, I added
to the command line, giving this instance the
If you didn't specify the umid on the command line, UML gives itself a random umid . There are a couple of ways to tell what it chose. First, look through the boot output or output from dmesg for a line that looks like this:
mconsole (version 2) initialized on /home/jdike/.uml/3m3vDd/mconsole
In this case, the umid is 3m3vDd . You can communicate with this instance by using that umid on the uml_mconsole command line.
Second, UML puts a directory with the same name as the umid in a special parent directory, by default, ~/.uml . So, you could also look at the subdirectory  of your ~/.uml directory for the umid to use.
The rest of the uml_mconsole command line is the command to send to the specified UML. In this case, we are asking for the configurations of the first few consoles. Console names start with con ; serial line names begin with ssl .
I will describe as much of the output format as needed here; Figure 3.1 contains a more complete and careful description.
Figure 3.1. Detailed description of UML console and serial line configuration
Looking at the output about the UML configuration, we see an OK on each response, which means that the command succeeded in communicating with the UML and getting a response. The con0 response says that console 0 is attached to stdin and stdout . This bears some explaining, so let's pull apart that response. There are two pieces to it, fd:0 and fd:1 , separated by a comma. In a comma-separated configuration like this, the first part refers to input to the console (or serial line), and the second part refers to output from it.
The fd:0 part also has two pieces, fd and 0, separated by a colon. fd says that the console input is to be attached to a file descriptor of the linux process, and says that file descriptor will be stdin , file descriptor zero. Similarly, the output is specified to be file descriptor one, stdout .
When the console input and output go to the same device, as we can see with
being attached to
, input and output are not specified separately. There is only a single colon-separated device description. As you might have guessed,
refers to a
The con1 configuration is one we haven't seen before. It simply says that the console doesn't existthere is no such device.
The configuration for
is the one we are looking for.
says that this is a
console, and there's no specific
device listed, so it has not yet been activated by having a UML
host% uml_mconsole debian config con3=port:9000 OK
port:9000 says that the console should be attached to the host's port 9000, which we will access by telnetting to that port.
host% uml_mconsole debian config con3 OK port:9000
So far, so good. Let's try telnetting there now:
host% telnet localhost 9000 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused
This failed because UML hasn't run a getty on its console 3. We can fix this by editing its /etc/inittab . Looking there on my machine, I see:
#3:2345:respawn:/sbin/getty 38400 tty3
I had enabled this one in the past but since disabled it. You may not have a tty3 entry at all. You want to end up with a line that looks like this:
3:2345:respawn:/sbin/getty 38400 tty3
I'll just uncomment mine; you may have to add the line in its entirety, so fire up your favorite editor on /etc/inittab and fix it. Now, tell init it needs to reread the inittab file:
UML# kill -HUP 1
Let's go back to the host and try the telnet again:
host% telnet localhost 9000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Fedora Core release 1 (Yarrow) Kernel 2.4.27 on an i686 Debian GNU/Linux 2.2 usermode tty3 usermode login:
Here we have the UML's console, as advertised. Notice the discrepancy between the telnet banner and the login banner. Telnet is telling us that we are attaching to a Fedora Core 1 (FC1) system running a 2.4.27 kernel, while login is saying that we are attaching to a Debian system. This is because the host is the FC1 system, and telnetd running on the host and attaching us to the host's port 9000 is telling us about the host. There is some abuse of telnetd 's capabilities going on in order to allow the redirection of traffic between the host port and UML, and this is responsible for the confusion.
Now, let's stick a UML console on a host console. First, we need to make sure there's no host getty or login running on the
for the last console, and hitting Ctrl-Alt-F6 to switch to that virtual console confirms that a getty is running on it. I'll comment it out, so it looks like this:
I tell init to reread inittab :
host# kill -HUP 1
and switch back to that console to make sure it is not being used by the host any more. I now need to make sure that UML can
host% ls -l /dev/tty6 crw------ 1 root root 4, 6 Feb 17 16:26 /dev/tty6
This not being the case, I'll change the permissions so that UML has both read and write access to it:
host# chmod 666 /dev/tty6
After you make any similar changes needed on your own machine, we can tell UML to take over the console. We used the UML tty3 for the host port console, so let's look at tty4 :
host% uml_mconsole debian config con4 OK pts
So, let's assign con4 to the host's /dev/tty6 in the usual way:
host% uml_mconsole debian config con4=tty:/dev/tty6 OK
After enabling tty4 in the UML /etc/inittab and telling init to reread the file, we should be able to switch to the host's virtual console 6 and see the UML login prompt. Taken to extremes, this can be somewhat mind bending. Applying this technique to the other virtual con soles results in them all displaying UML, not host, login prompts.
For the security conscious, this
Now that we've seen all the ways to access our UML console, it's time to stay logged in on the console and see what we can do inside the UML.