[Libvir] RFC: Supporting serial & parallel ports for QEMU (and improving Xen)

[Daniel P. Berrange]

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  -=|