- Devel - libvirt List Archives

[libvirt] Erratic failure of
by Daniel Veillard 04 Nov '13

04 Nov '13

While building the release my first rpm build failed with FAIL: securityselinuxtest i.e. rpmbuit -ta based on libvirt-1.1.4 tarball on an up to date Fedora release 19, it did not reproduce (subsequent builds just worked fine) so i don't really have clues of what happened, except I didn't caught anything in my logs either. That didn't happen for rc1 or rc2 but that could be just pure luck . Sorry for the lack of details, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [PATCH] MacOS: Handle changes to args in xdrproc_t
by Doug Goldstein 03 Nov '13

03 Nov '13

With Mac OS X 10.9, xdrproc_t is no longer defined as: typedef bool_t (*xdrproc_t) (XDR *, void *, ...); but instead as typedef bool-t (*xdrproc_t) (XDR *, void *, unsigned int); The rationale explained in the header is that using a vararg is incorrect and has a potential to change the ABI slightly. They decided to specify the exact number of parameters and for compatibility with old code decided to make the signature require 3 arguments. The third argument is ignored for cases that its not used and its recommended to supply a 0. --- configure.ac | 41 +++++++++++++++++++++++++++++++++++++++++ src/rpc/virnetmessage.c | 10 ++++++++-- 2 files changed, 49 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 1c5b168..f2bae88 100644 --- a/configure.ac +++ b/configure.ac @@ -697,6 +697,47 @@ if test x"$with_remote" = x"yes" || test x"$with_libvirtd" = x"yes"; then *) XDR_CFLAGS=$lv_cv_xdr_cflags ;; esac AC_SUBST([XDR_CFLAGS]) + + dnl Mac OS X Mavericks (10.9) dropped the varargs definition that + dnl allowed 2 or 3 parameters to xdrproc_t callbacks and decided on + dnl 3 arguments being a must. + old_CFLAGS=$CFLAGS + AC_CACHE_CHECK([whether xdrproc_t callbacks take 2 or 3 args], + [lv_cv_xdrproc_t_args], [ + CFLAGS="$old_CFLAGS $XDR_CFLAGS" + AC_COMPILE_IFELSE([AC_LANG_PROGRAM( + [[ + #include <rpc/rpc.h> + ]], + [[ + XDR xdr; + xdrproc_t filter = NULL; + + return (filter)(&xdr, NULL); + ]])], + [lv_cv_xdrproc_t_args=2], [ + AC_COMPILE_IFELSE([AC_LANG_PROGRAM( + [[ + #include <rpc/rpc.h> + ]], + [[ + XDR xdr; + xdrproc_t filter = NULL; + + return (filter)(&xdr, NULL, 0); + ]])], + [lv_cv_xdrproc_t_args=3], + [lv_cv_xdrproc_t_args=unknown]) + ]) + CFLAGS="$old_CFLAGS" + ]) + case $lv_cv_xdrproc_t_args in + unknown) AC_MSG_ERROR([cannot determine arg count for xdrproc_t]) ;; + *) + AC_DEFINE_UNQUOTED([XDRPROC_T_ARG_COUNT], [$lv_cv_xdrproc_t_args], + [number of arguments that xdrproc_t func ptr takes]) + ;; + esac fi diff --git a/src/rpc/virnetmessage.c b/src/rpc/virnetmessage.c index d60366b..79e496f 100644 --- a/src/rpc/virnetmessage.c +++ b/src/rpc/virnetmessage.c @@ -33,6 +33,12 @@ #define VIR_FROM_THIS VIR_FROM_RPC +#if XDRPROC_T_ARG_COUNT == 3 +# define VIR_XDRPROC(proc, xdr, data) ((proc)((xdr), (data), 0)) +#else +# define VIR_XDRPROC(proc, xdr, data) ((proc)((xdr), (data))) +#endif + virNetMessagePtr virNetMessageNew(bool tracked) { virNetMessagePtr msg; @@ -345,7 +351,7 @@ int virNetMessageEncodePayload(virNetMessagePtr msg, msg->bufferLength - msg->bufferOffset, XDR_ENCODE); /* Try to encode the payload. If the buffer is too small increase it. */ - while (!(*filter)(&xdr, data)) { + while (!VIR_XDRPROC(*filter, &xdr, data)) { unsigned int newlen = (msg->bufferLength - VIR_NET_MESSAGE_LEN_MAX) * 4; if (newlen > VIR_NET_MESSAGE_MAX) { @@ -402,7 +408,7 @@ int virNetMessageDecodePayload(virNetMessagePtr msg, xdrmem_create(&xdr, msg->buffer + msg->bufferOffset, msg->bufferLength - msg->bufferOffset, XDR_DECODE); - if (!(*filter)(&xdr, data)) { + if (!VIR_XDRPROC(*filter, &xdr, data)) { virReportError(VIR_ERR_RPC, "%s", _("Unable to decode message payload")); goto error; } -- 1.8.1.5

4 6

[libvirt] [PATCH] MacOS: Handle changes to xdrproc_t definition
by Doug Goldstein 03 Nov '13

03 Nov '13

With Mac OS X 10.9, xdrproc_t is no longer defined as: typedef bool_t (*xdrproc_t)(XDR *, ...); but instead as: typdef bool_t (*xdrproc_t)(XDR *, void *, unsigned int); For reference, Linux systems typically define it as: typedef bool_t (*xdrproc_t)(XDR *, void *, ...); The rationale explained in the header is that using a vararg is incorrect and has a potential to change the ABI slightly do to compiler optimizations taken and the undefined behavior. They decided to specify the exact number of parameters and for compatibility with old code decided to make the signature require 3 arguments. The third argument is ignored for cases that its not used and its recommended to supply a 0. --- src/rpc/virnetmessage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/rpc/virnetmessage.c b/src/rpc/virnetmessage.c index d60366b..af07404 100644 --- a/src/rpc/virnetmessage.c +++ b/src/rpc/virnetmessage.c @@ -345,7 +345,7 @@ int virNetMessageEncodePayload(virNetMessagePtr msg, msg->bufferLength - msg->bufferOffset, XDR_ENCODE); /* Try to encode the payload. If the buffer is too small increase it. */ - while (!(*filter)(&xdr, data)) { + while (!(*filter)(&xdr, data, 0)) { unsigned int newlen = (msg->bufferLength - VIR_NET_MESSAGE_LEN_MAX) * 4; if (newlen > VIR_NET_MESSAGE_MAX) { @@ -402,7 +402,7 @@ int virNetMessageDecodePayload(virNetMessagePtr msg, xdrmem_create(&xdr, msg->buffer + msg->bufferOffset, msg->bufferLength - msg->bufferOffset, XDR_DECODE); - if (!(*filter)(&xdr, data)) { + if (!(*filter)(&xdr, data, 0)) { virReportError(VIR_ERR_RPC, "%s", _("Unable to decode message payload")); goto error; } -- 1.8.1.5

3 4

[libvirt] libvirt doesn't compile on OS X 10.9 Mavericks
by Ryan Schmidt 02 Nov '13

02 Nov '13

libvirt 1.1.3 doesn't compile on OS X 10.9 Mavericks. A bug report has already been filed, but I was asked to write to this mailing list to bring the matter to your attention. https://bugzilla.redhat.com/show_bug.cgi?id=1023860 In that bug report it mentions that this was fixed, however the patch linked to does not fix the problem.

2 2

[libvirt] [RFC PATCHv2 0/2] gluster pools
by Eric Blake 01 Nov '13

01 Nov '13

This addresses the review from RFCv1 for splitting the glfs checks to be different from the storage backend checks: https://www.redhat.com/archives/libvir-list/2013-October/msg00645.html I'm still just in RFC stage; wanting to make sure I have the documentation correct for sample XML prior to actually coding up the use of <glfs.h> from storage_backend_gluster.c. Note that qemu's block/gluster.c documents that qemu expects that when using glfs to bypass the file system, the image will always be specified as: * file=gluster[+transport]://[server[:port]]/volname/image[?socket=...] which means that there is no way to pass a direct gluster volume as a raw block device to qemu (it is always a file embedded within the gluster volume); hence my choice of making a single gluster volume act as the storage pool. Eric Blake (2): storage: initial support for linking with libgfapi storage: document gluster pool configure.ac | 21 +++++++ docs/formatstorage.html.in | 11 ++-- docs/schemas/storagepool.rng | 21 +++++++ docs/storage.html.in | 90 +++++++++++++++++++++++++++- libvirt.spec.in | 15 +++++ m4/virt-gluster.m4 | 26 ++++++++ po/POTFILES.in | 1 + src/Makefile.am | 9 +++ src/conf/storage_conf.c | 20 +++++-- src/conf/storage_conf.h | 3 +- src/storage/storage_backend.c | 6 ++ src/storage/storage_backend.h | 6 +- src/storage/storage_backend_gluster.c | 46 ++++++++++++++ src/storage/storage_backend_gluster.h | 29 +++++++++ tests/storagepoolxml2xmlin/pool-gluster.xml | 8 +++ tests/storagepoolxml2xmlout/pool-gluster.xml | 11 ++++ tests/storagepoolxml2xmltest.c | 1 + 17 files changed, 311 insertions(+), 13 deletions(-) create mode 100644 m4/virt-gluster.m4 create mode 100644 src/storage/storage_backend_gluster.c create mode 100644 src/storage/storage_backend_gluster.h create mode 100644 tests/storagepoolxml2xmlin/pool-gluster.xml create mode 100644 tests/storagepoolxml2xmlout/pool-gluster.xml -- 1.8.3.1

1 4

[libvirt] Using external ceph.conf for RBD pools and disks
by Michael Chapman 01 Nov '13

01 Nov '13

Hi all, At the moment, RBD storage pools in libvirt must be supplied with a list of Ceph monitor addresses, using <host> elements in the pool's source definition. Ceph itself has a configuration file, and this is used by default by all Ceph command-line utilities. This file can contain the monitor addresses for the cluster, as well as a bunch of other useful options (e.g. for tuning and debugging). I think it would be nice if libvirt were able to load in this file when starting RBD storage pools. Before I send some patches through. however, I thought I'd better check to see whether my approach is sound. First, I am not keen on having libvirt get librados to load the configuration file automatically. librados actually uses a search path to find the configuration file, and that path includes silly things like the current working directory. Since it can be told to load a single file, I think it would be better if it were made explicit in the storage pool XML, i.e.: <pool type="rbd"> <name>rbd</name> <source> <name>rbd</name> <config file="/etc/ceph/ceph.conf"/> <auth username="user" type="ceph"> <secret usage="mycephcluster"/> </auth> </source> </pool> <config> would be able to be used in addition to, or as an alternative to, a list of <host> elements. Would something along these lines this be suitable? Would it be better to use the <config> element's text content as the filename, rather than use an attribute? I'm not sure what style guidelines there are for something like this. The second part is of course to make a similar change to RBD-based domain disk definitions, i.e.: ... <disk type="network"> <driver name="qemu" type="raw"/> <source protocol="rbd" name="pool/volume"> <config file="/etc/ceph/ceph.conf"/> </source> <target dev="vda" bus="virtio"/> <auth username="user"> <secret type="ceph" usage="mycephcluster"/> </auth> </disk> ... Again, <config> could be used instead of or alongside some <host> elements. This is where it gets a little tricky. At the moment, <host> in a disk's source definition is entirely optional. Furthermore, QEMU _always_ loads a Ceph configuration file -- either one supplied as a "conf" argument for the block device, or one found through the search path mentioned earlier. The only way to suppress this is to pass conf=/dev/null... but for backwards-compatibility (users may be relying on QEMU's use of the search path), I don't think we can do this now. There's one final gotcha in all of this: if QEMU is given both a "conf" argument and a "mon_addr" argument, only the latter will take effect. This means if both <config> and <host> are supplied, then the <host> elements will override any monitor addresses from the configuration file. For consistency, I intend to make an RBD storage pool have the same behaviour. However, would it perhaps be better if the user could only choose _either_ <config> or a list of <host> elements? Personally, I don't think it's a big deal if the behaviour is clearly documented -- being able to load options from a config file while still defining hosts in the libvirt XML could be useful. Anyway, before I send my patches through I'm interested in hearing people's thoughts on this. All sound sane? Too intrusive? A waste of time? :-) - Michael

4 5

Re: [libvirt] [PATCH] network_conf.c: correct the value of the 'result' variable
by Hongwei Bi 01 Nov '13

01 Nov '13

2013/11/1 Eric Blake <eblake(a)redhat.com>: > [off-list] > > On 10/31/2013 06:20 PM, Hongwei Bi wrote: > > Your system clock is off. From your headers: > > Received: from localhost ([112.23.86.63]) > by mx.google.com with ESMTPSA id q4sm5224371pba.12.2013.10.31.09.39.20 > for <multiple recipients> > (version=TLSv1.2 cipher=RC4-SHA bits=128/128); > Thu, 31 Oct 2013 09:39:21 -0700 (PDT) > Date: Fri, 1 Nov 2013 08:20:12 +0800 > > your system claimed to have sent at 12:20 UTC on Friday, but your mail > server received it at 16:39 UTC on Thursday. Your clock is about 8 > hours off, and it messes up mail clients that sort threads by most > recent activity. > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > According to the following link https://www.redhat.com/archives/libvir-list/2013-November/msg00016.html It seems that there is no need to add this patch. But the caller virNetworkDefFormatInternal() has a check of the return value which is described as " if (virNetworkDNSDefFormat(buf, &def->dns) < 0) ". So I think we should at least change one or the other.

2 2

[libvirt] RHBZ 1013045: Crash on xen domain startup: *** Error in `/usr/sbin/libvirtd': free(): invalid next size (fast): 0x00007f82c8003210 ***
by Jeremy Fitzhardinge 01 Nov '13

01 Nov '13

Hi all, I posted this bug (https://bugzilla.redhat.com/show_bug.cgi?id=1013045) to the Redhat Bugzilla a while ago, and the only response has been to post a note to this list about the bug. Summary below, but it looks like a pretty clear use-after-free or something. The full details are attached to the bug report. Thanks, J -- Description of problem: When starting a Xen domain with libvirt + libxl, it crashes after creating the domain. The domain is left in a paused state, and works fine if manually unpaused with xl unpause. virt-manager never shows the domain as running. [...] Steps to Reproduce: 1. Open virt-manager 2. Connect to localhost (xen) 3. Start a domain Actual results: Domain is created in a paused state, virt-manager shows errors about losing connection to the daemon. Logs show libvirtd crashed. Expected results: Domain creation. Additional info: Sep 27 09:08:30 saboo libvirtd[24880]: *** Error in `/usr/sbin/libvirtd': free(): invalid next size (fast): 0x00007f82c8003210 *** Sep 27 09:08:30 saboo libvirtd[24880]: ======= Backtrace: ========= Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libc.so.6(+0x365b27d0e8)[0x7f82f5a7a0e8] Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libvirt.so.0(virFree+0x1a)[0x7f82f8f07d5a] Sep 27 09:08:30 saboo libvirtd[24880]: /usr/lib64/libvirt/connection-driver/libvirt_driver_libxl.so(+0x14b6c)[0x7f82e032bb6c] Sep 27 09:08:30 saboo libvirtd[24880]: /usr/lib64/libvirt/connection-driver/libvirt_driver_libxl.so(+0x154d4)[0x7f82e032c4d4] Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libvirt.so.0(virDomainCreate+0xf7)[0x7f82f8fdb6b7] Sep 27 09:08:30 saboo libvirtd[24880]: /usr/sbin/libvirtd(+0x350c7)[0x7f82f9a1a0c7] Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libvirt.so.0(virNetServerProgramDispatch+0x3ba)[0x7f82f90314aa] Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libvirt.so.0(+0x3a33f822d8)[0x7f82f902c2d8] Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libvirt.so.0(+0x3a33ea0c15)[0x7f82f8f4ac15] Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libvirt.so.0(+0x3a33ea0691)[0x7f82f8f4a691] Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libpthread.so.0(+0x365ba07c53)[0x7f82f61ccc53] Sep 27 09:08:30 saboo libvirtd[24880]: /lib64/libc.so.6(clone+0x6d)[0x7f82f5af2d3d]

5 15

[libvirt] [PATCH] fix api changes in xen restore
by Bamvor Jian Zhang 01 Nov '13

01 Nov '13

in recently xen commit: 7051d5c8, there is a api changes in libxl_domain_create_restore. Author: Andrew Cooper <andrew.cooper3(a)citrix.com> Date: Thu Oct 10 12:23:10 2013 +0100 tools/migrate: Fix regression when migrating from older version of Xen use the macro LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS in libxl.h in order to make libvirt could compile with old and new xen. the params checkpointed_stream is useful if libvirt libxl driver support migration. for new, set it as zero. Signed-off-by: Bamvor Jian Zhang <bjzhang(a)suse.com> --- src/libxl/libxl_driver.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 4928695..104ad31 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -555,6 +555,9 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, int managed_save_fd = -1; libxlDomainObjPrivatePtr priv = vm->privateData; libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver); +#ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS + libxl_domain_restore_params params; +#endif if (libxlDomainObjPrivateInitCtx(vm) < 0) goto error; @@ -619,8 +622,14 @@ libxlVmStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, ret = libxl_domain_create_new(priv->ctx, &d_config, &domid, NULL, NULL); else +#ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS + params.checkpointed_stream = 0; + ret = libxl_domain_create_restore(priv->ctx, &d_config, &domid, + restore_fd, &params, NULL, NULL); +#else ret = libxl_domain_create_restore(priv->ctx, &d_config, &domid, restore_fd, NULL, NULL); +#endif if (ret) { if (restore_fd < 0) -- 1.8.1.4

3 2

[libvirt] the POLLHUP envet for a pipe descriptor is the cause that the libvirt_lxc costs 100% cpu usage.
by jj zhong 01 Nov '13

01 Nov '13

I found the poll in virEventPollRunOnce (vireventpoll.c), a POLLHUP event occurred for a pipe descriptor, thus the poll always returned because of it.( the pipe broken). this may be the best I could track temporarily，I don't know what to do netx , to mask the hangup event or to do something to handle the hangup event , what to do ? Is it a bug or something ? any help would be appreciate. :)

3 2