February 2012 - Devel - libvirt List Archives

[libvirt] [PATCH] Workaround python header file insanity
by Daniel P. Berrange 24 Feb '12

24 Feb '12

From: "Daniel P. Berrange" <berrange(a)redhat.com> The /usr/include/python/pyconfig.h file pollutes the global namespace with a huge number of HAVE_XXX and WITH_XXX defines. These change what we detected in our own config.h In particular if you try to build without DTrace, python's headers turn it back on with predictable fail. THe hack to workaround this is to rename WITH_DTRACE to WITH_DTRACE_PROBES to avoid the namespace clash --- configure.ac | 4 ++-- daemon/Makefile.am | 2 +- src/Makefile.am | 4 ++-- src/internal.h | 2 +- tests/Makefile.am | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index 732f4fe..262e63b 100644 --- a/configure.ac +++ b/configure.ac @@ -1378,10 +1378,10 @@ if test "$with_dtrace" != "no" ; then with_dtrace=yes fi if test "$with_dtrace" = "yes"; then - AC_DEFINE_UNQUOTED([WITH_DTRACE], 1, [whether DTrace static probes are available]) + AC_DEFINE_UNQUOTED([WITH_DTRACE_PROBES], 1, [whether DTrace static probes are available]) fi fi -AM_CONDITIONAL([WITH_DTRACE], [test "$with_dtrace" != "no"]) +AM_CONDITIONAL([WITH_DTRACE_PROBES], [test "$with_dtrace" != "no"]) dnl NUMA lib diff --git a/daemon/Makefile.am b/daemon/Makefile.am index e2c1357..db4abf5 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -109,7 +109,7 @@ libvirtd_LDADD = \ $(SASL_LIBS) \ $(POLKIT_LIBS) -if WITH_DTRACE +if WITH_DTRACE_PROBES libvirtd_LDADD += ../src/probes.o endif diff --git a/src/Makefile.am b/src/Makefile.am index d5f52a0..9b1921d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1284,7 +1284,7 @@ libvirt_la_CFLAGS = -DIN_LIBVIRT $(AM_CFLAGS) # picked out for us. libvirt_la_DEPENDENCIES = $(libvirt_la_BUILT_LIBADD) $(LIBVIRT_SYMBOL_FILE) -if WITH_DTRACE +if WITH_DTRACE_PROBES libvirt_la_BUILT_LIBADD += probes.o libvirt_la_DEPENDENCIES += probes.o nodist_libvirt_la_SOURCES = probes.h @@ -1521,7 +1521,7 @@ libvirt_lxc_LDADD = $(CAPNG_LIBS) $(YAJL_LIBS) \ $(LIBNL_LIBS) $(AUDIT_LIBS) $(DEVMAPPER_LIBS) \ $(RT_LIBS) \ ../gnulib/lib/libgnu.la -if WITH_DTRACE +if WITH_DTRACE_PROBES libvirt_lxc_LDADD += probes.o endif if WITH_SECDRIVER_SELINUX diff --git a/src/internal.h b/src/internal.h index fabcb52..3408541 100644 --- a/src/internal.h +++ b/src/internal.h @@ -247,7 +247,7 @@ # define VIR_DIV_UP(value, size) (((value) + (size) - 1) / (size)) -# if WITH_DTRACE +# if WITH_DTRACE_PROBES # ifndef LIBVIRT_PROBES_H # define LIBVIRT_PROBES_H # include "probes.h" diff --git a/tests/Makefile.am b/tests/Makefile.am index 3fb9e2f..9974c2f 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -29,7 +29,7 @@ INCLUDES += \ endif PROBES_O = -if WITH_DTRACE +if WITH_DTRACE_PROBES PROBES_O += ../src/probes.o endif -- 1.7.7.6

2 1

[libvirt] [PATCH] Fixed URI parsing
by Martin Kletzander 24 Feb '12

24 Feb '12

