[libvirt] building error
by Wen Congyang
When I build libvirt, I meet the following error:
make[3]: Entering directory `/home/wency/rpmbuild/BUILD/libvirt-0.9.2/daemon'
CC libvirtd-libvirtd.o
CC libvirtd-remote.o
remote.c: In function 'remoteDispatchAuthPolkit':
remote.c:2043: error: invalid initializer
make[3]: *** [libvirtd-remote.o] Error 1
This patch can fix the problem. But I do not know whether it is right.
>From b03a5c08b751440460bf4cb02fea061b77fb3ef5 Mon Sep 17 00:00:00 2001
From: Wen Congyang <wency(a)cn.fujitsu.com>
Date: Wed, 29 Jun 2011 19:04:19 +0800
Subject: [PATCH 1/2] daemon: Fix building error with polkit1
---
daemon/remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index 9e6cf77..042894b 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -2041,7 +2041,7 @@ remoteDispatchAuthPolkit(virNetServerPtr server ATTRIBUTE_UNUSED,
goto authdeny;
}
PROBE(CLIENT_AUTH_ALLOW, "fd=%d, auth=%d, username=%s",
- virNetServerClientGetFD(client), REMOTE_AUTH_POLKIT, ident);
+ virNetServerClientGetFD(client), REMOTE_AUTH_POLKIT, (char *)ident);
VIR_INFO("Policy allowed action %s from pid %d, uid %d",
action, callerPid, callerUid);
ret->complete = 1;
--
1.7.1
12 years, 10 months
[libvirt] [PATCH] build: fix virBufferVasprintf on mingw
by Eric Blake
Gnulib documents that mingw [v]snprintf is broken (it returns -1
on out-of-space, instead of the count of what would have been
printed); but while we were using the snprintf wrapper, we had
not yet been using the vsnprintf wrapper.
* bootstrap.conf (gnulib_modules): Add vsnprintf.
Reported by Matthias Bolte.
---
bootstrap.conf | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/bootstrap.conf b/bootstrap.conf
index 581d60b..302cce8 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -97,6 +97,7 @@ usleep
vasprintf
verify
vc-list-files
+vsnprintf
waitpid
warnings
'
--
1.7.4.4
12 years, 10 months
[libvirt] [PATCH 1/4] libvirtd: avoid memory leak on OOM
by Eric Blake
Detected by Coverity; only strikes on OOM so not serious.
* daemon/libvirtd.c (daemonPidFilePath): Plug leak.
---
daemon/libvirtd.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index 60ee705..06d2077 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -310,8 +310,10 @@ daemonPidFilePath(bool privileged,
if (!(userdir = virGetUserDirectory(geteuid())))
goto error;
- if (virAsprintf(pidfile, "%s/.libvirt/libvirtd.pid", userdir) < 0)
+ if (virAsprintf(pidfile, "%s/.libvirt/libvirtd.pid", userdir) < 0) {
+ VIR_FREE(userdir);
goto no_memory;
+ }
VIR_FREE(userdir);
}
--
1.7.4.4
12 years, 10 months
[libvirt] Network device abstraction aka virtual switch - V3
by Laine Stump
This is a followup to
https://www.redhat.com/archives/libvir-list/2011-April/msg00591.html
(and an even earlier draft) which I alluded to here:
https://www.redhat.com/archives/libvir-list/2011-June/msg00383.html
Network device abstraction aka virtual switch - V3
==================================================
The <interface> element of a guest's domain config in libvirt has a
<source> element that describes what resources on a host will be used
to connect the guest's network interface to the rest of the
world. This is very flexible, allowing several different types of
connection (virtual network, host bridge, direct macvtap connection to
physical interface, qemu usermode, user-defined via an external
script), but currently has the problem that unnecessary details of the
host resources are embedded into the guest's config; if the guest is
migrated to a different host, and that host has a different hardware
or network config (or possibly the same hardware, but that hardware is
currently in use by a different guest), the migration will fail.
I am proposing a change to libvirt's network XML that will allow us to
(optionally - old configs will remain valid) remove the host details
from the guest's domain XML (which can move around from host to host)
and place them in the network XML (which remains with a single host);
the domain XML will then use existing config elements to associate
each guest interface with a "network".
The motivating use case for this change is the "direct" connection
type (which uses macvtap for vepa and vnlink connections directly
between a guest and a physical interface, rather than through a
bridge), but it is applicable for all types of connection. (Another
hopeful side effect of this change will be to make libvirt's network
connection model easier to realize on non-Linux hypervisors (eg,
VMWare ESX) and for other network technologies, such as openvswitch,
VDE, and various VPN implementations).
Background
==========
(parts lifted from Dan Berrange's last mail on this subject)
Currently <network> supports 3 connectivity modes
- Non-routed network, separate subnet (no <forward> element
present)
- Routed network, separate subnet with NAT (<forward mode='nat'/>)
- Routed network, separate subnet (<forward mode='route'/>)
Each of these is implemented in the existing network driver by
creating a bridge device using brctl, and connecting the guest network
interfaces via tap devices (a detail which, now that I've stated it,
you should promptly forget!). All traffic between that bridge and the
outside network is done via the host's IP routing stack (ie, there is
no physical device directly connected to the bridge)
In the future, these two additional routed modes might be useful:
- Routed network, IP subnetting
- Routed network, separate subnet with VPN
The core goal of this proposal, though, is to replace type=bridge and
type=direct from the domain interface XML with new types of <network>
definitions so that the domain can just give "type='network'" and have
all the necessary details filled in at runtime. This basically means
we're adding several bridging modes (the submodes of "direct" have
been flattened out here):
- Bridged network, eth + bridge + tap
- Bridged network, eth + macvtap + vepa
- Bridged network, eth + macvtap + private
- Bridged network, eth + macvtap + passthrough
- Bridged network, eth + macvtap + bridge
Another "future expansion" could be to add:
- Bridged network, with VPN
Likewise, support for other technologies, such as openvswitch and VDE
would each be another entry on this list.
(Dan also listed each of the above "+sriov" separately, but that ends
up being handled in an orthogonal manner (by just specifying a pool of
interfaces for a single network), so I'm only giving the abbreviated
list)
I. Changes to domain <interface> element
========================================
In many cases, the <interface> element of the domain XML will be
identical to what is used now when connecting the interface to a
libvirt-style virtual network:
<interface type='network'>
<source network='red-network'/>
<mac address='xx:xx:xx:xx:xx:xx'/>
</interface>
Depending on the definition of the network "red-network" on the host
the guest was started on / migrated to, this could be either a direct
(macvtap) connection using one of the various direct modes
(vepa/private/bridge/passthrough), a bridge (again, pointed to by the
definition of 'red-network'), or a virtual network (using the current
network definition syntax). This way the same guest could be migrated
not only between macvtap-enabled hosts, but from there to a host using
a bridge, or maybe a host in a remote location that used a virtual
network with a secure tunnel to connect back to the rest of the
red-network.
(Part of the migration process would of course check that the
destination host had a network of the proper name with adequate
available resources, and fail if it didn't; management software at a
level above libvirt would probably filter a list of candidate
migration destinations based on available networks and any various
details of those networks (eg. it could search for only networks using
vepa for the connection), and only attempt migration to one that had
the matching network available).
<virtualport> element of <interface>
------------------------------------
Since many of the attributes/sub-elements of <virtualport> (used by
some modes of "direct" interface connections) are identical for all
interfaces connecting to any given switch, most of the information in
<virtualport> will be optional in the domain's interface definition -
it can be filled in from a similar <virtualport> element that will be
added to the <network> definition.
Some parameters in <virtualport> ("instanceid", for example) must be
unique for every interface, though, so those will still be specified
in the <interface> XML. The two <virtualport> elements will be OR'ed
at runtime to arrive at the actual set of parameters that are
used.
(Open Question: What should be the policy when a parameter is
specified in both places? Should one take precedence? Or should it be
considered an error?)
portgroup attribute of <source>
-------------------------------
The <source> element of an interface definition will be able to
optionally specify a "portgroup" attribute. If portgroup is *NOT*
given, the default (first) portgroup of the network will be used (if
any are defined). If portgroup *IS* specified, the source network must
have a portgroup by that name (or the domain startup/migration will
fail), and the attributes of that portgroup will be used for the
connection. Here is an example <interface> definition that has both a
reduced <virtualport> element, as well as a portgroup attribute:
<interface type='network'>
<source network='red-network' portgroup='engineering'/>
<virtualport type="802.1Qbg">
<parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/>
</virtualport>
<mac address='de:ad:be:ef:ca:fe'/>
</interface>
(The specifics of what can be in a portgroup are given below)
II. Changes to <network> definition
===================================
As Dan has pointed out, any additions to <network> must be designed so
that existing management applications (written to understand <network>
prior to these new additions) will at least recognize that the XML
they've been given is for something new that they don't fully
understand. At the same time, the new types of network definition
should attempt to re-use as much of the existing elements/attributes
as possible, both to make it easier to extend these applications, as
well as to make the status displays of un-updated applications make as
much sense as possible.
Dan's suggestion (which I obviously endorse :-) is that the new types
of network should be specified by extending the choices for <forward
mode='....'>.
He also suggested adding a new "layer='network|link'" attribute to
<forward>. I'm not convinced that item is necessary (it seems
redundant), but am including it here for sake of discussion.
The current modes are:
<forward layer='network' mode='route|nat'/>
(in addition to not listing any mode, which equates to "isolated")
Here are suggested new modes:
<forward layer='link'
mode='bridge-brctl|vepa|private|passthrough|bridge-macvtap'/>
A description of each:
bridge-brctl - equivalent to "<interface type='bridge'>" in the
interface definition. The bridge device to use would be
given in the existing <forward dev='xxx'>. (Dan also
suggests putting this in <network>'s <bridge
name='xxx'/> - opinions?)
(Question: better name for this?)
vepa - same as "<interface type='direct'>..." with <source
mode='vepa'/>
private - <interface type='direct'> ... <source mode='private'/>
passthrough - <interface type='direct'> ... <source mode='passthrough'/>
bridge-macvtap - <interface type='direct'> ... <source mode='bridge'/>
(Question: better name for this?)
Interface Pools
---------------
In many cases, a single host network may have multiple physical
network devices associated with it (especially in the case of an
SRIOV-capable ethernet card, which will have several "virtual
functions" associated with a single physical ethernet connection). The
host will at least want to balance the load of multiple guests between
these multiple devices, and may even require (in the case of
passthrough mode, for example) that only a single guest interface be
attached to each host device.
The current specification for <forward> only allows for a single "dev"
attribute, though. In order to support multiple device names, we will
extend <forward> to allow 0 or more <interface> sub-elements:
<forward mode='vepa' dev='eth10'/>
<interface dev='eth10'/>
<interface dev='eth11'/>
<interface dev='eth12'/>
<interface dev='eth13'/>
</forward>
Note that, as a convenience, the first of these elements will always
be a duplicate of the "dev" attribute in <forward> itself. (Is this
necessary/desirable?)
In the case of mode='passthrough', only one guest interface can be
connected to a device at a time. libvirt will keep track of which
devices are in use, and attempt to assign a free device; failure to
assign a device will result in a failure of the domain to
start/migrate. For the other direct modes, libvirt will simply keep
track of the number of guest interfaces currently using each device,
and attempt to keep them balanced.
(Open question: where will we keep track of this allocation/assignment?)
Portgroups
-----------
A <portgroup> (sub-element of <network>) is just a way of easily
putting connections to the network into different classes, with each
class having a different level/type of service. Each <network> can
have multiple <portgroup> elements, and each <portgroup> has a name,
as well as various attributes associated with it. The first thing we
will use portgroups for is as an alternate place to specify
<virtualport> parameters:
<portgroup name='engineering'>
<virtualport type="802.1Qbg">
<parameters managerid="11" typeid="1193047" typeidversion="2"/>
</virtualport>
</portgroup>
Anything that is valid in an interface's <virtualport> is also valid here.
The next thing to specify in a portgroup will be bandwidth limiting /
QoS configuration. Since I don't know exactly what's needed for that,
I won't specify it here.
If anything is specified both directly under <network> and in a
<portgroup>, the value in portgroup will take precedence. (Again -
what will the precedence of items specified in the <interface> be?)
EXAMPLES
--------
Examples of 'red-network' for different types of connections (all of
these would work with minor variations of the interface XML given
above, e.g. the 'vepa' version would require <virtualport> in the
interface that specified an instanceid, and if the <interface>
specified a portgroup, it would need to also be in the <network>
definition (even if it was empty aside from name).
<!-- Existing usage - a libvirt virtual network -->
<network>
<name>red-network</name>
<bridge name='virbr0'/>
<forward layer='network' mode='route'/>
...
</network>
<!-- The simplest - an existing host bridge -->
<network>
<name>red-network</name>
<forward mode='bridge-brctl' dev='br0'/>
</network>
<!-- A macvtap connection to a vepa bridge -->
<network>
<name>red-network</name>
<forward layer='link' mode='vepa' dev='eth10'/>
<virtualport type='802.1Qbg'>
<parameters managerid='11' typeid='1193047' typeidversion='2'/>
</virtualport>
<!-- NB: if <interface> doesn't specify portgroup, -->
<!-- 'accounting' is assumed -->
<portgroup name='accounting'>
<virtualport>
<parameters typeid='22'/>
</virtualport>
</portgroup>
<portgroup name='engineering'>
<virtualport>
<parameters typeid='33'/>
</virtualport>
</portgroup>
</network>
<!-- A macvtap passthrough connection (one guest interface per dev) -->
<network>
<name>red-network</name>
<forward layer='link' mode='passthrough' dev='eth10'/>
<interface dev='eth10'/>
<interface dev='eth11'/>
<interface dev='eth12'/>
<interface dev='eth13'/>
<interface dev='eth14'/>
<interface dev='eth15'/>
<interface dev='eth16'/>
<interface dev='eth17'/>
</forward>
</network>
=============
Open Questions:
* Is there a good reason to include the "layer='network|link'"
attribute in forward? (maybe just because it's useful info for a
management application that doesn't know the details of the modes?)
Or is it redundant?
* What should be the policy when a virtualport parameter is specified
in both the <interface> and the <network>/<portgroup>? Should one take
precedence? Or should it be considered an error?
* Is it okay for the domain's own definition to specify what portgroup
it will be in? Or are there cases where we want to allow someone to
modify their domain XML, but force them into a particular portgroup
beyond their control?
* Is it really necessary/desirable for the first ethernet device in a
pool to be duplicated in the <forward dev='xxx'...> attribute? Or
can that attribute be omitted when there is a pool of devices?
* Where will we keep track of the count of guest interfaces connected
to each host interface device, and where will we keep track of which
device is being used by a particular guest interface? In the
network/domain XML?
* Does anyone have better names for "brctl-bridge" and
"macvtap-bridge"?
12 years, 10 months
[libvirt] FreeBSD Port, update to 0.9.2 compile error
by Jason Helfman
Hi,
I am trying to update the port for libvirt to 0.9.2, but am receiving a new
compiling error, that I have not seen yet.
console.c:280: warning: declaration of 'devname' shadows a global declaration [-Wshadow]
/usr/include/stdlib.h:264: warning: shadowed declaration is here [-Wshadow]
CC virsh-virsh.o
CCLD virsh
GEN virt-xml-validate
GEN virt-pki-validate
gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/tools'
gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/tools'
Making all in docs
gmake[2]: Entering directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs'
GEN libvirt-api.xml
./apibuild.py: not found
gmake[2]: *** [libvirt-api.xml] Error 127
gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2/docs'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.2'
gmake: *** [all] Error 2
*** Error code 1
Stop in /home/jhelfman/ports/devel/libvirt.
Any thoughts?
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
12 years, 10 months
[libvirt] [PATCHv2] build: consistently use CFLAGS
by Eric Blake
According to the automake manual, CPPFLAGS (aka INCLUDES, as spelled
in automake 1.9.6) should only include -I, -D, and -U directives; more
generic directives like -Wall belong in CFLAGS since they affect more
phases of the build process. Therefore, we should be sticking CFLAGS
additions into a CFLAGS container, not a CPPFLAGS container.
* src/Makefile.am (INCLUDES): Move CFLAGS items...
(AM_CFLAGS): ...to their proper location.
* python/Makefile.am (INCLUDES, AM_CFLAGS): Likewise.
* tests/Makefile.am (INCLUDES, AM_CFLAGS): Likewise.
---
v1 had no review:
https://www.redhat.com/archives/libvir-list/2011-May/msg01934.html
changes from v1: rebase to latest
I tested it on top of these two patches, hopefully they'll be ack'd first:
https://www.redhat.com/archives/libvir-list/2011-June/msg01537.html
https://www.redhat.com/archives/libvir-list/2011-June/msg01486.html
python/Makefile.am | 5 +++--
src/Makefile.am | 15 +++++++--------
tests/Makefile.am | 8 +++++---
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/python/Makefile.am b/python/Makefile.am
index 432ad70..0edb3e4 100644
--- a/python/Makefile.am
+++ b/python/Makefile.am
@@ -3,12 +3,13 @@
SUBDIRS= . tests
INCLUDES = \
- $(WARN_CFLAGS) \
- $(PYTHON_INCLUDES) \
+ $(PYTHON_INCLUDES) \
-I$(top_srcdir)/include \
-I$(top_builddir)/include \
-I$(top_builddir)/$(subdir)
+AM_CFLAGS = $(WARN_CFLAGS)
+
DOCS_DIR = $(datadir)/doc/libvirt-python-$(LIBVIRT_VERSION)
DOCS = ${srcdir}/TODO
diff --git a/src/Makefile.am b/src/Makefile.am
index 4ba3ea7..10ee20a 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -3,20 +3,19 @@
# No libraries with the exception of LIBXML should be listed
# here. List them against the individual XXX_la_CFLAGS targets
# that actually use them
-INCLUDES = \
- -I$(top_srcdir)/gnulib/lib \
+INCLUDES = -I$(top_srcdir)/gnulib/lib \
-I../gnulib/lib \
-I../include \
-I@top_srcdir@/src/util \
-I@top_srcdir@/include \
- $(DRIVER_MODULE_CFLAGS) \
+ -DIN_LIBVIRT
+
+AM_CFLAGS = $(DRIVER_MODULE_CFLAGS) \
$(LIBXML_CFLAGS) \
$(WARN_CFLAGS) \
- $(LOCK_CHECKING_CFLAGS) \
- -DIN_LIBVIRT \
- $(WIN32_EXTRA_CFLAGS)
-
-AM_CFLAGS = $(COVERAGE_CFLAGS)
+ $(LOCK_CHECKING_CFLAGS) \
+ $(WIN32_EXTRA_CFLAGS) \
+ $(COVERAGE_CFLAGS)
AM_LDFLAGS = $(COVERAGE_LDFLAGS)
EXTRA_DIST = $(conf_DATA)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 38a353f..984d8fd 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -8,15 +8,17 @@ INCLUDES = \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src \
-I$(top_srcdir)/src/util \
- -I$(top_srcdir)/src/conf \
+ -I$(top_srcdir)/src/conf
+
+AM_CFLAGS = \
$(LIBXML_CFLAGS) \
$(GNUTLS_CFLAGS) \
$(SASL_CFLAGS) \
$(SELINUX_CFLAGS) \
$(APPARMOR_CFLAGS) \
$(YAJL_CFLAGS) \
- $(COVERAGE_CFLAGS) \
- $(WARN_CFLAGS)
+ $(COVERAGE_CFLAGS) \
+ $(WARN_CFLAGS)
if WITH_DRIVER_MODULES
INCLUDES += \
--
1.7.4.4
12 years, 10 months
[libvirt] [PATCH] build: remove dead variables
by Eric Blake
Detected by Coverity. No real harm in leaving these, but fixing
them cuts down on the noise for future analysis.
* src/rpc/virnetserver.c (virNetServerAddService): Delete unused
entry.
* src/util/sysinfo.c (virSysinfoRead): Delete dead assignment to
base.
---
src/rpc/virnetserver.c | 7 +++----
src/util/sysinfo.c | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/rpc/virnetserver.c b/src/rpc/virnetserver.c
index 0ef81fd..5e1719b 100644
--- a/src/rpc/virnetserver.c
+++ b/src/rpc/virnetserver.c
@@ -529,11 +529,10 @@ int virNetServerAddService(virNetServerPtr srv,
#if HAVE_AVAHI
if (mdnsEntryName) {
int port = virNetServerServiceGetPort(svc);
- virNetServerMDNSEntryPtr entry;
- if (!(entry = virNetServerMDNSAddEntry(srv->mdnsGroup,
- mdnsEntryName,
- port)))
+ if (!virNetServerMDNSAddEntry(srv->mdnsGroup,
+ mdnsEntryName,
+ port))
goto error;
}
#endif
diff --git a/src/util/sysinfo.c b/src/util/sysinfo.c
index f4edde9..eec996b 100644
--- a/src/util/sysinfo.c
+++ b/src/util/sysinfo.c
@@ -472,7 +472,7 @@ virSysinfoRead(void) {
ret->nmemory = 0;
ret->memory = NULL;
- if ((base = virSysinfoParseMemory(base, ret)) == NULL)
+ if (virSysinfoParseMemory(base, ret) == NULL)
goto no_memory;
cleanup:
--
1.7.4.4
12 years, 10 months
[libvirt] [Libvirt-test-API][PATCH 1/6] add createWithFlags() API and modify migrate() function to align with libvirt Python migration definition
by Guannan.ren
---
lib/domainAPI.py | 57 ++++++++++++++++++++++++++++++++++++------------------
1 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/lib/domainAPI.py b/lib/domainAPI.py
index 0c725f8..5667c20 100644
--- a/lib/domainAPI.py
+++ b/lib/domainAPI.py
@@ -40,18 +40,6 @@ append_path(result.group(0))
import exception
-# DomainMigrateFlags
-VIR_MIGRATE_LIVE = 1
-
-# DomainState
-VIR_DOMAIN_NOSTATE = 0
-VIR_DOMAIN_RUNNING = 1
-VIR_DOMAIN_BLOCKED = 2
-VIR_DOMAIN_PAUSED = 3
-VIR_DOMAIN_SHUTDOWN = 4
-VIR_DOMAIN_SHUTOFF = 5
-VIR_DOMAIN_CRASHED = 6
-
class DomainAPI(object):
def __init__(self, connection):
self.conn = connection
@@ -182,6 +170,16 @@ class DomainAPI(object):
code = e.get_error_code()
raise exception.LibvirtAPI(message, code)
+ def start_with_flags(self, domname, flags = 0):
+ try:
+ dom_obj = self.get_defined_obj(domname)
+ retval = dom_obj.createWithFlags(flags)
+ return retval
+ except libvirt.libvirtError, e:
+ message = e.get_error_message()
+ code = e.get_error_code()
+ raise exception.LibvirtAPI(message, code)
+
def suspend(self, domname):
try:
dom_obj = self.get_domain_by_name(domname)
@@ -223,10 +221,10 @@ class DomainAPI(object):
code = e.get_error_code()
raise exception.LibvirtAPI(message, code)
- def migrate(self, domname, dconn, flags = VIR_MIGRATE_LIVE):
+ def migrate(self, domname, dconn, flags, dname = None, uri = None, bandwidth = 0):
try:
dom_obj = self.get_domain_by_name(domname)
- retval = dom_obj.migrate(dconn, flags, None, None, 0)
+ retval = dom_obj.migrate(dconn, flags, dname, uri, 0)
return retval
except libvirt.libvirtError, e:
message = e.get_error_message()
@@ -484,7 +482,7 @@ class DomainAPI(object):
dom_obj = self.get_domain_by_name(domname)
state = dom_obj.info()
if state[0] == VIR_DOMAIN_NOSTATE:
- dom_state = 'no state'
+ dom_state = 'nostate'
elif state[0] == VIR_DOMAIN_RUNNING:
dom_state = 'running'
elif state[0] == VIR_DOMAIN_BLOCKED:
@@ -581,7 +579,7 @@ class DomainAPI(object):
code = e.get_error_code()
raise exception.LibvirtAPI(message, code)
- def isActive(self, domname):
+ def is_active(self, domname):
try:
dom_obj = self.get_domain_by_name(domname)
return dom_obj.isActive()
@@ -590,7 +588,7 @@ class DomainAPI(object):
code = e.get_error_code()
raise exception.LibvirtAPI(message, code)
- def isPersistent(self, domname):
+ def is_persistent(self, domname):
try:
dom_obj = self.get_domain_by_name(domname)
return dom_obj.isPersistent()
@@ -662,10 +660,10 @@ class DomainAPI(object):
code = e.get_error_code()
raise exception.LibvirtAPI(message, code)
- def migrate_to_uri(self, domname, duri, dname, bandwidth, flag = 0):
+ def migrate_to_uri(self, domname, duri, flags, dname = None, bandwidth = 0):
try:
dom_obj = self.get_domain_by_name(domname)
- return dom_obj.migrateToURI(duri, dname, bandwidth, flag)
+ return dom_obj.migrateToURI(duri, flags, dname, bandwidth)
except libvirt.libvirtError, e:
message = e.get_error_message()
code = e.get_error_code()
@@ -761,3 +759,24 @@ class DomainAPI(object):
code = e.get_error_code()
raise exception.LibvirtAPI(message, code)
+
+# DomainState
+VIR_DOMAIN_NOSTATE = 0
+VIR_DOMAIN_RUNNING = 1
+VIR_DOMAIN_BLOCKED = 2
+VIR_DOMAIN_PAUSED = 3
+VIR_DOMAIN_SHUTDOWN = 4
+VIR_DOMAIN_SHUTOFF = 5
+VIR_DOMAIN_CRASHED = 6
+
+
+# virDomainMigrateFlags
+VIR_MIGRATE_LIVE = 1
+VIR_MIGRATE_PEER2PEER = 2
+VIR_MIGRATE_TUNNELLED = 4
+VIR_MIGRATE_PERSIST_DEST = 8
+VIR_MIGRATE_UNDEFINE_SOURCE = 16
+VIR_MIGRATE_PAUSED = 32
+VIR_MIGRATE_NON_SHARED_DISK = 64
+VIR_MIGRATE_NON_SHARED_INC = 128
+
--
1.7.1
12 years, 10 months
[libvirt] [PATCH] Add test case for parsing JSON docs
by Daniel P. Berrange
While investigating some memory leaks it was unclear whether the
JSON code correctly free'd all memory during parsing. Add a test
case which can be run under valgrind to clearly demonstrate that
the parser is leak free.
* tests/Makefile.am: Add 'jsontest'
* tests/jsontest.c: A few simple JSON parsing tests
---
tests/Makefile.am | 14 +++++++
tests/jsontest.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 125 insertions(+), 0 deletions(-)
create mode 100644 tests/jsontest.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 7db9d1f..3bde22e 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -14,6 +14,7 @@ INCLUDES = \
$(SASL_CFLAGS) \
$(SELINUX_CFLAGS) \
$(APPARMOR_CFLAGS) \
+ $(YAJL_CFLAGS) \
$(COVERAGE_CFLAGS) \
$(WARN_CFLAGS)
@@ -29,6 +30,7 @@ LDADDS = \
$(SASL_LIBS) \
$(SELINUX_LIBS) \
$(APPARMOR_LIBS) \
+ $(YAJL_LIBS) \
$(WARN_CFLAGS) \
../src/libvirt_test.la \
../gnulib/lib/libgnu.la \
@@ -112,6 +114,10 @@ if WITH_CIL
check_PROGRAMS += object-locking
endif
+if HAVE_YAJL
+check_PROGRAMS += jsontest
+endif
+
check_PROGRAMS += networkxml2xmltest
check_PROGRAMS += networkxml2argvtest
@@ -195,6 +201,10 @@ TESTS = virshtest \
virnetsockettest \
$(test_scripts)
+if HAVE_YAJL
+TESTS += jsontest
+endif
+
if WITH_XEN
TESTS += xml2sexprtest \
sexpr2xmltest \
@@ -443,6 +453,10 @@ hashtest_SOURCES = \
hashtest.c hashdata.h testutils.h testutils.c
hashtest_LDADD = $(LDADDS)
+jsontest_SOURCES = \
+ jsontest.c jsondata.h testutils.h testutils.c
+jsontest_LDADD = $(LDADDS)
+
if WITH_LIBVIRTD
eventtest_SOURCES = \
eventtest.c testutils.h testutils.c
diff --git a/tests/jsontest.c b/tests/jsontest.c
new file mode 100644
index 0000000..412f475
--- /dev/null
+++ b/tests/jsontest.c
@@ -0,0 +1,111 @@
+#include <config.h>
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <time.h>
+
+#include "internal.h"
+#include "json.h"
+#include "testutils.h"
+
+struct testInfo {
+ const char *doc;
+ bool pass;
+};
+
+
+static int
+testJSONFromString(const void *data)
+{
+ const struct testInfo *info = data;
+ virJSONValuePtr json;
+ int ret = -1;
+
+ json = virJSONValueFromString(info->doc);
+
+ if (info->pass) {
+ if (!json) {
+ if (virTestGetVerbose())
+ fprintf(stderr, "Fail to parse %s\n", info->doc);
+ ret = -1;
+ goto cleanup;
+ } else {
+ if (virTestGetDebug())
+ fprintf(stderr, "Parsed %s\n", info->doc);
+ }
+ } else {
+ if (json) {
+ if (virTestGetVerbose())
+ fprintf(stderr, "Should not have parsed %s\n", info->doc);
+ ret = -1;
+ goto cleanup;
+ } else {
+ if (virTestGetDebug())
+ fprintf(stderr, "Fail to parse %s\n", info->doc);
+ }
+ }
+
+ ret = 0;
+
+cleanup:
+ virJSONValueFree(json);
+ return ret;
+}
+
+
+static int
+mymain(void)
+{
+ int ret = 0;
+
+#define DO_TEST_FULL(name, cmd, doc, pass) \
+ do { \
+ struct testInfo info = { doc, pass }; \
+ if (virtTestRun(name, 1, testJSON ## cmd, &info) < 0) \
+ ret = -1; \
+ } while (0)
+
+#define DO_TEST_PARSE(name, doc) \
+ DO_TEST_FULL(name, FromString, doc, true)
+
+ DO_TEST_PARSE("Simple", "{\"return\": {}, \"id\": \"libvirt-1\"}");
+ DO_TEST_PARSE("NotSoSimple", "{\"QMP\": {\"version\": {\"qemu\":"
+ "{\"micro\": 91, \"minor\": 13, \"major\": 0},"
+ "\"package\": \" (qemu-kvm-devel)\"}, \"capabilities\": []}}");
+
+
+ DO_TEST_PARSE("Harder", "{\"return\": [{\"filename\": "
+ "\"unix:/home/berrange/.libvirt/qemu/lib/tck.monitor,server\","
+ "\"label\": \"charmonitor\"}, {\"filename\": \"pty:/dev/pts/158\","
+ "\"label\": \"charserial0\"}], \"id\": \"libvirt-3\"}");
+
+ DO_TEST_PARSE("VeryHard", "{\"return\": [{\"name\": \"quit\"}, {\"name\":"
+ "\"eject\"}, {\"name\": \"change\"}, {\"name\": \"screendump\"},"
+ "{\"name\": \"stop\"}, {\"name\": \"cont\"}, {\"name\": "
+ "\"system_reset\"}, {\"name\": \"system_powerdown\"}, "
+ "{\"name\": \"device_add\"}, {\"name\": \"device_del\"}, "
+ "{\"name\": \"cpu\"}, {\"name\": \"memsave\"}, {\"name\": "
+ "\"pmemsave\"}, {\"name\": \"migrate\"}, {\"name\": "
+ "\"migrate_cancel\"}, {\"name\": \"migrate_set_speed\"},"
+ "{\"name\": \"client_migrate_info\"}, {\"name\": "
+ "\"migrate_set_downtime\"}, {\"name\": \"netdev_add\"}, "
+ "{\"name\": \"netdev_del\"}, {\"name\": \"block_resize\"},"
+ "{\"name\": \"balloon\"}, {\"name\": \"set_link\"}, {\"name\":"
+ "\"getfd\"}, {\"name\": \"closefd\"}, {\"name\": \"block_passwd\"},"
+ "{\"name\": \"set_password\"}, {\"name\": \"expire_password\"},"
+ "{\"name\": \"qmp_capabilities\"}, {\"name\": "
+ "\"human-monitor-command\"}, {\"name\": \"query-version\"},"
+ "{\"name\": \"query-commands\"}, {\"name\": \"query-chardev\"},"
+ "{\"name\": \"query-block\"}, {\"name\": \"query-blockstats\"}, "
+ "{\"name\": \"query-cpus\"}, {\"name\": \"query-pci\"}, {\"name\":"
+ "\"query-kvm\"}, {\"name\": \"query-status\"}, {\"name\": "
+ "\"query-mice\"}, {\"name\": \"query-vnc\"}, {\"name\": "
+ "\"query-spice\"}, {\"name\": \"query-name\"}, {\"name\": "
+ "\"query-uuid\"}, {\"name\": \"query-migrate\"}, {\"name\": "
+ "\"query-balloon\"}], \"id\": \"libvirt-2\"}");
+
+ return (ret == 0) ? EXIT_SUCCESS : EXIT_FAILURE;
+}
+
+VIRT_TEST_MAIN(mymain)
--
1.7.4.4
12 years, 10 months
[libvirt] [PATCH] build: simplify sanlock distribution
by Eric Blake
EXTRA_DIST is intended for files that must unconditionally be
part of the tarball, so it should be outside HAVE_SANLOCK.
Once that is fixed, then there is no need to cp an unchanged
qemu-sanlock.conf from srcdir to builddir in a VPATH build,
not to mention that $(builddir) is not supported in the automake
in use in RHEL 5.
* src/Makefile.am ($(builddir)/locking/%-sanlock.conf): Delete.
(BUILT_SOURCES): No need to build qemu-sanlock.conf.
(EXTRA_DIST): Always ship sanlock .aug and .conf files.
---
As promised in:
https://www.redhat.com/archives/libvir-list/2011-June/msg01448.html
I'm starting a 'make distcheck' overnight to fully test this,
but think that it will pass without issues.
src/Makefile.am | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 8f99cc2..bfbaa06 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1186,6 +1186,10 @@ libvirt_qemu_la_LIBADD = libvirt.la $(CYGWIN_EXTRA_LIBADD)
EXTRA_DIST += $(LIBVIRT_QEMU_SYMBOL_FILE)
+EXTRA_DIST += locking/sanlock.conf \
+ locking/libvirt_sanlock.aug \
+ locking/test_libvirt_sanlock.aug
+
if HAVE_SANLOCK
lockdriverdir = $(libdir)/libvirt/lock-driver
lockdriver_LTLIBRARIES = sanlock.la
@@ -1199,20 +1203,11 @@ sanlock_la_LIBADD = -lsanlock \
augeas_DATA += locking/libvirt_sanlock.aug
augeastest_DATA += locking/test_libvirt_sanlock.aug
-EXTRA_DIST += locking/sanlock.conf \
- locking/libvirt_sanlock.aug \
- locking/test_libvirt_sanlock.aug
-
-$(builddir)/locking/%-sanlock.conf: $(srcdir)/locking/sanlock.conf
- $(AM_V_GEN)mkdir locking ; \
- cp $< $@
-
if WITH_QEMU
conf_DATA += locking/qemu-sanlock.conf
-BUILT_SOURCES += locking/qemu-sanlock.conf
endif
else
-EXTRA_DIST += $(LOCK_DRIVER_SANLOCK_SOURCES) locking/sanlock.conf
+EXTRA_DIST += $(LOCK_DRIVER_SANLOCK_SOURCES)
endif
noinst_LTLIBRARIES += libvirt-net-rpc.la libvirt-net-rpc-server.la libvirt-net-rpc-client.la
--
1.7.4.4
12 years, 10 months