November 2013 - Devel - libvirt List Archives

[libvirt] pvpanic plans?
by Paolo Bonzini 04 Nov '13

04 Nov '13

The thread from yesterday has died off (perhaps also because of my inappropriate answer to Michael, for which I apologize to him and everyone). I took some time to discuss the libvirt requirements further with Daniel Berrange and Eric Blake on IRC. If anyone is interested, I can give logs. This is a suggestion for how to proceed in both QEMU and libvirt. == Builtin pvpanic == QEMU will remove pvpanic from pc-1.5 in 1.6.1 and 1.5.4. This does not break migration. == Support in libvirt for current functionality == libvirt will add a <panic-notifier/> element, and possibly a capability for it accessible via "virsh capabilities". There are two possibilities: 1) On QEMU 1.5.4/1.6.1 and newer (and on QEMU 1.6.0 with a machine type other than pc-1.5), <on_crash> will only work if the element is there. On QEMU 1.5.0->1.5.3, and on QEMU 1.6.0 with the pc-1.5 machine type, <on_crash> will be obeyed always, and may override e.g. reboot-on-panic if a guest driver exist. 2) On all versions, <on_crash> will only work if the element is there. In turn, there are two ways to implement (2): 2a) libvirt will always add -global pvpanic.iobase=0 to neutralize the builtin pvpanic device if present. <panic-notifier/> will create the device with -device pvpanic,iobase=0x505 Advantage: no changes to QEMU Disadvantage 1: writes to port 0 with QEMU 1.{5.0,5.1,5.2,5.3,6.0} and pc-1.5 machine type will write to a pvpanic device instead of the DMA controller. Probably harmless, and limited to some QEMU versions. Disadvantage 2: libvirt has knowledge of the pvpanic port number 2b) QEMU will provide a way for libvirt to detect that no machine type has the builtin pvpanic. If some machine type may have the builtin pvpanic, and <panic-notifier/> is absent, libvirt will add "-global pvpanic.iobase=0" to neutralize it. Otherwise, libvirt will create the device normally. A possible way for libvirt to detect "good" machine types is a dummy property. This is a bit ugly in that the property would not affect the behavior of the device. The property would remain in the long term. Another possibility is for QEMU to rename the device, e.g. to isa-pvpanic. This is also somewhat gross, but not visible in the long term when the "pvpanic" name will be lost in history. Advantage 1: libvirt has no knowledge of the pvpanic port number Disadvantage 1: same as above Disadvantage 2: need a somewhat gross change in QEMU This method also provides an (also somewhat gross on the QEMU side) way to detect other changes in the pvpanic semantics. One example mentioned below, is making the panicked state temporary. == Possible improvements to pvpanic == The current implementation of pvpanic supports three modes: reset system on panic, destroy domain on panic, preserve domain with no possibility to resume it. (Optionally a domain can be dumped too). Long term, the choice to include pvpanic should not be on the guest admin's shoulders, but rather in libosinfo. Thus, it would be nice to have a fourth mode where the panic is logged but the guest otherwise keeps running. This mode would let libosinfo add pvpanic by default without affecting the guest's behavior on panic. With this change, <on_crash>ignore</on_crash> will behave as follows for the three possibilities above: (1) With QEMU 1.5.0 to 1.6.1, <on_crash> will _not_ obey the setting, never (even if no <panic-notifier/> is specified). libvirt will have to pick a fallback action. advantage of destroy as fallback: it is the default (but note that restart is the default for virt-install) advantage of preserve as fallback: lets the admin examine the panic advantage of restart as fallback: maximum availability of the VM, it is the default for virt-install (2a) With QEMU 1.5.0 to 1.6.1, <on_crash> will _not_ obey the setting if <panic-notifier/> is specified. libvirt has _no way_ to learn about this, so the capability would always be present with these QEMU versions and libosinfo would always add <panic-notifier/> with these versions. Given the libosinfo scenario being considered here, this is not very different from (1). (2b) With QEMU 1.5.0 to 1.6.1, the <panic-notifier/> element will not be available and not exposed in libvirt capabilities. Thus with this version libosinfo would omit <panic-notifier/> from the XML. Guest policy will always be followed correctly. The problem in both (1) and (2a) can be summarized as follows. First, libvirt will have to implement and document a fallback action for buggy QEMU. Second, even though the problems would be limited to some version of QEMU, they would be relatively hard to debug for a casual user, could start happening randomly by updating any one of QEMU, libvirt, libosinfo or the guest kernel, and there is no fallback action for libvirt that is always correct. Thus, considering future libosinfo support for pvpanic, (2b) is preferrable in my opinion. Now, making pvpanic reversible requires a change in QEMU (patch already posted). Andreas proposed using a pvpanic property to determine whether the panicked state is temporary or definitive. libvirt could piggyback on such a property to detect the "goodness" of machine types (as mentioned regarding solution 2b above). However: First, this would require a more intrusive patch, less appealing for 1.5 and 1.6 stable branches. Second, there is no reason why libvirt would want to make the panicked state definitive. To achieve the same effect, libvirt can just not issue the "continue" monitor command when the guest is panicked. Thus the new property would be useless except to communicate pvpanic behavior---and renaming the device still seems preferrable to me. Thanks for reading up to here! Paolo