Function virParseURI was added. This function is wrapper around xmlParseURI. In this wrapper we are fixing what doesn't seems to be fixed in libxml2 in the near future. The wrapper is written in such way that if anything gets fixed in libxml2, it'll still work. File changes: - src/util/xml.h -- declaration - src/util/xml.c -- definition - src/libvirt_private.syms -- symbol export - all others -- function call fixed and include added --- src/esx/esx_driver.c | 3 ++- src/libvirt.c | 10 ++++++---- src/libvirt_private.syms | 1 + src/libxl/libxl_driver.c | 3 ++- src/lxc/lxc_driver.c | 3 ++- src/openvz/openvz_driver.c | 3 ++- src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_migration.c | 5 +++-- src/remote/remote_driver.c | 3 ++- src/uml/uml_driver.c | 3 ++- src/util/xml.c | 37 +++++++++++++++++++++++++++++++++++++ src/util/xml.h | 3 +++ src/vbox/vbox_tmpl.c | 3 ++- src/vmx/vmx.c | 3 ++- src/xen/xen_driver.c | 2 +- src/xen/xend_internal.c | 3 ++- 16 files changed, 70 insertions(+), 17 deletions(-) diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c index f5e1cc7..4375432 100644 --- a/src/esx/esx_driver.c +++ b/src/esx/esx_driver.c @@ -44,6 +44,7 @@ #include "esx_vi.h" #include "esx_vi_methods.h" #include "esx_util.h" +#include "xml.h" #define VIR_FROM_THIS VIR_FROM_ESX @@ -3976,7 +3977,7 @@ esxDomainMigratePerform(virDomainPtr domain, } /* Parse migration URI */ - parsedUri = xmlParseURI(uri); + parsedUri = virParseURI(uri); if (parsedUri == NULL) { virReportOOMError(); diff --git a/src/libvirt.c b/src/libvirt.c index 8035add..eeca680 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -44,6 +44,7 @@ #include "command.h" #include "virnodesuspend.h" #include "virrandom.h" +#include "xml.h" #ifndef WITH_DRIVER_MODULES # ifdef WITH_TEST @@ -1117,8 +1118,9 @@ do_open (const char *name, if (STRCASEEQ(name, "xen")) name = "xen:///"; - /* Convert xen:// -> xen:/// because xmlParseURI cannot parse the - * former. This allows URIs such as xen://localhost to work. + /* Convert xen:// -> xen:/// because xmlParseURI (and thus virParseURI + * as well) cannot parse the former. This allows URIs such as + * xen://localhost to work. */ if (STREQ (name, "xen://")) name = "xen:///"; @@ -1127,7 +1129,7 @@ do_open (const char *name, virConnectOpenResolveURIAlias(name, &alias) < 0) goto failed; - ret->uri = xmlParseURI (alias ? alias : name); + ret->uri = virParseURI (alias ? alias : name); if (!ret->uri) { virLibConnError(VIR_ERR_INVALID_ARG, _("could not parse connection URI %s"), @@ -4964,7 +4966,7 @@ virDomainMigratePeer2Peer (virDomainPtr domain, return -1; } - tempuri = xmlParseURI(dconnuri); + tempuri = virParseURI(dconnuri); if (!tempuri) { virLibConnError(VIR_ERR_INVALID_ARG, __FUNCTION__); virDispatchError(domain->conn); diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index a5f9433..7975f94 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -1425,6 +1425,7 @@ virTypedParameterAssign; # xml.h +virParseURI; virXMLChildElementCount; virXMLParseHelper; virXMLPropString; diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 6cfc5eb..f1ef5fb 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -44,6 +44,7 @@ #include "libxl_conf.h" #include "xen_xm.h" #include "virtypedparam.h" +#include "xml.h" #define VIR_FROM_THIS VIR_FROM_LIBXL @@ -1043,7 +1044,7 @@ libxlOpen(virConnectPtr conn, if (libxl_driver == NULL) return VIR_DRV_OPEN_DECLINED; - conn->uri = xmlParseURI("xen:///"); + conn->uri = virParseURI("xen:///"); if (!conn->uri) { virReportOOMError(); return VIR_DRV_OPEN_ERROR; diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index b712da4..9c3c005 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -59,6 +59,7 @@ #include "virnodesuspend.h" #include "virtime.h" #include "virtypedparam.h" +#include "xml.h" #define VIR_FROM_THIS VIR_FROM_LXC @@ -138,7 +139,7 @@ static virDrvOpenStatus lxcOpen(virConnectPtr conn, if (lxc_driver == NULL) return VIR_DRV_OPEN_DECLINED; - conn->uri = xmlParseURI("lxc:///"); + conn->uri = virParseURI("lxc:///"); if (!conn->uri) { virReportOOMError(); return VIR_DRV_OPEN_ERROR; diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c index 833a98d..47fad74 100644 --- a/src/openvz/openvz_driver.c +++ b/src/openvz/openvz_driver.c @@ -56,6 +56,7 @@ #include "virfile.h" #include "logging.h" #include "command.h" +#include "xml.h" #define VIR_FROM_THIS VIR_FROM_OPENVZ @@ -1335,7 +1336,7 @@ static virDrvOpenStatus openvzOpen(virConnectPtr conn, if (access("/proc/vz", W_OK) < 0) return VIR_DRV_OPEN_DECLINED; - conn->uri = xmlParseURI("openvz:///system"); + conn->uri = virParseURI("openvz:///system"); if (conn->uri == NULL) { virReportOOMError(); return VIR_DRV_OPEN_ERROR; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 45c4100..5ff1313 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -857,7 +857,7 @@ static virDrvOpenStatus qemudOpen(virConnectPtr conn, if (qemu_driver == NULL) return VIR_DRV_OPEN_DECLINED; - conn->uri = xmlParseURI(qemu_driver->privileged ? + conn->uri = virParseURI(qemu_driver->privileged ? "qemu:///system" : "qemu:///session"); if (!conn->uri) { diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 12cfbde..35a2ebc 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -45,6 +45,7 @@ #include "virtime.h" #include "locking/domain_lock.h" #include "rpc/virnetsocket.h" +#include "xml.h" #define VIR_FROM_THIS VIR_FROM_QEMU @@ -1773,10 +1774,10 @@ static int doNativeMigrate(struct qemud_driver *driver, virReportOOMError(); return -1; } - uribits = xmlParseURI(tmp); + uribits = virParseURI(tmp); VIR_FREE(tmp); } else { - uribits = xmlParseURI(uri); + uribits = virParseURI(uri); } if (!uribits) { qemuReportError(VIR_ERR_INTERNAL_ERROR, diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index e068126..116cf12 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -47,6 +47,7 @@ #include "command.h" #include "intprops.h" #include "virtypedparam.h" +#include "xml.h" #define VIR_FROM_THIS VIR_FROM_REMOTE @@ -719,7 +720,7 @@ doRemoteOpen (virConnectPtr conn, goto failed; VIR_DEBUG("Auto-probed URI is %s", uriret.uri); - conn->uri = xmlParseURI(uriret.uri); + conn->uri = virParseURI(uriret.uri); VIR_FREE(uriret.uri); if (!conn->uri) { virReportOOMError(); diff --git a/src/uml/uml_driver.c b/src/uml/uml_driver.c index a4cf945..f1e290a 100644 --- a/src/uml/uml_driver.c +++ b/src/uml/uml_driver.c @@ -63,6 +63,7 @@ #include "configmake.h" #include "virnetdevtap.h" #include "virnodesuspend.h" +#include "xml.h" #define VIR_FROM_THIS VIR_FROM_UML @@ -1138,7 +1139,7 @@ static virDrvOpenStatus umlOpen(virConnectPtr conn, if (uml_driver == NULL) return VIR_DRV_OPEN_DECLINED; - conn->uri = xmlParseURI(uml_driver->privileged ? + conn->uri = virParseURI(uml_driver->privileged ? "uml:///system" : "uml:///session"); if (!conn->uri) { diff --git a/src/util/xml.c b/src/util/xml.c index b426653..982ce9a 100644 --- a/src/util/xml.c +++ b/src/util/xml.c @@ -800,6 +800,43 @@ error: goto cleanup; } +/** + * virParseURI: + * @uri: URI to parse + * + * Wrapper for xmlParseURI + * + * Unfortunately there are few things that should be managed after + * parsing the URI. First example is removing the square brackets + * around IPv6 addresses. + * + * @returns the parsed uri object with some fixes + */ +xmlURIPtr +virParseURI(const char *uri) +{ + xmlURIPtr ret = xmlParseURI(uri); + + /* First check: does it even make sense to jump inside */ + if (ret != NULL && ret->server != NULL && ret->server[0] == '[') { + size_t last = strlen(ret->server) - 1; /* Index of last char */ + + /* We want to modify the server string only if there are + * square brackets on both ends and inside there is IPv6 + * address. Otherwise we could make a mistake by modifying + * something else than IPv6 address. */ + if (ret->server[last] == ']' && strchr(ret->server, ':')) { + for (size_t i = 0; i < last; i++) + ret->server[i] = ret->server[i + 1]; + + ret->server[last - 1] = '\0'; + } + /* Even after such modification, it is completely ok to free + * the uri with xmlFreeURI() */ + } + + return ret; +} static int virXMLEmitWarning(int fd, const char *name, diff --git a/src/util/xml.h b/src/util/xml.h index a3750fa..c0fbbca 100644 --- a/src/util/xml.h +++ b/src/util/xml.h @@ -10,6 +10,7 @@ # include <libxml/parser.h> # include <libxml/tree.h> # include <libxml/xpath.h> +# include <libxml/uri.h> int virXPathBoolean(const char *xpath, xmlXPathContextPtr ctxt); @@ -61,6 +62,8 @@ xmlDocPtr virXMLParseHelper(int domcode, const char *url, xmlXPathContextPtr *pctxt); +xmlURIPtr virParseURI(const char *uri); + /** * virXMLParse: * @filename: file to parse, or NULL for string parsing diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c index b168c7d..11fa995 100644 --- a/src/vbox/vbox_tmpl.c +++ b/src/vbox/vbox_tmpl.c @@ -56,6 +56,7 @@ #include "configmake.h" #include "virfile.h" #include "fdstream.h" +#include "xml.h" /* This one changes from version to version. */ #if VBOX_API_VERSION == 2002 @@ -980,7 +981,7 @@ static virDrvOpenStatus vboxOpen(virConnectPtr conn, virCheckFlags(VIR_CONNECT_RO, VIR_DRV_OPEN_ERROR); if (conn->uri == NULL) { - conn->uri = xmlParseURI(uid ? "vbox:///session" : "vbox:///system"); + conn->uri = virParseURI(uid ? "vbox:///session" : "vbox:///system"); if (conn->uri == NULL) { virReportOOMError(); return VIR_DRV_OPEN_ERROR; diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 1fdbd50..866b150 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -33,6 +33,7 @@ #include "logging.h" #include "uuid.h" #include "vmx.h" +#include "xml.h" /* @@ -2610,7 +2611,7 @@ virVMXParseSerial(virVMXContext *ctx, virConfPtr conf, int port, (*def)->target.port = port; (*def)->source.type = VIR_DOMAIN_CHR_TYPE_TCP; - parsedUri = xmlParseURI(fileName); + parsedUri = virParseURI(fileName); if (parsedUri == NULL) { virReportOOMError(); diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c index 94cafde..c101e11 100644 --- a/src/xen/xen_driver.c +++ b/src/xen/xen_driver.c @@ -270,7 +270,7 @@ xenUnifiedOpen (virConnectPtr conn, virConnectAuthPtr auth, unsigned int flags) if (!xenUnifiedProbe()) return VIR_DRV_OPEN_DECLINED; - conn->uri = xmlParseURI("xen:///"); + conn->uri = virParseURI("xen:///"); if (!conn->uri) { virReportOOMError(); return VIR_DRV_OPEN_ERROR; diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c index 5c3838f..e346f5f 100644 --- a/src/xen/xend_internal.c +++ b/src/xen/xend_internal.c @@ -46,6 +46,7 @@ #include "memory.h" #include "count-one-bits.h" #include "virfile.h" +#include "xml.h" /* required for cpumap_t */ #include <xen/dom0_ops.h> @@ -3224,7 +3225,7 @@ xenDaemonDomainMigratePerform (virDomainPtr domain, * "hostname", "hostname:port" or "xenmigr://hostname[:port]/". */ if (strstr (uri, "//")) { /* Full URI. */ - xmlURIPtr uriptr = xmlParseURI (uri); + xmlURIPtr uriptr = virParseURI (uri); if (!uriptr) { virXendError(VIR_ERR_INVALID_ARG, "%s", _("xenDaemonDomainMigrate: invalid URI")); -- 1.7.3.4

