[Libvir] RFC: Supporting serial & parallel ports for QEMU (and improving Xen)
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 -=|
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.
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 -=|
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
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 -=|
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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 -=|
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
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 -=|
participants (5)
-
Charles Duffy -
Daniel P. Berrange -
Daniel Veillard -
Gerd Hoffmann -
Mark McLoughlin