[Libvir] RFC: Supporting serial & parallel ports for QEMU (and improving Xen)
by 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 -=|
16 years, 10 months
[Libvir] Extending libvirt to probe NUMA topology
by Ryan Harper
Hello all,
I wanted to start a discussion on how we might get libvirt to be able to
probe the NUMA topology of Xen and Linux (for QEMU/KVM). In Xen, I've
recently posted patches for exporting topology into the [1]physinfo
hypercall, as well adding a [2]hypercall to probe the Xen heap. I
believe the topology and memory info is already available in Linux.
With these, we have enough information to be able to write some simple
policy above libvirt that can create guests in a NUMA-aware fashion.
I'd like to suggest the following for discussion:
(1) A function to discover topology
(2) A function to check available memory
(3) Specifying which cpus to use prior to domain start
Thoughts?
1. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00298.html
2. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00299.html
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
ryanh(a)us.ibm.com
17 years, 3 months
[Libvir] [PATCH] check the file name for --log
by Atsushi SAKAI
Hi,
This patch fixes the trouble if execute virsh with
virsh --log --debug.
In this case FILE "--debug" is generated and
--debug is off.
This patch treat as error return
if it uses the hyphen "-" at the head of log file name.
Signed-off-by: Atsushi SAKAI <sakaia(a)jp.fujitsu.com>
Thanks
Atsushi SAKAI
17 years, 4 months
[Libvir] [PATCH] check file format in virsh attach/detach-device
by Masayuki Sunou
Hi
virsh attach/detach-devich does not check file format now.
This patch checks config file format is XML or not.
(in virsh attach/detach-device)
If file format is not XML, just return the error with message.
Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com>
Atsushi SAKAI <sakaia(a)jp.fujitsu.com>
Thanks,
Masayuki Sunou.
17 years, 4 months
[Libvir] Exporting calls just to libvirtd
by Richard W.M. Jones
With the two patches[1][2] I recently posted, the remote driver has
started to make calls more directly into the drivers. Calls like
driver->domainMigratePrepare in [2] are exposed to the remote driver,
but shouldn't be exported for public use.
However because libvirtd links to regular libvirt.so, the calls actually
do need to be exported, so we export them as __virDomainMigratePrepare
(etc) with the double underscore and exclusion from <libvirt.h>
indicating that users of the published libvirt API should not call them.
It seems we could avoid exporting them entirely with one of these methods:
(a) Link libvirtd to the static libvirt.a.
-- Probably violates a load of distro policy and removes some supposed
benefits of dynamic linking.
(b) Build a separate shared library with a different dynamic symbol table.
-- Also removes one benefit of dynamic linking, because the two
libraries are different despite having the same code in them.
Any ideas if some advanced feature of ELF offers a way out here?
Rich.
[1]https://www.redhat.com/archives/libvir-list/2007-July/msg00444.html
[2]https://www.redhat.com/archives/libvir-list/2007-July/msg00357.html
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
17 years, 5 months
[Libvir] PATCH: Check for bogus default architecture
by Daniel P. Berrange
There was a missing check in the QEMU driver for a bogus architecture in
the XML which could cause a crash. This wasn't a problem except for the
fact that another bug in my recent virt-install 0.200.0 release passed a
bogus architecture on 32-bit platforms :-(
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 -=|
17 years, 5 months
[Libvir] PATCH: Overhaul the test driver
by Daniel P. Berrange
The test driver has suffered from quite alot of bitrot. Its got all sorts
of checks in the driver entry points already done by libvirt.c, its got
private data, redundantly pointing to private data, it doesn't implement
any of the networking APIs, is missing alot of the newer domain APIs. So
I've given it a thorough overhaul to remove alot of redundant code, clean
up more, and add entry points for all the APIs except for VCPU pinning ones.
The addition of the networking APIs means we no longer get errors thrown
when trying to run tests without the libvirt daemon running, and means apps
can actually do tests for their networking capabilities.
docs/testnetdef.xml | 12
docs/testnetpriv.xml | 11
docs/testnode.xml | 2
src/driver.h | 1
src/libvirt.c | 17
src/qemu_driver.c | 1
src/remote_internal.c | 1
src/test.c | 1892 +++++++++++++++++++++++++++++++-------------------
tests/virshtest.c | 465 +++---------
9 files changed, 1382 insertions(+), 1020 deletions(-)
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 -=|
17 years, 5 months
[Libvir] PATCH Fix a couple of mem leaks
by Daniel P. Berrange
I ran 'make valgrind' for the first time in too long and found a hanful of
memory leaks in code exercised by the test suite. The attached patch fixes
them all.
I'm sure there are more lurking though - the test suite is mainly focused
on exercising & validating correctness of parsing routines - its not really
tried doing any validation of failure scenaarios. So I fear there's probably
a number of error code paths where we don't cleanup properly, and/or don't
reject invalid data. Its an area which should be addressed by someone with
some copious free time ;-)
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 -=|
17 years, 5 months
[Libvir] PATCH 0/2: Capabilities and features
by David Lutterkort
Hi,
these two patches extend the features libvirt reports in the
capabilities XML; in particular, features are now reported for the QEMU
driver, and features for both Xen and QEMU include information on
ACPI/APIC support.
Tools that rely on feature reporting, in general, need to know whether a
certain feature is on or off by default, and whether that can be
toggled, because users will be asking for one of three things for their
VM:
* Feature X (e.g., ACPI) must be on/present in the VM
* Feature X must not be on/present in the VM
* It doesn't matter whether feature X is there or not
For example, in QEMU, ACPI is on by default, but can be turned off. The
APIC on the other hand, is always there and can't be turned off. That is
now reported as
<features>
<acpi default="on" toggle="yes"/>
<apic default="on" toggle="no"/>
</features>
It's unfortunate that the format for PAE (<pae/> vs. <nonpae/>)
reporting doesn't fit into this scheme. I didn't want to start with
having tags <X/> and <nonX/> for each feature; that means that parsers
need to special case PAE. It's probably too late, but it would be nice
if PAE was reported in a similar format, with <pae> correponding to <pae
default="on" toggle="no"/>, <nonpae/> corresponding to <pae
default="yes" toggle="no"/>, and having both together corresponding to
<pae default="yes" toggle="yes"/>, but that's a separate discussion from
these patches.
David
17 years, 5 months