5 11

[libvirt] RFC: Post-install behavior of libvirt(-client)
by Martin Kletzander 24 Feb '12

24 Feb '12

Hello everyone, I have a small bug #786770 [1] assigned and I discussed this with few people from our team but I'm still not sure what should be the proper fix for this bug. To sumarize the bug, the problem described and discussed there [1] is that when there's a fresh installation of RHEL system with libvirt-client, there are some error messages displayed. These messages are generated by the part of %post client script where we are running this: if [ $1 -ge 1 ]; then level=$(/sbin/runlevel | /bin/cut -d ' ' -f 2) if /sbin/chkconfig --levels $level libvirt-guests; then # this doesn't do anything but allowing for libvirt-guests to be # stopped on the first shutdown /sbin/service libvirt-guests start > /dev/null 2>&1 || true fi fi The messages are generated because "/sbin/runlevel" returns "unknown" in chrooted installation environment. But there's more to that. While looking at this part of code, I wonder what we are trying to do here :) There are some problems, let me revise: - 1st parameter of this script is 1 for install and 2 for upgrade, thus "[ $1 -ge 1 ]" is always true - we are trying to get the current runlevel and then check if libvirt-guests is enabled in this runlevel. As mentioned before, the latter doesn't work because we are using command "/sbin/runlevel" there. There is another option, but unfortunately, running "/sbin/chkconfig libvirt-guests" fails as well. Both of these are trying to get current runlevel from "/var/run/utmp" which is empty in the chrooted env during installation. Thinking about this a little more, I see two more "unconsistencies" let's say: - we are starting libvirt-guests if it is enabled (rpm post script should not start services) - we don't check if libvirtd is running, so during shutdown we can get even more error messages that the script is not able to connect to libvirt etc. So I'm wondering if I can just remove the starting part (because if someone wants to use it after first install, he has to start libvirtd anyway and then should know to start libvirt-guests as well) or if I have to come up with some totally different solution how to do this. Maybe I'm missing something here or I don't understand it correctly, any correction is appreciated. Thanks in advance for all suggestions. Have a nice day Martin [1] https://bugzilla.redhat.com/show_bug.cgi?id=786770

