- Devel - libvirt List Archives

[Libvir] build problems with latest cvs version
by Jan Michael 05 May '07

05 May '07

Hi libvirt-list, I run into the same build problem with version libvirt version 0.2.1, 0.2.2 and the latest cvs-version. In libvirt directory I did the following (for cvs version) ./autogen.sh --disable-shared --disable-QEMU I'd like to disable shared libraries and QEMU support (I have only installed xen 3.0.3 envrionment). The make process breaks while building in [/opt/test/libvirt/qemud], while doing the following: <make output> if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/libxml2 -I../ include -I../include -I/usr/include/libxml2 -Wp,-D_FORTIFY_SOURCE=2 - fexceptions -fasynchronous-unwind-tables -Wall -Wmissing-prototypes - Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite- strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant- decls -Wno-sign-compare -DLOCAL_STATE_DIR="\"/usr/local/var\"" - DSYSCONF_DIR="\"/usr/local/etc\"" -DQEMUD_PID_FILE="\"/usr/local/var/ run/libvirt_qemud.pid\"" -g -O2 -MT libvirt_qemud-bridge.o -MD -MP - MF ".deps/libvirt_qemud-bridge.Tpo" -c -o libvirt_qemud-bridge.o `test -f 'bridge.c' || echo './'`bridge.c; \ then mv -f ".deps/libvirt_qemud-bridge.Tpo" ".deps/libvirt_qemud- bridge.Po"; else rm -f ".deps/libvirt_qemud-bridge.Tpo"; exit 1; fi bridge.c: In function `brAddBridge': bridge.c:130: error: `SIOCBRADDBR' undeclared (first use in this function) bridge.c:130: error: (Each undeclared identifier is reported only once bridge.c:130: error: for each function it appears in.) bridge.c: In function `brDeleteBridge': bridge.c:148: error: `SIOCBRDELBR' undeclared (first use in this function) bridge.c: In function `brAddInterface': bridge.c:182: error: `SIOCBRADDIF' undeclared (first use in this function) bridge.c: In function `brDeleteInterface': bridge.c:190: error: `SIOCBRDELIF' undeclared (first use in this function) bridge.c: In function `brSetForwardDelay': bridge.c:481: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:481: error: syntax error before string constant bridge.c:481: warning: empty body in an if-statement bridge.c: In function `brGetForwardDelay': bridge.c:503: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:503: error: syntax error before string constant bridge.c:503: warning: empty body in an if-statement bridge.c: In function `brSetEnableSTP': bridge.c:531: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:531: error: syntax error before string constant bridge.c:531: warning: empty body in an if-statement bridge.c: In function `brGetEnableSTP': bridge.c:553: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:553: error: syntax error before string constant bridge.c:553: warning: empty body in an if-statement </make output> I get the same even on the older versions 0.2.2 and 0.2.1. Can you please help me to solve this compilation error? Many thanks in advance, Jan Michael

4 12

[Libvir] PATCH: Remove duplicate graphics for HVM on 3.0.5
by Daniel P. Berrange 04 May '07

04 May '07

In the Xen 3.0.5 series, the HVM graphics config was moved to use the same syntax as Paravirt (ie the pvfb devices). I previously added support for this, but didn't realize that the old syntax was kept as back-compat when doing 'xm list --long' or equiv. So we're ending up with 2 <graphics> elements with the same information. This patch makes us ignore the old style config if running on new XenD. 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 1

[Libvir] PATCH: Disable xm_internal.c on newer XenD
by Daniel P. Berrange 03 May '07

03 May '07

The xm_internal.c driver (that processes /etc/xen config files) is only ever intended to be used on XenD <= 3.0.3 There are impls of all the methods in xend_internal.c that take priority on newer XenD, since the xend driver is before it in the stack. The only flaw is that upon failure of one of the xend method libvirt will carry on & invoke the xm_internal driver method. The attached patch addresses this by completely disabling the xm_internal driver on XenD >= 3.0.4 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 3

[Libvir] PATCH: Use --strict-order with dnsmasq
by Daniel P. Berrange 03 May '07

03 May '07

A bug reported by David Lutterkort... The 'man resolv.conf' docs for 'nameserver' say [quote] nameserver Name server IP address Internet address (in dot notation) of a name server that the resolver should query. Up to MAXNS (currently 3, see <resolv.h>) name servers may be listed, one per keyword. If there are multi- ple servers, the resolver library queries them in the order listed. If no nameserver entries are present, the default is to use the name server on the local machine. (The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.) [/quote] While 'man dnsmasq' docs for 'strict-order' say: [quote] -o, --strict-order By default, dnsmasq will send queries to any of the upstream servers it knows about and tries to favour servers to are known to be up. Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf [/quote] So by default, the algorithm dnsmasq uses for DNS lookups is a) Different from that use by GLibC b) Wrong Thus I think we should always use --strict-order when running dnsmasq. The attached patch adds this 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] Allow network drivers to decline to take a connection
by Richard W.M. Jones 03 May '07

