1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
<TITLE>User Mode Linux HOWTO : Setting up serial lines and consoles</TITLE>
<LINK HREF="UserModeLinux-HOWTO-6.html" REL=next>
<LINK HREF="UserModeLinux-HOWTO-4.html" REL=previous>
<LINK HREF="UserModeLinux-HOWTO.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="UserModeLinux-HOWTO-6.html">Next</A>
<A HREF="UserModeLinux-HOWTO-4.html">Previous</A>
<A HREF="UserModeLinux-HOWTO.html#toc5">Contents</A>
<HR>
<H2><A NAME="input"></A> <A NAME="s5">5.</A> <A HREF="UserModeLinux-HOWTO.html#toc5">Setting up serial lines and consoles</A></H2>
<P>
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.</P>
<P>
You can attach them to host ptys, ttys, file descriptors, and ports.
This allows you to do things like
<UL>
<LI>have a UML console appear on an unused host console,
</LI>
<LI>hook two virtual machines together by having one attach to a pty and
having the other attach to the corresponding tty
</LI>
<LI>make a virtual machine accessible from the net by attaching a console
to a port on the host.
</LI>
</UL>
</P>
<P>
The general format of the command line option is <EM>device</EM>=<EM>channel</EM>.</P>
<P> </P>
<H2><A NAME="ss5.1">5.1</A> <A HREF="UserModeLinux-HOWTO.html#toc5.1">Specifying the device</A>
</H2>
<P>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.</P>
<P>
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.</P>
<P>
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:
<BLOCKQUOTE><CODE>
<PRE>
ssl=pty ssl0=tty:/dev/tty0 ssl1=tty:/dev/tty1
</PRE>
</CODE></BLOCKQUOTE>
The specificity of the device name is all that matters; order on the
command line is irrelevant.</P>
<H2><A NAME="ss5.2">5.2</A> <A HREF="UserModeLinux-HOWTO.html#toc5.2">Specifying the channel</A>
</H2>
<P>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.
<UL>
<LI>pseudo-terminals - <EM>device</EM>=pty
pts terminals - <EM>device</EM>=pts
<P>
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:
<UL>
<LI>screen /dev/pts/<EM>n</EM>
</LI>
<LI>screen /dev/tty<EM>xx</EM>
</LI>
<LI>minicom -o -p /dev/tty<EM>xx</EM> - minicom seems not able to handle pts
devices
</LI>
<LI>kermit - start it up, 'open' the device, then 'connect'
</LI>
</UL>
</P>
<P> </P>
</LI>
<LI>terminals - <EM>device</EM>=tty:<EM>tty device file</EM>
<P>
This will make UML attach the device to the specified tty (i.e
<BLOCKQUOTE><CODE>
<PRE>
con1=tty:/dev/tty3
</PRE>
</CODE></BLOCKQUOTE>
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.</P>
<P> </P>
</LI>
<LI>xterms - <EM>device</EM>=xterm
<P>
UML will run an xterm and the device will be attached to it.</P>
<P> </P>
</LI>
<LI>Port - <EM>device</EM>=port:<EM>port number</EM>
<P>
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:
<BLOCKQUOTE><CODE>
<PRE>
con1=port:9000
</PRE>
</CODE></BLOCKQUOTE>
Attaching all the serial lines to that port would be done similarly:
<BLOCKQUOTE><CODE>
<PRE>
ssl=port:9000
</PRE>
</CODE></BLOCKQUOTE>
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).</P>
<P>
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.</P>
<P>
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.</P>
<P> </P>
</LI>
<LI>already-existing file descriptors - <EM>device</EM>=<EM>file
descriptor</EM>
<P>
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:
<BLOCKQUOTE><CODE>
<PRE>
con0=fd:0,fd:1 con=pts
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P> </P>
</LI>
<LI>Nothing - <EM>device</EM>=<EM>null</EM>
<P>
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.</P>
<P> </P>
</LI>
<LI>None - <EM>device</EM>=<EM>none</EM>
<P>
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.</P>
</LI>
</UL>
</P>
<P>You can also specify different input and output channels for a device
by putting a comma between them:
<BLOCKQUOTE><CODE>
<PRE>
ssl3=tty:/dev/tty2,xterm
</PRE>
</CODE></BLOCKQUOTE>
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.</P>
<P>
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.</P>
<H2><A NAME="ss5.3">5.3</A> <A HREF="UserModeLinux-HOWTO.html#toc5.3">Examples</A>
</H2>
<P>There are a number of interesting things you can do with this
capability.</P>
<P>
First, this is how you get rid of those bleeding console xterms by
attaching them to host ptys:
<BLOCKQUOTE><CODE>
<PRE>
con=pty con0=fd:0,fd:1
</PRE>
</CODE></BLOCKQUOTE>
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:
<BLOCKQUOTE><CODE>
<PRE>
con1=tty:/dev/tty6
</PRE>
</CODE></BLOCKQUOTE>
You can attach two virtual machines together with what amounts to a
serial line as follows:</P>
<P>Run one UML with a serial line attached to a pty -
<BLOCKQUOTE><CODE>
<PRE>
ssl1=pty
</PRE>
</CODE></BLOCKQUOTE>
Look at the boot log to see what pty it got (this example will assume
that it got /dev/ptyp1).</P>
<P>Boot the other UML with a serial line attached to the corresponding
tty -
<BLOCKQUOTE><CODE>
<PRE>
ssl1=tty:/dev/ttyp1
</PRE>
</CODE></BLOCKQUOTE>
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.</P>
<HR>
<A HREF="UserModeLinux-HOWTO-6.html">Next</A>
<A HREF="UserModeLinux-HOWTO-4.html">Previous</A>
<A HREF="UserModeLinux-HOWTO.html#toc5">Contents</A>
</BODY>
</HTML>
|
