- Devel - libvirt List Archives

[libvirt] [PATCH] storage: Skips backingStore of virtual snapshot lv
by Osier Yang 21 Nov '11

21 Nov '11

lvs outputs "[$lvname_vorigin]" for the virtual snapshot lv (created with "--virtualsize"), and the original device pointed by "$lvname_vorigin" is just for lvm internal use, one should never use it. Per lvm's nameing rules, "[" is not valid as part of the vg/lv name. (man 8 lvm). <quote> VALID NAMES The following characters are valid for VG and LV names: a-z A-Z 0-9 + _ . - VG and LV names cannot begin with a hyphen. There are also various reserved names that are used internally by lvm that can not be used as LV or VG names. A VG cannot be called anything that exists in /dev/ at the time of creation, nor can it be called '.' or '..'. A LV cannot be called '.' '..' 'snapshot' or 'pvmove'. The LV name may also not con‐ tain the strings '_mlog' or '_mimage' </quote> So we can skip the set the lv's backingStore by checking if the name begins with a "[". --- src/storage/storage_backend_logical.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c index 3c3e736..8118d08 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -121,7 +121,14 @@ virStorageBackendLogicalMakeVol(virStoragePoolObjPtr pool, } } - if (groups[1] && !STREQ(groups[1], "")) { + /* Skips the backingStore of lv created with "--virtualsize", + * its original device "/dev/$vgname/$lvname_vorigin" is + * just for lvm internal use, one should never use it. + * + * (lvs outputs "[$lvname_vorigin] for field "origin" if the + * lv is created with "--virtualsize"). + */ + if (groups[1] && !STREQ(groups[1], "") && (groups[1][0] != '[')) { if (virAsprintf(&vol->backingStore.path, "%s/%s", pool->def->target.path, groups[1]) < 0) { virReportOOMError(); -- 1.7.1

2 4

[libvirt] [PATCH] build: require more tools from maintainers
by Eric Blake 19 Nov '11

19 Nov '11

We want our tarballs to be complete - this means that any generated file that gets shipped as part of the tarball so that ordinary users don't have to rebuild it must be something that the maintainer can generate. There have been various reports of random build failures when using libvirt.git instead of a tarball, and often it is due to missing a maintainer-specific tool to produce one of these generated files. This patch raises the bar for what you must have installed to build libvirt.git, but does not impact what you can get away with for building tarballs. Note: It still remains possible to do a successful 'make dist' without these tools, when starting from a release tarball. * bootstrap.conf (buildreq): Add tools that maintainers need for a successful 'make dist' from a fresh git checkout. --- In reply to this thread: https://www.redhat.com/archives/libvir-list/2011-November/msg00344.html bootstrap.conf | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/bootstrap.conf b/bootstrap.conf index 6498aba..a291590 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -181,6 +181,12 @@ ACLOCAL="$ACLOCAL -I m4" export ACLOCAL # Build prerequisites +# Note that some of these programs are only required for 'make dist' to +# succeed from a fresh git checkout; not all of these programs are +# required to run 'make dist' on a tarball. As a special case, we want +# to require the equivalent of the Fedora python-devel package, but +# RHEL 5 lacks the witness python-config package; we hack around that +# old environment below. buildreq="\ autoconf 2.59 automake 1.9.6 @@ -191,9 +197,18 @@ gzip - libtool - perl 5.5 pkg-config - +python-config - rpcgen - tar - +xmllint - +xsltproc - " +# You don't have to be on a system with rpm; rather, if you happen to +# be on RHEL 5, then this bypasses the bootstrap logic that probes for +# a working 'python-config --version'. +if `(rpm -q python-devel) >/dev/null 2>&1`; then + PYTHON_CONFIG=true +fi # Automake requires that ChangeLog exist. touch ChangeLog || exit 1 -- 1.7.7.1

1 1

[libvirt] [PATCH] Don't copy sexpr node value that is an empty string
by Jim Fehlig 18 Nov '11

18 Nov '11

Xen4.1 initializes some unspecified sexpr config items to an empty string, unlike previous Xen versions that would leave the item unset. E.g. the kernel item for an HVM guest (non-direct kernel boot): Xen4.0 and earlier ... (image (hvm (kernel ) ... Xen4.1 ... (image (hvm (kernel '') ... The empty string for kernel causes some grief in subsequent parsing where existence of specified kernel is checked, e.g. if (!def->os.kernel) ... This patch solves the problem in sexpr_node_copy() by not copying a node containing an empty string. --- src/util/sexpr.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/util/sexpr.c b/src/util/sexpr.c index 0e30087..3523d76 100644 --- a/src/util/sexpr.c +++ b/src/util/sexpr.c @@ -519,7 +519,7 @@ int sexpr_node_copy(const struct sexpr *sexpr, const char *node, char **dst) { const char *val = sexpr_node(sexpr, node); - if (val) { + if (val && *val) { *dst = strdup(val); if (!(*dst)) return -1; -- 1.7.7

2 2

[libvirt] "make rpm" failing with git head on RHEL6
by Justin Clift 18 Nov '11

18 Nov '11

Hi guys, Just tried "make rpm" with git head, on RHEL 6.x. It gave the following failure: make[1]: Leaving directory `/home/jc/git_repos/libvirt' make[1]: Entering directory `/home/jc/git_repos/libvirt' { test ! -d "libvirt-0.9.6" || { find "libvirt-0.9.6" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -fr "libvirt-0.9.6"; }; } test -d "libvirt-0.9.6" || mkdir "libvirt-0.9.6" cp: cannot stat `./NEWS': No such file or directory make[1]: *** [distdir] Error 1 make[1]: Leaving directory `/home/jc/git_repos/libvirt' make: *** [rpm] Error 2 Anyone want to fix it prior to 0.9.7? :) Regards and best wishes, Justin Clift -- Aeolus Community Manager http://www.aeolusproject.org

5 15

[libvirt] [PATCH] tests: avoid xend ABRT crash report
by Eric Blake 18 Nov '11

18 Nov '11

I installed the xen development packages on my non-Xen F16 machine in order to compile-test xen code and ensure we don't break things on that front, but being a non-xen machine, /usr/sbin/xend is obviously not running. Unfortunately, xen-4.1.2-1.fc16 has a bug where merely trying to probe xend status on a non-xen kernel causes xend to issue an ABRT crash report: https://bugzilla.redhat.com/show_bug.cgi?id=728696 Even though libvirt (correctly) skips the test, the xend crash report is unnecessary noise. Fix this by first filtering out non-xen kernels even before attempting to probe xend. The test still runs and passes (if run as root) on a RHEL 5 xen kernel after this patch. * tests/reconnect.c (mymain): Skip xend probe on non-xen kernel. * tests/statstest.c (mymain): Likewise. --- Pushing under the trivial rule (can't quite call it the build-breaker, since the libvirt testsuite itself still passed). tests/reconnect.c | 9 ++++++++- tests/statstest.c | 9 ++++++++- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/tests/reconnect.c b/tests/reconnect.c index d4aa9f3..90af830 100644 --- a/tests/reconnect.c +++ b/tests/reconnect.c @@ -2,6 +2,7 @@ #include <stdio.h> #include <stdlib.h> +#include <sys/utsname.h> #include "internal.h" #include "testutils.h" @@ -20,8 +21,14 @@ mymain(void) virDomainPtr dom; int status; virCommandPtr cmd; + struct utsname ut; - /* skip test if xend is not running */ + /* Skip test if xend is not running. Calling xend on a non-xen + kernel causes some versions of xend to issue a crash report, so + we first probe uname results. */ + uname(&ut); + if (strstr(ut.release, "xen") == NULL) + return EXIT_AM_SKIP; cmd = virCommandNewArgList("/usr/sbin/xend", "status", NULL); if (virCommandRun(cmd, &status) != 0 || status != 0) { virCommandFree(cmd); diff --git a/tests/statstest.c b/tests/statstest.c index 18cdc5c..fff69a3 100644 --- a/tests/statstest.c +++ b/tests/statstest.c @@ -3,6 +3,7 @@ #include <stdio.h> #include <stdlib.h> #include <string.h> +#include <sys/utsname.h> #include "stats_linux.h" #include "internal.h" @@ -47,8 +48,14 @@ mymain(void) int ret = 0; int status; virCommandPtr cmd; + struct utsname ut; - /* skip test if xend is not running */ + /* Skip test if xend is not running. Calling xend on a non-xen + kernel causes some versions of xend to issue a crash report, so + we first probe uname results. */ + uname(&ut); + if (strstr(ut.release, "xen") == NULL) + return EXIT_AM_SKIP; cmd = virCommandNewArgList("/usr/sbin/xend", "status", NULL); if (virCommandRun(cmd, &status) != 0 || status != 0) { virCommandFree(cmd); -- 1.7.7.1

1 0

[libvirt] [PATCH] build: fix compile error with no macvtap
by Eric Blake 18 Nov '11

18 Nov '11

Since commit 6ec8288a, compilation has failed on RHEL 5: util/virnetdevmacvlan.c:672: error: conflicting types for 'virNetDevMacVLanCreateWithVPortProfile' * src/util/virnetdevmacvlan.c (virNetDevMacVLanCreateWithVPortProfile): Add missing parameter. --- (That function name is a mouthful!) Pushing under the build-breaker rule. src/util/virnetdevmacvlan.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c index 98b0f9a..12fc411 100644 --- a/src/util/virnetdevmacvlan.c +++ b/src/util/virnetdevmacvlan.c @@ -662,6 +662,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char *ifname ATTRIBUTE_UNUSED, const unsigned char *macaddress ATTRIBUTE_UNUSED, const char *linkdev ATTRIBUTE_UNUSED, enum virNetDevMacVLanMode mode ATTRIBUTE_UNUSED, + bool withTap ATTRIBUTE_UNUSED, int vnet_hdr ATTRIBUTE_UNUSED, const unsigned char *vmuuid ATTRIBUTE_UNUSED, virNetDevVPortProfilePtr virtPortProfile ATTRIBUTE_UNUSED, -- 1.7.7.1

1 0

[libvirt] [PATCH V5 00/10] Make inner workings of nwfilters more flexible + extensions
by Stefan Berger 18 Nov '11

18 Nov '11

The following series of patches re-does some of the inner workings of nwfilters with the goal to enable users to write filters that have other than the system-known chains supported right now ('root','arp','rarp','ipv4' and 'ipv6'). Ideally users should be able to provide a chain name in the chains XML attribute and either be able to jump to it as an 'action' or have the chain created automatically as it is the case right now for those chains enumerated before. The latter is now added in this patch series as well. I am first introducing internal priorities for the chains mentioned above so that their creation can be made more flexible -- currently their creation and the order in which they are accessed is hardcoded. This largely does away with the hardcoded stuff. All assigned priorities have negative values. Later on the priorities for the chains are made accessible via an XML attribute. Further, filters will be automatically accessed from the (ebtables) interface 'root' chain using the prefix of the name of the chain. As an example, the following filter will be accessed from the root chain for 'arp' packets since its name 'arp-xyz' has the prefix 'arp'. <filter name='test-arp-xyz' chain='arp-xyz' priority='-650'> <uuid>94abeecc-c956-0ac8-1f49-a06ee8995688</uuid> <rule action='accept' direction='out' priority='100'> <arp opcode='Request_Reverse' arpsrcmacaddr='$MAC' arpdstmacaddr='$MAC' arpsrcipaddr='0.0.0.0' arpdstipaddr='0.0.0.0'/> </rule> <rule action='accept' direction='inout' priority='500'/> </filter> In another step the priorities of rules is extended to also allow negativ values. This then allows the creation of rules and chains in the interface 'root' chain to be mixed so that the following layout becomes possible: Bridge chain: libvirt-I-vnet0, entries: 6, policy: ACCEPT -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arp -p ARP -j ACCEPT -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -j DROP In the above list of rules the '-p ARP -j ACCEPT' can now be found in between the 'jumps' to protocol-specific chains, which allows for more efficient rule evaluation. I did testing with the test cases in libvirt-tck as well as those in the tests/ directory and did not see any regressions. v5: - addressed Eric Blake's comments v4: - assign priority to chain according to name prefix - change default (internal) priorities of chains (by +200) - fix memory leak Regards, Stefan

2 29

[libvirt] [PATCH] build: fix accidental POTFILES.in regression
by Eric Blake 18 Nov '11

18 Nov '11

The original patch for commit 4789fb2 considered renaming a file, then backed out the name change, but forgot to back out the POTFILES.in change, resulting in 'make syntax-check' failure. --- Pushing under the build-breaker rule. po/POTFILES.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/po/POTFILES.in b/po/POTFILES.in index 7485088..403d94b 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -152,5 +152,5 @@ src/xenapi/xenapi_utils.c src/xenxs/xen_sxpr.c src/xenxs/xen_xm.c tools/console.c -tools/libvirt-guests.init.in +tools/libvirt-guests.init.sh tools/virsh.c -- 1.7.7.1

1 0

[libvirt] [PATCH V5 0/4] Support for multiple IP addresses using lists
by Stefan Berger 18 Nov '11

18 Nov '11

This patch series builds on the previously posted patch series https://www.redhat.com/archives/libvir-list/2011-October/msg00912.html and introduces the capability to assign a list to a variable and have multiple rules instantiated, one for each item in the list. This means, that if for example a variable like IP has been assigned a list of values IP = [1.2.3.4, 5.6.7.8, 10.0.0.1] it will instantiate 3 rules, which in turn allows us to build filters that can evaluate multiple possible values per field, i.e., allow the filtering for multiple IP addresses (per interface). v5: - addressing Eric Blake's comments v4: - addressing Daniel Berrange's comments - changed (default) behavior of iterator v3: - following Daniel Berrange's comment regarding how a list of items should be represented in the XML v2: - reimplementation of iterator - other nits Regards, Stefan

2 10

[libvirt] [PATCH V6 00/11] Make inner workings of nwfilters more flexible + extensions
by Stefan Berger 18 Nov '11

18 Nov '11

The following series of patches re-does some of the inner workings of nwfilters with the goal to enable users to write filters that have other than the system-known chains supported right now ('root','arp','rarp','ipv4' and 'ipv6'). Ideally users should be able to provide a chain name in the chains XML attribute and either be able to jump to it as an 'action' or have the chain created automatically as it is the case right now for those chains enumerated before. The latter is now added in this patch series as well. I am first introducing internal priorities for the chains mentioned above so that their creation can be made more flexible -- currently their creation and the order in which they are accessed is hardcoded. This largely does away with the hardcoded stuff. All assigned priorities have negative values. Later on the priorities for the chains are made accessible via an XML attribute. Further, filters will be automatically accessed from the (ebtables) interface 'root' chain using the prefix of the name of the chain. As an example, the following filter will be accessed from the root chain for 'arp' packets since its name 'arp-xyz' has the prefix 'arp'. <filter name='test-arp-xyz' chain='arp-xyz' priority='-650'> <uuid>94abeecc-c956-0ac8-1f49-a06ee8995688</uuid> <rule action='accept' direction='out' priority='100'> <arp opcode='Request_Reverse' arpsrcmacaddr='$MAC' arpdstmacaddr='$MAC' arpsrcipaddr='0.0.0.0' arpdstipaddr='0.0.0.0'/> </rule> <rule action='accept' direction='inout' priority='500'/> </filter> In another step the priorities of rules is extended to also allow negativ values. This then allows the creation of rules and chains in the interface 'root' chain to be mixed so that the following layout becomes possible: Bridge chain: libvirt-I-vnet0, entries: 6, policy: ACCEPT -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arp -p ARP -j ACCEPT -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -j DROP In the above list of rules the '-p ARP -j ACCEPT' can now be found in between the 'jumps' to protocol-specific chains, which allows for more efficient rule evaluation. I did testing with the test cases in libvirt-tck as well as those in the tests/ directory and did not see any regressions. v6: - addresses Eric Blake's comments on patches 2, 6, 7, 9 + added documentation patch (11) v5: - addressed Eric Blake's comments v4: - assign priority to chain according to name prefix - change default (internal) priorities of chains (by +200) - fix memory leak Regards, Stefan

2 19