03 May '07

A couple of problems fixed in the attached patch. Firstly the path used to connect to the network driver in non-root mode was wrong. This may have affected you if you tried to use the test:///default driver as non-root. I haven't tested this fully, but in any case the path is obviously wrong and needs to be fixed. Secondly remote introduces its own network driver, and so we now need to allow network drivers to decline to take a connection (currently they either succeed or give an error - meaning in effect that there can only be one network driver). The first part of the attached patch allows this. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

2 3

[Libvir] [PATCH] Synchronous daemon restart
by Mark McLoughlin 03 May '07

03 May '07

Hey, See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238492 Basically, doing a "service libvirtd restart", you see: libvirt-qemud: Failed to autostart network 'default': cannot create bridge 'virbr0' : File exists and the default network is broken. The problem turns out to be that the initscript doesn't wait before the old daemon has shut down before starting the new one. The fix is simple - if you don't pass a kill level argument to killproc(), then it will block for a few seconds until the daemon has shutdown before killing it with a SIGKILL. Cheers, Mark. Index: qemud/libvirtd.in =================================================================== RCS file: /data/cvs/libvirt/qemud/libvirtd.in,v retrieving revision 1.1 diff -u -p -r1.1 libvirtd.in --- qemud/libvirtd.in 23 Feb 2007 12:50:58 -0000 1.1 +++ qemud/libvirtd.in 2 May 2007 16:47:18 -0000 @@ -34,7 +34,7 @@ start() { stop() { echo -n $"Stopping $SERVICE daemon: " - killproc $PROCESS -TERM + killproc $PROCESS RETVAL=$? echo if [ $RETVAL -eq 0 ]; then

2 3

[Libvir] [PATCH] Don't throw away errors in virConnectOpen (at least not so often)
by Richard W.M. Jones 03 May '07

03 May '07

Error messages, I like them. I don't like them to be thrown away. A nice feature of virterror is that it'll throw away errors under the following conditions: (1) You are in virConnectOpen, and (2) You pass a non-NULL virConnectPtr to __virRaiseError. libvirt has a lot of errors which meet those conditions - the attached patch fixes the ones I could find. It also fixes qemuOpenConnection so that it doesn't try to open a Unix socket with random stack data. It also adds error messages in some useful places where previously there was an error, but no message. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

3 3

[Libvir] PATCH: Support <on_reboot>poweroff</on_reboot> in QEMU/KVM
by Daniel P. Berrange 03 May '07

03 May '07

Currently in the QEMU driver we don't support any of the customizable shutdown operation behaviour elements in the XML. ie <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> This was principally because we don't particularly have a good way to actually implement some of them. Well, QEMU 0.9.0 added a -no-reboot flag which could be used to force a 'reboot' inside the guest to behaviour like a shutdown. So we can now support at least the <on_reboot> element with 'destroy' or 'restart' behaviours. This turns out to be critical for provisioning guests, because the initial install uses a different VM configs, from later runtime, eg boot from ISO, vs boot from Disk. The attached patch adds support for accepting <on_reboot> when defining new domain configs. When dumping XML we will also add <on_poweroff> and <on_crash> elements to at least indicate what our behaviour is, though the user can't customize them. In doing this patch I had to change the way we read data from QEMU. We were over the 4096 buffer size, and also in some cases we were getting a short read which meant we lost the end of the help message. We now have a buffer of 8k (max QEMU help is 5k currently), and read in a loop until EOF or 8k is hit. 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 1

[Libvir] [PATCH] Allow virDomainDefine to overwrite existing inactive domains for xen 3.0.3 userspace installations
by Hugh Brock 02 May '07

02 May '07

virDomainDefineXML should overwrite an existing inactive domain config if it finds one; it does this successfully for later (post 3.0.3) xen versions. However on xen 3.0.3 overwriting an existing config would fail with a name conflict. This patch allows the overwrite, removing the prior config from the config hashes. If someone more familiar than I with libvirt error handling and style could look at this and tell me if I've done something horribly wrong, I'd appreciate it. Signed-off-by: Hugh Brock <hbrock(a)redhat.com> -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

3 2

[Libvir] Remote patch, 2007-05-01
by Richard W.M. Jones 02 May '07

02 May '07

This is a patch against CVS -- in other words, it includes the two previous patches I sent to this list today. Compared to the previous patch, it's just bug fixes and testing. Sorry, these patches are getting rather huge. Unfortunately I can't see any sensible way to split it up. For the most part you either have remote support or you don't. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 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. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

2 2