[libvirt] [osinfo PATCH 1/8] Add #include <string.h> for strcmp
by Christophe Fergeau
---
tools/osinfo-detect.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tools/osinfo-detect.c b/tools/osinfo-detect.c
index 6afa30a..be36afb 100644
--- a/tools/osinfo-detect.c
+++ b/tools/osinfo-detect.c
@@ -23,6 +23,7 @@
*/
#include <osinfo/osinfo.h>
+#include <string.h>
#define FORMAT_STR_PLAIN "plain"
#define FORMAT_STR_ENV "env"
--
1.7.7.1
13 years
[libvirt] virt-viewer, requirement question
by Jason Helfman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
I am the port maintainer for libvirt, and associated tools, in the FreeBSD
Project.
I was wondering if "Require SPICE-GTK >= 0.6.0" for virt-viewer, is
accurate, or is this optional.
Thanks,
Jason
- --
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iF4EAREIAAYFAk7Fs78ACgkQXpKtZoyM+6UjQQD/a325xAeqwky8gEecZ5prlhrt
hrW1J0aNohkdZNUR0xgA/24bMLgC3t9DQOVnlZ66YFvJZe5FmIyps4jjsjLH207f
=6oa6
-----END PGP SIGNATURE-----
13 years
[libvirt] [PATCH] storage: Skips backingStore of virtual snapshot lv
by Osier Yang
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
13 years
[libvirt] [PATCH] build: require more tools from maintainers
by Eric Blake
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
13 years
[libvirt] [PATCH] Don't copy sexpr node value that is an empty string
by Jim Fehlig
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
13 years
[libvirt] "make rpm" failing with git head on RHEL6
by Justin Clift
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
13 years
[libvirt] [PATCH] tests: avoid xend ABRT crash report
by Eric Blake
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
13 years
[libvirt] [PATCH] build: fix compile error with no macvtap
by Eric Blake
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
13 years
[libvirt] [PATCH V5 00/10] Make inner workings of nwfilters more flexible + extensions
by Stefan Berger
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
13 years
[libvirt] [PATCH] build: fix accidental POTFILES.in regression
by Eric Blake
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
13 years
