[libvirt] [PATCH] build: Fix problem of building Python bindings
by Osier Yang
If one specify "--with-python=yes" but no python-devel package
is installed, we ignore it with just a notice message, which
doesn't give clear guide to user.
---
configure.ac | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 190bf40..758c893 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1917,15 +1917,13 @@ if test "$with_python" != "no" ; then
then
PYTHON_INCLUDES=-I/usr/include/python$PYTHON_VERSION
else
- AC_MSG_NOTICE([Could not find python$PYTHON_VERSION/Python.h, disabling bindings])
- with_python=no
+ AC_MSG_ERROR([You must install python-devel to build Python bindings])
fi
fi
fi
fi
else
- AC_MSG_NOTICE([Could not find python interpreter, disabling bindings])
- with_python=no
+ AC_MSG_ERROR([You must install python to build Python bindings])
fi
else
AC_MSG_NOTICE([Could not find python in $with_python, disabling bindings])
--
1.7.4
13 years, 7 months
[libvirt] [PATCH 00/22] Extend remote generator to generate function bodies too
by Matthias Bolte
Richard W.M. Jones suggested [1] that the code that directly deals with the
XDR protocol should be generated. The remote_generate_stubs.pl script
already generates all the headers, just the bodies in the daemon and remote
driver are manually written. But most of the functions just follow simple
patterns. So I extended the generator to exploit this patterns and move
11 kLOC code from manually written to generated code.
During this I came a cross many small variations and problems in the XDR
protocol. For example, NWFilterDefineXML has a flags parameter in the public
API, but it's not transferred in the XDR protocol. Another things is the
variations in the usage of unsigned VS signed types. This comes in two forms.
public API VS XDR procotol and in between different functions. For example,
some functions use int for the flags paramater and some use unsigned int.
This results in quite a lot of special case handling in the generator.
cfg.mk | 10 +-
daemon/Makefile.am | 46 +-
daemon/qemu_dispatch_args.h | 2 +-
daemon/qemu_dispatch_bodies.c | 6 +
daemon/qemu_dispatch_prototypes.h | 2 +-
daemon/qemu_dispatch_ret.h | 2 +-
daemon/qemu_dispatch_table.h | 2 +-
daemon/remote.c | 5765 +----------------------------------
daemon/remote_dispatch_args.h | 2 +-
daemon/remote_dispatch_bodies.c | 5933 +++++++++++++++++++++++++++++++++++
daemon/remote_dispatch_prototypes.h | 80 +-
daemon/remote_dispatch_ret.h | 2 +-
daemon/remote_dispatch_table.h | 158 +-
daemon/remote_generate_stubs.pl | 195 --
daemon/remote_generator.pl | 1198 +++++++
po/POTFILES.in | 1 +
src/Makefile.am | 13 +-
src/remote/qemu_client_bodies.c | 4 +
src/remote/qemu_protocol.c | 2 +-
src/remote/qemu_protocol.h | 2 +-
src/remote/qemu_protocol.x | 2 +-
src/remote/remote_client_bodies.c | 4664 +++++++++++++++++++++++++++
src/remote/remote_driver.c | 4907 +----------------------------
src/remote/remote_protocol.c | 26 +-
src/remote/remote_protocol.h | 26 +-
src/remote/remote_protocol.x | 34 +-
src/remote_protocol-structs | 26 +-
27 files changed, 12093 insertions(+), 11017 deletions(-)
[1] https://www.redhat.com/archives/libvir-list/2011-April/msg00884.html
Matthias
13 years, 7 months
[libvirt] [PATCH] virsh: fix regression in log to file
by Supriya Kannery
Commit 36deff04 introduced a regression due to which virsh is not able
to log to a file - msg_buf was changed from an array to a pointer
without corresponding change to usage of "sizeof()".
Fix regression in virsh logging
Signed-off-by: Supriya Kannery <supriyak(a)in.ibm.com>
---
tools/virsh.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Index: libvirt/tools/virsh.c
===================================================================
--- libvirt.orig/tools/virsh.c
+++ libvirt/tools/virsh.c
@@ -12257,7 +12257,7 @@ vshOutputLogFile(vshControl *ctl, int lo
*/
gettimeofday(&stTimeval, NULL);
stTm = localtime(&stTimeval.tv_sec);
- snprintf(msg_buf, sizeof(msg_buf),
+ snprintf(msg_buf, MSG_BUFFER,
"[%d.%02d.%02d %02d:%02d:%02d ",
(1900 + stTm->tm_year),
(1 + stTm->tm_mon),
@@ -12265,7 +12265,7 @@ vshOutputLogFile(vshControl *ctl, int lo
(stTm->tm_hour),
(stTm->tm_min),
(stTm->tm_sec));
- snprintf(msg_buf + strlen(msg_buf), sizeof(msg_buf) - strlen(msg_buf),
+ snprintf(msg_buf + strlen(msg_buf), MSG_BUFFER - strlen(msg_buf),
"%s] ", SIGN_NAME);
switch (log_level) {
case VSH_ERR_DEBUG:
@@ -12287,13 +12287,13 @@ vshOutputLogFile(vshControl *ctl, int lo
lvl = LVL_DEBUG;
break;
}
- snprintf(msg_buf + strlen(msg_buf), sizeof(msg_buf) - strlen(msg_buf),
+ snprintf(msg_buf + strlen(msg_buf), MSG_BUFFER - strlen(msg_buf),
"%s ", lvl);
- vsnprintf(msg_buf + strlen(msg_buf), sizeof(msg_buf) - strlen(msg_buf),
+ vsnprintf(msg_buf + strlen(msg_buf), MSG_BUFFER - strlen(msg_buf),
msg_format, ap);
if (msg_buf[strlen(msg_buf) - 1] != '\n')
- snprintf(msg_buf + strlen(msg_buf), sizeof(msg_buf) -
strlen(msg_buf), "\n");
+ snprintf(msg_buf + strlen(msg_buf), MSG_BUFFER -
strlen(msg_buf), "\n");
/* write log */
if (safewrite(ctl->log_fd, msg_buf, strlen(msg_buf)) < 0) {
13 years, 7 months
[libvirt] [PATCH 0/6] Introduce a new migration protocol to QEMU driver
by Daniel P. Berrange
The current migration protocol has several flaws
- No initial hook on the source host to do work before
the dst VM is launched
- No ability to restart src VM if dst fails to recv all
migration data, but src successfully sent it all
This introduces a new 5 step migration process to address
this limitation. To support features such as seemless
migration of SPICE clients, and lock driver state passing
this now makes use of the migration cookie feature too
13 years, 7 months
[libvirt] [PATCH] lxc: Do not try to reconnect inactive domain when do lxcStartup
by Osier Yang
Otherwise if there are inactive lxc domains, lxcStartup will
try to reconnect to sockets of these domains, which results in
errors in libvirtd log.
---
src/lxc/lxc_driver.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
index e905302..ef7827b 100644
--- a/src/lxc/lxc_driver.c
+++ b/src/lxc/lxc_driver.c
@@ -1992,6 +1992,9 @@ lxcReconnectVM(void *payload, const void *name ATTRIBUTE_UNUSED, void *opaque)
virDomainObjLock(vm);
+ if (!virDomainObjIsActive(vm))
+ goto cleanup;
+
priv = vm->privateData;
if ((priv->monitor = lxcMonitorClient(driver, vm)) < 0) {
goto cleanup;
--
1.7.4
13 years, 8 months
[libvirt] [PATCH] tests: Update valgrind suppressions file
by Matthias Bolte
---
tests/.valgrind.supp | 58 +++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/tests/.valgrind.supp b/tests/.valgrind.supp
index 4af10b1..68cfa0c 100644
--- a/tests/.valgrind.supp
+++ b/tests/.valgrind.supp
@@ -258,14 +258,58 @@
Memcheck:Param
capget(data)
fun:capget
+ fun:*
fun:capng_clear
+ fun:virClearCapabilities
fun:__virExec
fun:virExecWithHook
- fun:virExec
- fun:qemudProbeMachineTypes
- fun:qemudCapsInitGuest
- fun:qemudCapsInit
- fun:qemudStartup
- fun:virStateInitialize
- fun:main
+}
+{
+ libnlMemoryLeak1
+ Memcheck:Leak
+ fun:malloc
+ fun:strdup
+ obj:/usr/lib/libnl.so.1.1
+}
+{
+ libnlMemoryLeak2
+ Memcheck:Leak
+ fun:calloc
+ obj:/usr/lib/libnl.so.1.1
+}
+{
+ libselinuxMemoryLeak1
+ Memcheck:Leak
+ fun:malloc
+ fun:getdelim
+ obj:/lib/libselinux.so.1
+}
+{
+ dashMemoryLeak1
+ Memcheck:Leak
+ fun:malloc
+ obj:/bin/dash
+}
+{
+ dashMemoryLeak2
+ Memcheck:Leak
+ fun:malloc
+ fun:strdup
+ obj:/bin/dash
+}
+{
+ vboxMemoryLeak1
+ Memcheck:Leak
+ ...
+ fun:VBoxNsxpNS_InitXPCOM2
+}
+{
+ libnetcfMemoryLeak1
+ fun:malloc
+ fun:xmlStrndup
+ fun:xmlHashUpdateEntry3
+ fun:*
+ fun:xsltRegisterAllExtras
+ fun:drv_init
+ fun:interfaceOpenInterface
}
--
1.7.0.4
13 years, 8 months
[libvirt] [PATCH v2] Fix disability to run on systems with no PCI bus
by Michal Privoznik
The patch which moved libpciaccess initialization to one place caused
regression - we were not able to run on system with no PCI bus, like
s390(x).
---
src/node_device/node_device_udev.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c
index 2139ef3..fcff252 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -1421,8 +1421,12 @@ static int udevDeviceMonitorShutdown(void)
ret = -1;
}
+#if defined __s390__ || defined __s390x_
+ /* Nothing was initialized, nothing needs to be cleaned up */
+#else
/* pci_system_cleanup returns void */
pci_system_cleanup();
+#endif
return ret;
}
@@ -1595,6 +1599,10 @@ static int udevDeviceMonitorStartup(int privileged)
int ret = 0;
int pciret;
+#if defined __s390__ || defined __s390x_
+ /* On x390(x) system there is no PCI bus.
+ * Therefore there is nothing to initialize here. */
+#else
if ((pciret = pci_system_init()) != 0) {
/* Ignore failure as non-root; udev is not as helpful in that
* situation, but a non-privileged user won't benefit much
@@ -1607,6 +1615,7 @@ static int udevDeviceMonitorStartup(int privileged)
goto out;
}
}
+#endif
if (VIR_ALLOC(priv) < 0) {
virReportOOMError();
--
1.7.4.4
13 years, 8 months
[libvirt] Libvirt and IPSec (was: What about Trusted Virtual Domains???)
by Paolo Smiraglia
Hi to everyone! First of all, sorry for the thread subject change.
Due to the several issues of the Libvirt implementation of the Trusted
Virtual Domains (TVD), I decided to approach the topic in a modular manner.
I think that the first step should be to define the IPSec support or,
more in general, the secure tunnel support for Libvirt. I see the
implementation divided in two step:
1. define a new driver called 'sectunnel' which describes a generic
secure tunnel that will be established using several
technologies (for now using only ipsec)
2. modify the existing 'network' driver by adding the possibility to
specify the 'sectunnel' that
the network have to use in the virtual network definition
As an example, you can see below a possible XML definition of the
network which use a secure tunnel and the corresponding 'sectunnel' XML
definition:
NETWORK DEFINITION
==================
<network>
<name>sec-net</name>
<uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b</uuid>
<bridge name='virbr0' />
<domain name='example' />
...
<sectunnel name='sec-tun' /> <--(specify the 'sectunnel' to use)
</network>
SECTUNNEL DEFINITION
====================
<sectunnel type='ipsec'>
<name>sec-tun</name>
<uuid>8b7fd1b0-4463-43b7-8b6e-8006344aeb66</uuid>
<!-- Security Association definitions -->
<sa>
<secret uuid='...' /> <--(specify the 'secret' which
contains the pre-shared key)
</sa>
<!-- Security Policy definitions -->
<sp>
<src_range address='10.0.0.1' prefixlen='30' port='5000' />
<dst_range address='10.0.0.2' prefixlen='30' port='5000' />
<upperspec protocol='any' />
<policy direction='out' action='ipsec'>
<rule protocol='esp' mode='tunnel' level='require'>
<src address='192.168.0.1' port='55055' />
<dst address='192.168.0.2' port='55055' />
</rule>
</policy>
</sp>
<sp>
<src_range address='10.0.0.2' prefixlen='30' port='5000' />
<dst_range address='10.0.0.1' prefixlen='30' port='5000' />
<upperspec protocol='any' />
<policy direction='in' action='ipsec'>
<rule protocol='esp' mode='tunnel' level='require'>
<src address='192.168.0.2' port='55055' />
<dst address='192.168.0.1' port='55055' />
</rule>
</policy>
</sp>
</sectunnel>
As you can see in the 'sectunnel' XML definition, I use a 'secret'
element. This element is a Libvirt secret [1] and it stores the
pre-shared key used by IPSec to establish the Security Associations
(SA). Obviously this feature requires to define a new usage category in
the 'secret' driver definition.
Another possible way to establish the SA is to use the X.509
certificates. To this purpose, I think that the certificates already
used by Libvirt to setup SSL/TLS remote connections, might be used.
That's all! :-)
What do you think about this possible IPSec implementation?
Thanks in advance for the replies!
Best regards,
PAOLO
LINK LIST
---------
[1] http://libvirt.org/formatsecret.html
--
PAOLO SMIRAGLIA
Department of Control and Computer Engineering
Mobile: +39 (333) 527 3593
Email: paolo.smiraglia(a)polito.it
13 years, 8 months
[libvirt] RFC: virInterface change transaction API
by Laine Stump
I've been asked to implement what some people have termed as a
"transaction-oriented" API for host interface configuration (ie
virInterface*()).
The basic intent is to allow rollback to a known-good config if anything
goes
wrong when changing around the host network config with virInterface*()
functions.
The most straightforward way to achieve this is that prior to calling
virInterfaceDefine/virInterfaceUndefine, the current state of the
host's network configuration (ie the /etc/sysconfig/network-scripts/ifcfg-*
files in the case of Fedora and RHEL) would be saved off somewhere, and
kept around until we're sure the new config is good; once we know that,
we can just eliminate the backup. If, however, the user of virInterface*()
explicitly requests, we could copy the files back; alternately if the system
is rebooted without these known-good files being erased, we would assume
that something went wrong and restore the original config.
As with all other virInterface functions, the details of all this will
be handled by netcf (and below), but since libvirt is the main consumer
of netcf, I figure this is the appropriate place to discuss how it gets
done,
so please let me know any opinions on any piece of this. I plan to start
the implementation "soon", as I want to be finished before the end of
May.
I see 3 layers to this:
1) libvirt
At the libvirt layer, this feature just requires 3 new APIs, which
are directly passed through to netcf:
virInterfaceChangeStart(virConnectPtr conn, unsigned int flags);
virInterfaceChangeCommit(virConnectPtr conn, unsigned int flags);
virInterfaceChangeRollback(virConnectPtr conn, unsigned int flags);
For the initial implementation, these will be simple passthroughs
to similarly named netcf functions. (in the future, it would be
useful for the server side of libvirt to determine if client<->server
connectivity was lost due to the network changes, and automatically
tell netcf to do a rollback).
2) netcf
The netcf api will have these same three APIs, just named slightly
differently:
ncf_change_start(struct netcf *ncf, unsigned int flags);
There are two possibilities for this. Either:
A) call the initscript described below to save all config
files that might possibly be changed (snapshot_config)
or
B) set a flag in *ncf indicating that all future calls
to netcf that would end up modifying a particular
config file should save off that file *if it hasn't
already been saved*.
(A) is simpler, but relies on the initscript having
exact/complete matching knowledge of what files netcf may
change. Should we worry about that and deal with the
complexities of (B), or is (A) good enough for now?
ncf_change_rollback(struct netcf *ncf, unsigned int flags);
Again, two possbilities:
A)
a) save the config of all current interfaces (in memory)
b) call the initscript below to restore the config to its
original state.
c) compare the new config to the old, and:
* bring down any interfaces that no longer exist
(PROBLEM: once an interface has no config files, you can
no longer operate on it with "ifdown")
* bounce any interfaces that have changed
* bring up any interfaces that have been re-added
or
B)
a) ifdown all interfaces
b) call initscript to restore previous config
(rollback_config)
c) ifup all interfaces.
(A) is much simpler, but may lead to unnecessary
difficulties when we bounce interfaces that didn't really
need it. So, the same question oas for ncf_change_start() -
is the more exact operation worth the extra complexity?
ncf_change_commit(struct netcf *ncf, unsigned int flags);
The simplest function - this will just call the initscript
to erase the backup (commit_config).
3) initscript
This initscript will at first live in (be installed by) netcf
(called /etc/init.d/networking-config?), but hopefully it will
eventually be accepted by the initscripts package (which includes
the networking-related initscripts), as it is of general use. (Dan
Kenigsberg already already took a stab at this script last year,
but received no reply from the initscripts maintainers, implying
they may not be too keen on the idea right now - it might take some
convincing ;-)
https://fedorahosted.org/pipermail/initscripts-devel/2010-February/000025...
It will have three commands, one of which will be called
automatically by "start" (the command called automatically at boot
time):
snapshot_config
This will save a copy of (what the script believes are - is this
problematic?) all network-config related files. It may or may not
be called by netcf (see the notes in ncf_start_change() above.
If this function finds that a snapshot has already been taken,
it should fail.
rollback_config (automatically called from "start" at boottime)
This will move back (from the saved copies) all files that were
changed/removed since snapshot, *and delete any files that have
been added*.
Note that this command doesn't need to worry about ifup/ifdown,
because it will be called prior to any other networking startup
(part of the reason that netcf will need to deal with that).
I notice that Dan K's version saves the modified files to a
"rollback-${date}" directory. Does this seem like a good idea?
It's nice to not lose anything, but there is no provision for
eliminating old versions, so it could grow without bound.
commit_config
This will just remove all the files in the save directory.
So, the two problems I have right now:
1) Do we accept the inexact method of just saving all files that match
a list of patterns during *start(), then in *rollback() erasing all
files matching that pattern and copying the old file back? Or do we
need to keep track of what files have been changed/removed and added,
and copy back / delete only those files during rollback?
(A version control system would keep track of this rather nicely,
but that's too complex for something that's intended to be a
failsafe (and that we would also like to eventually be in the base
OS install). Dan B. at one point suggested using patchfiles if I
wanted the save info to keep exact track of which files would need
to be replaced/deleted on rollback, but on further thought this
turns out to not be workable, since we would need to run diff (to
create the patchfile) after all changes had been made, and any
outside changes to any of the files would leave the patchfile
un-appliable, thus causing our "failsafe" to fail :-( ). Therefore,
we will need to rely on the list of globs to tell us what files
need to be deleted, or keep our own list in a separate file.)
2) Is it going to be okay to ifdown all interfaces prior to the
rollback, and ifup all interfaces afterwards? Or must we compare
the new config to the original, and ifdown only those interfaces
that had been previously added/changed, then ifup only those
interfaces that had been previously removed/changed?
3) If anyone has ideas on making the initscript more palatable to the
initscripts people, please speak up! :-) (one comment from an
initscripts
person was that 1) for the general case it would be difficult to
draw the
line on what parts of network connectivity should be included in this
rollback functionality, and 2) at some point this becomes a general
system config problem, and would really be better addressed by a
general system wide config management system. These are both
concerns that need well qualified answers. (I tend to think that this
is intended as a failsafe to prevent unreachable systems, so it should
be as simple as possible, and thus shouldn't be burdened with the
complexity of a full system config management system (which could
also co-exist at a higher level), but better answers are welcome.)
13 years, 8 months