3 7

[libvirt] [Patch v2] vmx: Better Workstation vmx handling
by Jean-Baptiste Rouault 24 Feb '12

24 Feb '12

This patch adds support for more network configurations in vmx files. Changes since v1: Adapt virVMXFormatEthernet() to handle empty bridge names and user interface type. Add new test cases to vmx2xmltest and xml2vmxtest. Jean-Baptiste Rouault (1): vmx: Better Workstation vmx handling src/vmx/vmx.c | 39 ++++++++++++------ tests/vmx2xmldata/vmx2xml-ethernet-nat.vmx | 6 +++ tests/vmx2xmldata/vmx2xml-ethernet-nat.xml | 21 ++++++++++ tests/vmx2xmldata/vmx2xml-ws-in-the-wild-1.vmx | 52 ++++++++++++++++++++++++ tests/vmx2xmldata/vmx2xml-ws-in-the-wild-1.xml | 35 ++++++++++++++++ tests/vmx2xmldata/vmx2xml-ws-in-the-wild-2.vmx | 52 ++++++++++++++++++++++++ tests/vmx2xmldata/vmx2xml-ws-in-the-wild-2.xml | 36 ++++++++++++++++ tests/vmx2xmltest.c | 4 ++ tests/xml2vmxdata/xml2vmx-ethernet-nat.vmx | 14 ++++++ tests/xml2vmxdata/xml2vmx-ethernet-nat.xml | 13 ++++++ tests/xml2vmxdata/xml2vmx-ws-in-the-wild-1.vmx | 22 ++++++++++ tests/xml2vmxdata/xml2vmx-ws-in-the-wild-1.xml | 29 +++++++++++++ tests/xml2vmxdata/xml2vmx-ws-in-the-wild-2.vmx | 22 ++++++++++ tests/xml2vmxdata/xml2vmx-ws-in-the-wild-2.xml | 30 ++++++++++++++ tests/xml2vmxtest.c | 4 ++ 15 files changed, 366 insertions(+), 13 deletions(-) create mode 100644 tests/vmx2xmldata/vmx2xml-ethernet-nat.vmx create mode 100644 tests/vmx2xmldata/vmx2xml-ethernet-nat.xml create mode 100644 tests/vmx2xmldata/vmx2xml-ws-in-the-wild-1.vmx create mode 100644 tests/vmx2xmldata/vmx2xml-ws-in-the-wild-1.xml create mode 100644 tests/vmx2xmldata/vmx2xml-ws-in-the-wild-2.vmx create mode 100644 tests/vmx2xmldata/vmx2xml-ws-in-the-wild-2.xml create mode 100644 tests/xml2vmxdata/xml2vmx-ethernet-nat.vmx create mode 100644 tests/xml2vmxdata/xml2vmx-ethernet-nat.xml create mode 100644 tests/xml2vmxdata/xml2vmx-ws-in-the-wild-1.vmx create mode 100644 tests/xml2vmxdata/xml2vmx-ws-in-the-wild-1.xml create mode 100644 tests/xml2vmxdata/xml2vmx-ws-in-the-wild-2.vmx create mode 100644 tests/xml2vmxdata/xml2vmx-ws-in-the-wild-2.xml -- 1.7.9

