July 2007 - Devel - libvirt List Archives

[Libvir] RFC: Supporting serial & parallel ports for QEMU (and improving Xen)
by Daniel P. Berrange 26 Feb '08

26 Feb '08

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

5 8

[Libvir] Extending libvirt to probe NUMA topology
by Ryan Harper 11 Sep '07

11 Sep '07

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

5 13

[Libvir] [PATCH] check the file name for --log
by Atsushi SAKAI 20 Aug '07

20 Aug '07

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

4 8

[Libvir] [PATCH] check file format in virsh attach/detach-device
by Masayuki Sunou 02 Aug '07

02 Aug '07

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.

3 4

[Libvir] Proposal: Check availability of driver calls (repost)
by Richard W.M. Jones 01 Aug '07

01 Aug '07

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

3 9

[Libvir] Exporting calls just to libvirtd
by Richard W.M. Jones 31 Jul '07

31 Jul '07

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

1 0

[Libvir] PATCH: Check for bogus default architecture
by Daniel P. Berrange 31 Jul '07

31 Jul '07

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

3 2

[Libvir] PATCH: Overhaul the test driver
by Daniel P. Berrange 31 Jul '07

31 Jul '07

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

3 2

[Libvir] PATCH Fix a couple of mem leaks
by Daniel P. Berrange 31 Jul '07

31 Jul '07

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

3 4

[Libvir] PATCH 0/2: Capabilities and features
by David Lutterkort 30 Jul '07

30 Jul '07

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

4 12