12 54

Re: [libvirt] Libvirt support of mac-programming over macvtap planned?
by Amos Kong 04 Nov '13

04 Nov '13

On Tue, Oct 29, 2013 at 09:50:56AM -0400, Matthew Rosato wrote: > Amos Kong provided QEMU support to facilitate macvtap rx-filter change > notification here: > http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg02736.html > > Libvirt work was mentioned, but I haven't noticed any activity here > regarding exploitation -- Is someone working this or planning to in the > near future? Don't want to duplicate effort. Anything that I can do to > help? We have an redhat internal bug to track it: https://bugzilla.redhat.com/show_bug.cgi?id=848199 CC Laine > Thanks, > Matt -- Amos.

2 2

[libvirt] [PATCHv2 1/2] virsh: move command cpu-baseline from domain group to host group.
by liyang 04 Nov '13

04 Nov '13

From: Li Yang <liyang.fnst(a)cn.fujitsu.com> cpu-baseline command can compute baseline CPU for a set of given CPUs, I think it should not belong to domain group, should belong to host group, so I moved the related source from virsh-domain.c to virsh-host.c Signed-off-by: Li Yang <liyang.fnst(a)cn.fujitsu.com> --- tools/virsh-domain.c | 116 ------------------------------------------------- tools/virsh-host.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 117 insertions(+), 116 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 42c9920..8fc6c59 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -6107,116 +6107,6 @@ cleanup: } /* - * "cpu-baseline" command - */ -static const vshCmdInfo info_cpu_baseline[] = { - {.name = "help", - .data = N_("compute baseline CPU") - }, - {.name = "desc", - .data = N_("Compute baseline CPU for a set of given CPUs.") - }, - {.name = NULL} -}; - -static const vshCmdOptDef opts_cpu_baseline[] = { - {.name = "file", - .type = VSH_OT_DATA, - .flags = VSH_OFLAG_REQ, - .help = N_("file containing XML CPU descriptions") - }, - {.name = "features", - .type = VSH_OT_BOOL, - .help = N_("Show features that are part of the CPU model type") - }, - {.name = NULL} -}; - -static bool -cmdCPUBaseline(vshControl *ctl, const vshCmd *cmd) -{ - const char *from = NULL; - bool ret = false; - char *buffer; - char *result = NULL; - char **list = NULL; - unsigned int flags = 0; - int count = 0; - - xmlDocPtr xml = NULL; - xmlNodePtr *node_list = NULL; - xmlXPathContextPtr ctxt = NULL; - virBuffer buf = VIR_BUFFER_INITIALIZER; - size_t i; - - if (vshCommandOptBool(cmd, "features")) - flags |= VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES; - - if (vshCommandOptStringReq(ctl, cmd, "file", &from) < 0) - return false; - - if (virFileReadAll(from, VSH_MAX_XML_FILE, &buffer) < 0) - return false; - - /* add a separate container around the xml */ - virBufferStrcat(&buf, "<container>", buffer, "</container>", NULL); - if (virBufferError(&buf)) - goto no_memory; - - VIR_FREE(buffer); - buffer = virBufferContentAndReset(&buf); - - - if (!(xml = virXMLParseStringCtxt(buffer, from, &ctxt))) - goto cleanup; - - if ((count = virXPathNodeSet("//cpu[not(ancestor::cpus)]", - ctxt, &node_list)) == -1) - goto cleanup; - - if (count == 0) { - vshError(ctl, _("No host CPU specified in '%s'"), from); - goto cleanup; - } - - list = vshCalloc(ctl, count, sizeof(const char *)); - - for (i = 0; i < count; i++) { - if (!(list[i] = virXMLNodeToString(xml, node_list[i]))) { - vshSaveLibvirtError(); - goto cleanup; - } - } - - result = virConnectBaselineCPU(ctl->conn, - (const char **)list, count, flags); - - if (result) { - vshPrint(ctl, "%s", result); - ret = true; - } - -cleanup: - xmlXPathFreeContext(ctxt); - xmlFreeDoc(xml); - VIR_FREE(result); - if (list != NULL && count > 0) { - for (i = 0; i < count; i++) - VIR_FREE(list[i]); - } - VIR_FREE(list); - VIR_FREE(buffer); - VIR_FREE(node_list); - - return ret; - -no_memory: - vshError(ctl, "%s", _("Out of memory")); - ret = false; - goto cleanup; -} - -/* * "cpu-stats" command */ static const vshCmdInfo info_cpu_stats[] = { @@ -10517,12 +10407,6 @@ const vshCmdDef domManagementCmds[] = { .flags = 0 }, #endif - {.name = "cpu-baseline", - .handler = cmdCPUBaseline, - .opts = opts_cpu_baseline, - .info = info_cpu_baseline, - .flags = 0 - }, {.name = "cpu-compare", .handler = cmdCPUCompare, .opts = opts_cpu_compare, diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 1d1bb97..b69de7c 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -35,6 +35,7 @@ #include "virbuffer.h" #include "viralloc.h" #include "virsh-domain.h" +#include "virfile.h" #include "virxml.h" #include "virtypedparam.h" #include "virstring.h" @@ -193,6 +194,116 @@ cleanup: } /* + * "cpu-baseline" command + */ +static const vshCmdInfo info_cpu_baseline[] = { + {.name = "help", + .data = N_("compute baseline CPU") + }, + {.name = "desc", + .data = N_("Compute baseline CPU for a set of given CPUs.") + }, + {.name = NULL} +}; + +static const vshCmdOptDef opts_cpu_baseline[] = { + {.name = "file", + .type = VSH_OT_DATA, + .flags = VSH_OFLAG_REQ, + .help = N_("file containing XML CPU descriptions") + }, + {.name = "features", + .type = VSH_OT_BOOL, + .help = N_("Show features that are part of the CPU model type") + }, + {.name = NULL} +}; + +static bool +cmdCPUBaseline(vshControl *ctl, const vshCmd *cmd) +{ + const char *from = NULL; + bool ret = false; + char *buffer; + char *result = NULL; + char **list = NULL; + unsigned int flags = 0; + int count = 0; + + xmlDocPtr xml = NULL; + xmlNodePtr *node_list = NULL; + xmlXPathContextPtr ctxt = NULL; + virBuffer buf = VIR_BUFFER_INITIALIZER; + size_t i; + + if (vshCommandOptBool(cmd, "features")) + flags |= VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES; + + if (vshCommandOptStringReq(ctl, cmd, "file", &from) < 0) + return false; + + if (virFileReadAll(from, VSH_MAX_XML_FILE, &buffer) < 0) + return false; + + /* add a separate container around the xml */ + virBufferStrcat(&buf, "<container>", buffer, "</container>", NULL); + if (virBufferError(&buf)) + goto no_memory; + + VIR_FREE(buffer); + buffer = virBufferContentAndReset(&buf); + + + if (!(xml = virXMLParseStringCtxt(buffer, from, &ctxt))) + goto cleanup; + + if ((count = virXPathNodeSet("//cpu[not(ancestor::cpus)]", + ctxt, &node_list)) == -1) + goto cleanup; + + if (count == 0) { + vshError(ctl, _("No host CPU specified in '%s'"), from); + goto cleanup; + } + + list = vshCalloc(ctl, count, sizeof(const char *)); + + for (i = 0; i < count; i++) { + if (!(list[i] = virXMLNodeToString(xml, node_list[i]))) { + vshSaveLibvirtError(); + goto cleanup; + } + } + + result = virConnectBaselineCPU(ctl->conn, + (const char **)list, count, flags); + + if (result) { + vshPrint(ctl, "%s", result); + ret = true; + } + +cleanup: + xmlXPathFreeContext(ctxt); + xmlFreeDoc(xml); + VIR_FREE(result); + if (list != NULL && count > 0) { + for (i = 0; i < count; i++) + VIR_FREE(list[i]); + } + VIR_FREE(list); + VIR_FREE(buffer); + VIR_FREE(node_list); + + return ret; + +no_memory: + vshError(ctl, "%s", _("Out of memory")); + ret = false; + goto cleanup; +} + +/* * "maxvcpus" command */ static const vshCmdInfo info_maxvcpus[] = { @@ -955,6 +1066,12 @@ const vshCmdDef hostAndHypervisorCmds[] = { .info = info_hostname, .flags = 0 }, + {.name = "cpu-baseline", + .handler = cmdCPUBaseline, + .opts = opts_cpu_baseline, + .info = info_cpu_baseline, + .flags = 0 + }, {.name = "maxvcpus", .handler = cmdMaxvcpus, .opts = opts_maxvcpus, -- 1.7.1

1 3

[libvirt] [PATCH] virnetsocket: fix getsockopt on FreeBSD
by Ryota Ozaki 04 Nov '13

04 Nov '13

aa0f099 introduced a strict error checking for getsockopt and it revealed that getting a peer credential of a socket on FreeBSD didn't work. Libvirtd hits the error: error : virNetSocketGetUNIXIdentity:1198 : Failed to get valid client socket identity groups SOL_SOCKET (0xffff) was used as a level of getsockopt for LOCAL_PEERCRED, however, it was wrong. 0 is correct as well as Mac OS X. So for LOCAL_PEERCRED our options are SOL_LOCAL (if defined) or 0 on Mac OS X and FreeBSD. According to the fact, the patch simplifies the code by removing ifdef __APPLE__. I tested the patch on FreeBSD 8.4, 9.2 and 10.0-BETA1. Signed-off-by: Ryota Ozaki <ozaki.ryota(a)gmail.com> --- src/rpc/virnetsocket.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index 3eb5708..04bf25a 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -1152,18 +1152,17 @@ cleanup: /* VIR_SOL_PEERCRED - the value needed to let getsockopt() work with * LOCAL_PEERCRED */ -# ifdef __APPLE__ -# ifdef SOL_LOCAL -# define VIR_SOL_PEERCRED SOL_LOCAL -# else -/* Prior to Mac OS X 10.7, SOL_LOCAL was not defined and users were - * expected to supply 0 as the second value for getsockopt() when using - * LOCAL_PEERCRED - */ -# define VIR_SOL_PEERCRED 0 -# endif + +/* Mac OS X 10.8 provides SOL_LOCAL for LOCAL_PEERCRED */ +# ifdef SOL_LOCAL +# define VIR_SOL_PEERCRED SOL_LOCAL # else -# define VIR_SOL_PEERCRED SOL_SOCKET +/* FreeBSD and Mac OS X prior to 10.7, SOL_LOCAL is not defined and + * users are expected to supply 0 as the second value for getsockopt() + * when using LOCAL_PEERCRED. NB SOL_SOCKET cannot be used instead + * of SOL_LOCAL + */ +# define VIR_SOL_PEERCRED 0 # endif int virNetSocketGetUNIXIdentity(virNetSocketPtr sock, -- 1.8.4

3 4

[libvirt] Entering freeze for libvirt-1.1.4
by Daniel Veillard 04 Nov '13

04 Nov '13

I finally tagged and genrated tarballs for RC1 of 1.1.4, so we have now entered freeze. The bits are available as usual at: ftp://libvirt.org/libvirt/ My initial testing doesn't show anything suspicious but is limited, so please give it a try, especially for portability issues ! If all goes well i will probably make an rc2 by Thurday and release 1.1.4 for good on Monday 4th. Give it a try ! thanks, 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/

2 3

[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 04 Nov '13

04 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 04 Nov '13

04 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 02 Nov '13

02 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