2 2

[libvirt] Add GSoC project ideas to the wiki!
by Stefan Hajnoczi 24 Feb '12

24 Feb '12

This is a reminder that QEMU will apply for Google Summer of Code 2012 and we need project ideas and mentors. Libvirt and kvm.ko projects are also welcome! http://wiki.qemu.org/Google_Summer_of_Code_2012 Please add yourself to the wiki now if you want to mentor a project this summer. I will file our application next week. Thanks, Stefan

2 2

[libvirt] [PATCH 1/1] Add a few additional comments to bugs.html
by Dave Allan 23 Feb '12

23 Feb '12

Clarified that "bugs" in this context means any change to libvirt, whether called a bug, feature, etc. Noted the existence of the Fedora virt preview repo as a way of trying out newer prebuilt packages. Noted that you don't need to be subscribed to the list to post. --- docs/bugs.html.in | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-) diff --git a/docs/bugs.html.in b/docs/bugs.html.in index 39b6725..cc73439 100644 --- a/docs/bugs.html.in +++ b/docs/bugs.html.in @@ -13,6 +13,15 @@ check below for distribution specific bug reporting policies first. </p> + <p> + Please note that although this page is called bug reporting, the + advice here applies to any change you feel should be made in + libvirt, whether it is called a bug, feature, documentation + change or any other kind of modification. (Coding Horror has an + interesting discussion of + <a href="http://www.codinghorror.com/blog/2008/11/thats-not-a-bug-its-a-feature-requ…">some + different takes on that categorization</a>.) + </p> <h2><a name="general">General libvirt bug reports</a></h2> @@ -39,7 +48,8 @@ ask questions on the list, as others may know of existing solutions or be interested in collaborating with you on finding a solution. Patches are always appreciated, and it's likely - that someone else has the same problem you do! + that someone else has the same problem you do! You don't need + to subscribe to the list to post. </p> <p> If you decide to write code, though, before you begin please @@ -59,13 +69,23 @@ <h2><a name="distribution">Linux Distribution specific bug reports</a></h2> <ul> <li> + <p> If you are using binaries from <strong>Fedora</strong>, enter tickets against the <code>Fedora</code> product and the <code>libvirt</code> component. + </p> <ul> <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Fedora">View Fedora libvirt tickets</a></li> <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&compon…">New Fedora libvirt ticket</a></li> </ul> + <p> + If you're willing to try out bleeding edge code but don't + want to build libvirt yourself, consider installing packages + from + the <a href="http://fedoraproject.org/wiki/Virtualization_Preview_Repository">Fedora + Virt Preview Repository</a> to see if your problem has been + fixed already. + </p> </li> <li> <p> -- 1.7.7.6

