4:12 p.m.
One user's feature request for our QEMU driver is to support serial ports.
Easy you might think... you'd be wrong :-)
On Xen we have very simple approach. When creating a guest simply add
<console/>
And it'll cause a serial port to be setup with an autoallocated pty, so
you get back
<console pty='/dev/pts/5'/>
In retrospect calling it 'console' was dumb, but hey we're stuck with that
now and its only a tiny naming issue so I don't mind really.
We can do the same thing with QEMU quite easily. QEMU, however, supports
many many many more ways to hooking up the serial port to Dom0. Indeed
so does Xen fullyvirt, but we don't expose this ability. Parallel ports
have identical config syntax to serial ports so we might as well deal
with both at once.
So, here's a stripped down version of the QEMU docs:
[quote http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC10]
`-serial dev'
Redirect the virtual serial port to host character device dev. The
default device is vc in graphical mode and stdio in non graphical
mode. This option can be used several times to simulate up to 4
serials ports. Use -serial none to disable all serial ports.
Available character devices are:
vc
Virtual console
pty
[Linux only] Pseudo TTY (a new PTY is automatically allocated)
none
No device is allocated.
null
void device
/dev/XXX
[Linux only] Use host tty, e.g. `/dev/ttyS0'. The host serial port
parameters are set according to the emulated ones.
/dev/parportN
[Linux only, parallel port only] Use host parallel port N. Currently
only SPP parallel port features can be used.
file:filename
Write output to filename. No character can be read.
stdio
[Unix only] standard input/output
pipe:filename
name pipe filename
COMn
[Windows only] Use host serial port n
udp:[remote_host]:remote_port[@[src_ip]:src_port]
This implements UDP Net Console.
tcp:[host]:port[,server][,nowait][,nodelay]
The TCP Net Console has two modes of operation.
telnet:host:port[,server][,nowait][,nodelay]
The telnet protocol is used instead of raw tcp sockets.
unix:path[,server][,nowait]
A unix domain socket is used instead of a tcp socket.
[/quote]
I don't see any reason to not support all/most of these options. The things
I don't like here is that /dev/XXX, vs /dev/parportN, vs COMn differences
for connecting guest <-> host passthrough of the devices. I figure it could
be simpler if it was just represented as 'n' and we'd translate that to
be /dev/ttyS[n] or /dev/parport[n] or COM[n] as needed.
The question as ever is how to represent this in XML. For serial ports we'll
stick with '<console>', while parallel ports we might as well use a better
named '<parallel>'. Next up, I think should use a 'type' attribute
on this
element to determine the main way ot connecting the device, and then more
type specific attributes or sub-elements as needed. If 'type' was not
specified then use a default of 'pty', since that gives compatability with
existing practice.
As an illustrative example
/*
* Parse the XML definition for a character device
*
* Top level node will be <console> or <parallel>, but all attributes
* and sub-elements are identical.
*
* type=vc|pty|null|host|file|pipe|udp|tcp|telnet, default is pty
*
* <console type='vc'/>
*
* <console type='pty' pty='/dev/pts/3'/>
*
* <console type='null'/>
*
* <console type='host' port='3'/>
*
* <console type='file' path='/some/file'/>
*
* <console type='pipe' path='/some/file'/>
*
* <console type='udp'>
* <sendto port='12356'/>
* </console>
*
* <console type='udp'>
* <sendto addr='127.0.0.1' port='12356'/>
* </console>
*
* <console type='udp'>
* <sendto addr='127.0.0.1' port='12356'/>
* <bind port='12356'/>
* </console>
*
* <console type='udp'>
* <sendto addr='127.0.0.1' port='12356'/>
* <bind addr='127.0.0.1' port='12356'/>
* </console>
*
* <console type='tcp'>
* <listen port='12356'/>
* </console>
*
* <console type='tcp'>
* <listen addr='127.0.0.1' port='12356'>
* <nowait/>
* <nodelay/>
* </listen>
* </console>
*
* <console type='tcp'>
* <connect addr='127.0.0.1' port='12356'>
* <nodelay/>
* </connect>
* </console>
*
* <console type='telnet'>
* <listen addr='127.0.0.1' port='12356'/>
* </console>
*
* <console type='telnet'>
* <connect addr='127.0.0.1' port='12356'/>
* </console>
*
*/
BTW, the udp, tcp, telnet options are only available on QEMU >= 0.9.0. We
already have ability to detect / validate that for both Xen & QEMU drivers.
NB, whereever there are IP addresses, hostnames can be used too, hence I
call the attriute 'addr' instead of 'ip'
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
2:12 a.m.
Hi Dan,
Looks fine to me ...
On Wed, 2007-05-16 at 22:12 +0100, Daniel P. Berrange wrote:
On Xen we have very simple approach. When creating a guest simply
add
<console/>
And it'll cause a serial port to be setup with an autoallocated pty, so
you get back
<console pty='/dev/pts/5'/>
In retrospect calling it 'console' was dumb, but hey we're stuck with that
now and its only a tiny naming issue so I don't mind really.
Why not add 'serial' with the new syntax, making <serial type='pty'
/>
equivalent to <console />, and continue supporting the existing
'console' syntax?
Cheers,
Mark.
6:25 a.m.
On Thu, May 17, 2007 at 08:12:55AM +0100, Mark McLoughlin wrote:
Hi Dan,
Looks fine to me ...
On Wed, 2007-05-16 at 22:12 +0100, Daniel P. Berrange wrote:
> On Xen we have very simple approach. When creating a guest simply add
>
> <console/>
>
> And it'll cause a serial port to be setup with an autoallocated pty, so
> you get back
>
> <console pty='/dev/pts/5'/>
>
> In retrospect calling it 'console' was dumb, but hey we're stuck with
that
> now and its only a tiny naming issue so I don't mind really.
Why not add 'serial' with the new syntax, making <serial type='pty'
/>
equivalent to <console />, and continue supporting the existing
'console' syntax?
I thought about this too, but given that it adds complexity to the XML, and
to the code & is a source of potential confusion, I just don't see that we
come out with a net win.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
3:58 a.m.
Hi,
The question as ever is how to represent this in XML. For serial
ports we'll
stick with '<console>', while parallel ports we might as well use a better
named '<parallel>'.
Hmm, I'd prefer to use '<serial>', much less confusing in the long run.
And maybe alias '<console>' to '<serial port=0>' for
compatibility.
Next up, I think should use a 'type' attribute on this
element to determine the main way ot connecting the device, and then more
type specific attributes or sub-elements as needed. If 'type' was not
specified then use a default of 'pty', since that gives compatability with
existing practice.
Also enumerate them somehow, so you can configure multiple of them.
NB, whereever there are IP addresses, hostnames can be used too,
hence I
call the attriute 'addr' instead of 'ip'
s/addr/host/ + s/port/service/ to make clear that non-numeric stuff is
accepted for both?
<serial type='udp' port='0'>
<sendto host='loghost' service='syslog'>
</serial>
cheers,
Gerd
2:18 p.m.
On Mon, May 21, 2007 at 10:58:02AM +0200, Gerd Hoffmann wrote:
Hi,
>The question as ever is how to represent this in XML. For serial ports
>we'll
>stick with '<console>', while parallel ports we might as well use a
better
>named '<parallel>'.
Hmm, I'd prefer to use '<serial>', much less confusing in the long run.
And maybe alias '<console>' to '<serial port=0>' for
compatibility.
There is actually one compelling reason to do this - the Xen paravirt
console really isn't a true serial port. It is just a dumb text console
driver, so perhaps it is better to distinguish <console> from <serial>
with this scenario. We already use <console> for HVM too though - so
perhaps we should say
- <parallel> - parallel ports
- <serial> - serial ports
- <console> - first text based virtual console channel
So, paravirt Xen would only ever have a <console> element. With fullyvirt
Xen the first <serial> port element would also be exposed as a <console>
element.
>Next up, I think should use a 'type' attribute on this
>element to determine the main way ot connecting the device, and then more
>type specific attributes or sub-elements as needed. If 'type' was not
>specified then use a default of 'pty', since that gives compatability with
>existing practice.
Also enumerate them somehow, so you can configure multiple of them.
Good point, better to have an explicit 'port' number attribute than
to rely on implict ordering of the devices in the XML, since there's
no other attribute in them giving uniqueness (cf device, or MAC in
disk or network).
>NB, whereever there are IP addresses, hostnames can be used too,
hence I
>call the attriute 'addr' instead of 'ip'
s/addr/host/ + s/port/service/ to make clear that non-numeric stuff is
accepted for both?
<serial type='udp' port='0'>
<sendto host='loghost' service='syslog'>
</serial>
Sounds reasonable.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
10:18 a.m.
On Mon, May 21, 2007 at 08:18:42PM +0100, Daniel P. Berrange wrote:
On Mon, May 21, 2007 at 10:58:02AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >The question as ever is how to represent this in XML. For serial ports
> >we'll
> >stick with '<console>', while parallel ports we might as well use
a better
> >named '<parallel>'.
>
> Hmm, I'd prefer to use '<serial>', much less confusing in the long
run.
> And maybe alias '<console>' to '<serial port=0>' for
compatibility.
There is actually one compelling reason to do this - the Xen paravirt
console really isn't a true serial port. It is just a dumb text console
driver, so perhaps it is better to distinguish <console> from <serial>
with this scenario. We already use <console> for HVM too though - so
perhaps we should say
- <parallel> - parallel ports
- <serial> - serial ports
- <console> - first text based virtual console channel
So, paravirt Xen would only ever have a <console> element. With fullyvirt
Xen the first <serial> port element would also be exposed as a <console>
element.
Sounds nice to me.
> >Next up, I think should use a 'type' attribute on
this
> >element to determine the main way ot connecting the device, and then more
> >type specific attributes or sub-elements as needed. If 'type' was not
> >specified then use a default of 'pty', since that gives compatability
with
> >existing practice.
>
> Also enumerate them somehow, so you can configure multiple of them.
Good point, better to have an explicit 'port' number attribute than
to rely on implict ordering of the devices in the XML, since there's
no other attribute in them giving uniqueness (cf device, or MAC in
disk or network).
> >NB, whereever there are IP addresses, hostnames can be used too, hence I
> >call the attriute 'addr' instead of 'ip'
>
> s/addr/host/ + s/port/service/ to make clear that non-numeric stuff is
> accepted for both?
>
> <serial type='udp' port='0'>
> <sendto host='loghost' service='syslog'>
> </serial>
Sounds reasonable.
BTW what's the status ? wondering :-)
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
10:25 a.m.
On Wed, May 30, 2007 at 11:18:46AM -0400, Daniel Veillard wrote:
On Mon, May 21, 2007 at 08:18:42PM +0100, Daniel P. Berrange wrote:
> On Mon, May 21, 2007 at 10:58:02AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > >The question as ever is how to represent this in XML. For serial ports
> > >we'll
> > >stick with '<console>', while parallel ports we might as well
use a better
> > >named '<parallel>'.
> >
> > Hmm, I'd prefer to use '<serial>', much less confusing in the
long run.
> > And maybe alias '<console>' to '<serial port=0>'
for compatibility.
>
> There is actually one compelling reason to do this - the Xen paravirt
> console really isn't a true serial port. It is just a dumb text console
> driver, so perhaps it is better to distinguish <console> from <serial>
> with this scenario. We already use <console> for HVM too though - so
> perhaps we should say
>
> - <parallel> - parallel ports
> - <serial> - serial ports
> - <console> - first text based virtual console channel
>
> So, paravirt Xen would only ever have a <console> element. With fullyvirt
> Xen the first <serial> port element would also be exposed as a
<console>
> element.
Sounds nice to me.
> > >Next up, I think should use a 'type' attribute on this
> > >element to determine the main way ot connecting the device, and then more
> > >type specific attributes or sub-elements as needed. If 'type' was
not
> > >specified then use a default of 'pty', since that gives
compatability with
> > >existing practice.
> >
> > Also enumerate them somehow, so you can configure multiple of them.
>
> Good point, better to have an explicit 'port' number attribute than
> to rely on implict ordering of the devices in the XML, since there's
> no other attribute in them giving uniqueness (cf device, or MAC in
> disk or network).
>
> > >NB, whereever there are IP addresses, hostnames can be used too, hence I
> > >call the attriute 'addr' instead of 'ip'
> >
> > s/addr/host/ + s/port/service/ to make clear that non-numeric stuff is
> > accepted for both?
> >
> > <serial type='udp' port='0'>
> > <sendto host='loghost' service='syslog'>
> > </serial>
>
> Sounds reasonable.
BTW what's the status ? wondering :-)
Lots of difficult bits, but I'm starting to get onto coding it. QEMU for
example doesn't have a a good way to tell you what tty it allocated so
you have to parse stdout to olook for 'char device directed to /dev/pts/4'
which is mildly evil. That said, we already do that evilness to figure
out the monitor tty, and it should be reliable once I figure out the right
algorithm :-)
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
8:01 a.m.
New subject: [Libvir] Re: RFC: Supporting serial & parallel ports for QEMU (and improving Xen)
Daniel P. Berrange wrote:
Lots of difficult bits, but I'm starting to get onto coding it.
Was this ever completed and merged? I don't see it documented at
http://libvirt.org/format.html
8:32 a.m.
New subject: [Libvir] Re: RFC: Supporting serial & parallel ports for QEMU (and improving Xen)
On Tue, Feb 26, 2008 at 08:01:11AM -0600, Charles Duffy wrote:
Daniel P. Berrange wrote:
>Lots of difficult bits, but I'm starting to get onto coding it.
Was this ever completed and merged? I don't see it documented at
http://libvirt.org/format.html
No, I never got a nice solution to the hard part of parsing QEMU's stdout
to extract the name of the /dev/pts/XXX files allocated. Once that's done
the rest is trivial.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
6113
days inactive
6399
days old
8 comments
5 participants
participants (5)
-
Charles Duffy -
Daniel P. Berrange -
Daniel Veillard -
Gerd Hoffmann -
Mark McLoughlin