1 0

[libvirt] [PATCH] Misleading error message when name is missing
by Benjamin Cama 23 Feb '12

23 Feb '12

Hi, [forwarding this here from RH bug #796732] When creating a network (virsh net-create) with an erroneous XML containing an empty <name> element, the error message is misleading: error: Failed to create network from foo.xml error: missing domain name information It took me a bit of time to figure out that it was the *network* name that was missing (I generate this xml and didn't look at it, first). I realized that the same message is used for missing name when creating a domain, network, or device node. Attached patch (warning: against a completly different git than yours, don't pay attention to wrong shas) thus make this message more generic. Regards, Benjamin PS: please Cc me, I'm not subscribed

2 2

[libvirt] [PATCH 1/1] Update bug reporting page
by Dave Allan 23 Feb '12

23 Feb '12

Remove suggestion that people file bugs against RHEL 5 and add a suggestion that people increase the visibility of their bugs by mentioning them on libvir-list. --- docs/bugs.html.in | 83 ++++++++++++++++++++++++++++++++++++---------------- 1 files changed, 57 insertions(+), 26 deletions(-) diff --git a/docs/bugs.html.in b/docs/bugs.html.in index 560dfa4..39b6725 100644 --- a/docs/bugs.html.in +++ b/docs/bugs.html.in @@ -9,22 +9,47 @@ <h2><a name="bugzilla">Bug Tracking</a></h2> <p> - The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla Server</a> - should be used to report bugs and request features in libvirt. - Before submitting a ticket, check the existing tickets to see if - the bug/feature is already tracked. + If you are using libvirt binaries from a Linux distribution + check below for distribution specific bug reporting policies + first. </p> <h2><a name="general">General libvirt bug reports</a></h2> <p> - If you are using official libvirt binaries from a Linux distribution - check below for distribution specific bug reporting policies first. + The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla Server</a> + should be used to report bugs and request features in libvirt. + Before submitting a ticket, check the existing tickets to see if + the bug/feature is already tracked. + For general libvirt bug reports, from self-built releases, GIT snapshots and any other non-distribution supported builds, enter tickets under the <code>Virtualization Tools</code> product and the <code>libvirt</code> component. </p> + <p> + It's always a good idea to file bug reports, as the process of + filing the report always makes it easier to describe the + problem, and the bug number provides a quick way of referring to + the problem. However, not everybody in the community pays + attention to bugzilla, so after you file a bug, asking questions + and submitting patches on <a href="contact.html">the libvirt + mailing lists</a> will increase your bug's visibility and + encourage people to think about your problem. Don't hesitate to + ask questions on the list, as others may know of existing + solutions or be interested in collaborating with you on finding + a solution. Patches are always appreciated, and it's likely + that someone else has the same problem you do! + </p> + <p> + If you decide to write code, though, before you begin please + read the <a href="hacking.html">contributor guidelines</a>, + especially the first point: "Discuss any large changes on the + mailing list first. Post patches early and listen to feedback." + Few development experiences are more discouraging than spending + a bunch of time writing a patch only to have someone point out a + better approach on list. + </p> <ul> <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Virtua…">View libvirt tickets</a></li> @@ -34,26 +59,37 @@ <h2><a name="distribution">Linux Distribution specific bug reports</a></h2> <ul> <li> - If you are using official binaries from a <strong>Fedora distribution</strong>, enter - tickets against the <code>Fedora</code> product and the <code>libvirt</code> - component. + If you are using binaries from <strong>Fedora</strong>, enter + tickets against the <code>Fedora</code> product and + the <code>libvirt</code> component. <ul> <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Fedora">View Fedora libvirt tickets</a></li> <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&compon…">New Fedora libvirt ticket</a></li> </ul> </li> <li> - If you are using official binaries from <strong>Red Hat Enterprise Linux distribution</strong>, - tickets against the <code>Red Hat Enterprise Linux 5</code> product and - the <code>libvirt</code> component. - <ul> - <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Red%20…">View Red Hat Enterprise Linux libvirt tickets</a></li> - <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Red%20Hat%20Enter…">New Red Hat Enterprise Linux libvirt ticket</a></li> - </ul> + <p> + If you are using binaries from <strong>Red Hat Enterprise + Linux</strong>, enter tickets against the Red Hat Enterprise + Linux product that you're using (e.g., Red Hat Enterprise + Linux 6) and the <code>libvirt</code> component. Red Hat + bugzilla has <a href="http://bugzilla.redhat.com">additional guidance</a> about getting support if + you are a Red Hat customer. + </p> </li> <li> - If you are using official binaries from another Linux distribution first - follow their own bug reporting guidelines. + <p> + If you are using binaries from another Linux distribution + first follow their own bug reporting guidelines. + </p> + </li> + <li> + <p> + Finally, if you are a contributor to another Linux + distribution and would like to have your procedure for + filing bugs mentioned here, please mail the libvirt + development list. + </p> </li> </ul> @@ -81,18 +117,18 @@ If the bug leads to a tool linked to libvirt crash, then the best is to provide a backtrace along with the scenario used to get the crash, the simplest is to run the program under gdb, reproduce the - steps leading to the crash and then issue a gdb "bt" command to + steps leading to the crash and then issue a gdb "bt -a" command to get the stack trace, attach it to the bug. Note that for the data to be really useful libvirt debug informations must be present for example by installing libvirt debuginfo package on Fedora or Red Hat Enterprise Linux (with debuginfo-install libvirt) prior to running gdb.</p> <p> - It may also happen that the libvirt daemon itself crashes or get stuck, + It may also happen that the libvirt daemon itself crashes or gets stuck, in the first case run it (as root) under gdb, and reproduce the sequence leading to the crash, similary to a normal program provide the "bt" backtrace information to where gdb will have stopped.<br/> - But if libvirtd get stuck, for example seems to stop processing + But if libvirtd gets stuck, for example seems to stop processing commands, try to attach to the faulty daemon and issue a gdb command "thread apply all bt" to show all the threads backtraces, as in:</p> <pre> # ps -o etime,pid `pgrep libvirt` @@ -106,10 +142,5 @@ (gdb) </pre> - <p> - If requesting a new feature attach any available patch to the ticket - and also email the patch to the libvirt mailing list for discussion - </p> - </body> </html> -- 1.7.7.6

2 1

[libvirt] [PATCH] qemu: nicer error message on failed graceful destroy
by Eric Blake 23 Feb '12

23 Feb '12

https://bugzilla.redhat.com/show_bug.cgi?id=795656 mentions that a graceful destroy request can time out, meaning that the error message is user-visible and should be more appropriate than just internal error. * src/qemu/qemu_driver.c (qemuDomainDestroyFlags): Swap error type. --- src/qemu/qemu_driver.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 717bdf1..c7ca881 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1792,7 +1792,7 @@ qemuDomainDestroyFlags(virDomainPtr dom, */ if (flags & VIR_DOMAIN_DESTROY_GRACEFUL) { if (qemuProcessKill(driver, vm, 0) < 0) { - qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + qemuReportError(VIR_ERR_OPERATION_FAILED, "%s", _("failed to kill qemu process with SIGTERM")); goto cleanup; } -- 1.7.7.6

2 2

[libvirt] [PATCH v2 0/4] Forbid migration with cache != none
by Jiri Denemark 23 Feb '12

23 Feb '12

Migrating qemu domains with disks using cache != none is unsafe unless the disk images are stored on coherent clustered filesystem. Thus we forbid migrating such domains unless VIR_MIGRATE_UNSAFE flags is used. This series uses similar aproach to forbidding unsafe PCI passthrough or disk format probing when we forbade those by default with the possibility to force them. Domain configuration is only checked on source, which makes migrating affected domains from an old libvirt to the new one possible. Migrating back is impossible since destination libvirtd would complain about unknown flag (the flag is not filtered so it gets to the destination even though it's not really used there). However, users of unknown clustered filesystems now have to always pass the new flag to be able to migrate because libvirtd would think they are doing something unsafe. Perhaps we should provide a system wide (i.e., /etc/libvirt/qemu.conf) tunable which would disable cache mode checking for all domains at once? I was also wondering if we should rather use more specific name for both the error code and flag, such as VIR(_ERR)?_MIGRATE_UNSAFE_CACHE (or ...UNSAFE_DISK) in the case we find other unsafe conditions... Version 2: - add virStorageFileIsClusterFS as suggested by Dan B. Jiri Denemark (4): Add support for unsafe migration virsh: Add --unsafe option to migrate command Introduce virStorageFileIsClusterFS qemu: Forbid migration with cache != none include/libvirt/libvirt.h.in | 2 +- include/libvirt/virterror.h | 1 + src/libvirt.c | 4 ++++ src/libvirt_private.syms | 1 + src/qemu/qemu_driver.c | 3 ++- src/qemu/qemu_migration.c | 39 +++++++++++++++++++++++++++++++++++---- src/qemu/qemu_migration.h | 6 ++++-- src/util/storage_file.c | 10 ++++++++++ src/util/storage_file.h | 1 + src/util/virterror.c | 6 ++++++ tools/virsh.c | 4 ++++ tools/virsh.pod | 10 +++++++++- 12 files changed, 78 insertions(+), 9 deletions(-) -- 1.7.8.4

3 12