When testing language bindings it is useful to be able to build
them against an uninstalled libvirt source tree. Add a dummy
set of pkg-config files to allow for this. This can be used by
setting
export PKG_CONFIG_PATH=/path/to/libvirt/git/src
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
For some reason there have never been pkg-config files created
for the libvirt-qemu.so and libvirt-lxc.so libraries.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add a helper function virBhyveGetDomainTotalCpuStats() to
obtain process CPU time using kvm (kernel memory interface)
and use it to set cpuTime field of the virDomainInfo struct in
bhyveDomainGetInfo().
This commit adds a new example to illustrate peer to
peer domain migration with virDomainMigrateToURI.
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@cloudwatt.com>
We don't support building libvirtd on Win32 since we lack the
fork/exec feature needed for the stateful drivers. Disable this
by default, so users can just do 'mingw32-configure' with no
special args required.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The configure definition previously always defined the GLUSTER_CLI macro
and thus the code needing it wasn't compiled out if the tool wasn't
accessible.
https://bugzilla.redhat.com/show_bug.cgi?id=1072714
Use the "gluster" command line tool to retrieve information about remote
volumes on a gluster server to allow storage pool source lookup.
Unfortunately gluster doesn't provide a management library so that we
could use that directly, instead the RPC calls are hardcoded in the
command line tool.
Commit 5e1d5dd moved the functions using isciadm to util/viriscsi.c,
but ISCSIADM was only defined when the iscsi backend was compiled in.
Define it unconditionally to fix the build (and allow testing
of viriscsi.c) even if iscsi backend is disabled.
configure check for character devices lock path calls
AC_DEFINE_UNQUOTED for VIR_CHRDEV_LOCK_FILE_PATH even if
$with_chrdev_lock_files = "no".
So the locking code in conf/virchrdev.c:
#ifdef VIR_CHRDEV_LOCK_FILE_PATH
is compiled in even if it shouldn't, because VIR_CHRDEV_LOCK_FILE_PATH
is defined as "no", so it tries to create lock files with strange
lock path like 'no/LCK..'.
Fix that by calling AC_DEFINE_UNQUOTED only if $with_chrdev_lock_files
is not 'no'.
Systemd does not forget about the cases, where client service needs to
wait for daemon service to initialize and start accepting new clients.
Setting a dependency in client is not enough as systemd doesn't know
when the daemon has initialized itself and started accepting new
clients. However, it offers a mechanism to solve this. The daemon needs
to call a special systemd function by which the daemon tells "I'm ready
to accept new clients". This is exactly what we need with
libvirtd-guests (client) and libvirtd (daemon). So now, with this
change, libvirt-guests.service is invoked not any sooner than
libvirtd.service calls the systemd notify function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The previous OOM testing support would re-run the entire "main"
method each iteration, failing a different malloc each time.
When a test suite has 'n' allocations, the number of repeats
requires is (n * (n + 1) ) / 2. This gets very large, very
quickly.
This new OOM testing support instead integrates at the
virtTestRun level, so each individual test case gets repeated,
instead of the entire test suite. This means the values of
'n' are orders of magnitude smaller.
The simple usage is
$ VIR_TEST_OOM=1 ./qemuxml2argvtest
...
29) QEMU XML-2-ARGV clock-utc ... OK
Test OOM for nalloc=36 .................................... OK
30) QEMU XML-2-ARGV clock-localtime ... OK
Test OOM for nalloc=36 .................................... OK
31) QEMU XML-2-ARGV clock-france ... OK
Test OOM for nalloc=38 ...................................... OK
...
the second lines reports how many mallocs have to be failed, and thus
how many repeats of the test will be run.
If it crashes, then running under valgrind will often show the problem
$ VIR_TEST_OOM=1 ../run valgrind ./qemuxml2argvtest
When debugging problems it is also helpful to select an individual
test case
$ VIR_TEST_RANGE=30 VIR_TEST_OOM=1 ../run valgrind ./qemuxml2argvtest
When things get really tricky, it is possible to request that just
specific allocs are failed. eg to fail allocs 5 -> 12, use
$ VIR_TEST_RANGE=30 VIR_TEST_OOM=1:5-12 ../run valgrind ./qemuxml2argvtest
In the worse case, you might want to know the stack trace of the
alloc which was failed then VIR_TEST_OOM_TRACE can be set. If it
is set to 1 then it will only print if it thinks a mistake happened.
This is often not reliable, so setting it to 2 will make it print
the stack trace for every alloc that is failed.
$ VIR_TEST_OOM_TRACE=2 VIR_TEST_RANGE=30 VIR_TEST_OOM=1:5-5 ../run valgrind ./qemuxml2argvtest
30) QEMU XML-2-ARGV clock-localtime ... OK
Test OOM for nalloc=36 !virAllocN
/home/berrange/src/virt/libvirt/src/util/viralloc.c:180
virHashCreateFull
/home/berrange/src/virt/libvirt/src/util/virhash.c:144
virDomainDefParseXML
/home/berrange/src/virt/libvirt/src/conf/domain_conf.c:11745
virDomainDefParseNode
/home/berrange/src/virt/libvirt/src/conf/domain_conf.c:12646
virDomainDefParse
/home/berrange/src/virt/libvirt/src/conf/domain_conf.c:12590
testCompareXMLToArgvFiles
/home/berrange/src/virt/libvirt/tests/qemuxml2argvtest.c:106
virtTestRun
/home/berrange/src/virt/libvirt/tests/testutils.c:250
mymain
/home/berrange/src/virt/libvirt/tests/qemuxml2argvtest.c:418 (discriminator 2)
virtTestMain
/home/berrange/src/virt/libvirt/tests/testutils.c:750
??
??:0
_start
??:?
FAILED
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
At this point it has a limited functionality and is highly
experimental. Supported domain operations are:
* define
* start
* destroy
* dumpxml
* dominfo
It's only possible to have only one disk device and only one
network, which should be of type bridge.
In order to make a client-only build successful on RHEL4 (yes, you
read that correctly!), commit 3ed2e54 modified src/util/virnetdev.c so
that the functional version of virNetDevGetVLanID() was only compiled
if GET_VLAN_VID_CMD was defined. However, it is *never* defined, but
is only an enum value, so the proper version was no longer compiled
even on platforms that support it. This resulted in the vlan tag not
being properly set for guest traffic on VEPA mode guest macvtap
interfaces that were bound to a vlan interface (that's the only place
that libvirt currently uses virNetDevGetVLanID)
Since there is no way to compile conditionally based on the presence
of an enum value, this patch modifies configure.ac to check for said
enum value with AC_CHECK_DECLS(), which #defines
HAVE_DECL_GET_VLAN_VID_CMD to 1 if it's successful compiling a test
program that uses GET_VLAN_VID_CMD (and still #defines it, but to 0,
if it's not successful). We can then make the compilation of
virNetDevGetVLanID() conditional on the value of
HAVE_DECL_GET_VLAN_VID_CMD.
On Fedora 20, with wireshark-devel installed, 'make rpm' failed
due to installed but unpackaged files related to wireshark. As
F20 is already released without wireshark, I chose to add a new
sub-package that is enabled only for F21 and later. Furthermore,
all existing wireshark plugins belong to the wireshark package,
so I got to invent behavior of how the first third-party wireshark
module will behave.
* libvirt.spec.in (with_wireshark): Add new conditional.
* configure.ac (ws-plugindir): Improve wording.
Signed-off-by: Eric Blake <eblake@redhat.com>
virKModConfig() - Return a buffer containing kernel module configuration
virKModLoad() - Load a specific module into the kernel configuration
virKModUnload() - Unload a specific module from the kernel configuration
virKModIsBlacklisted() - Determine whether a module is blacklisted within
the kernel configuration
There are a number of pthreads impls available on Win32
these days, in particular the mingw64 project has a good
impl. Delete the native windows thread implementation and
rely on using pthreads everywhere.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
On Fedora 19 and older the pthreads impl provided with
mingw does not have any pthread_sigmask impl at all. The
configure.ac check was not distinguishing this scenario
from that of a broken pthread_sigmask impl, so was
mistakenly enabling the libvirt workaround even when it
was not needed. This in turn conflicted with the gnulib
provided pthread_sigmask impl.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Trying to run
$ ./configure --prefix=$HOME/usr/libvirt-git
$ make install
results in libvirt trying to install in /usr/lib/wireshark/plugins/....
with predictable amounts of fail. The configure script should not be
hardcoding /usr/lib by default but rather honour $libdir
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This is useful in certain circumstances, for example when
libvirtd is being executed by FreeBSD rc script, it cannot find
dmidecode installed from FreeBSD ports because it doesn't have
/usr/local (default prefix for ports) in PATH.
Introduce Wireshark dissector plugin which adds support to Wireshark
for dissecting libvirt RPC protocol.
Added following files to build Wireshark dissector from libvirt source
tree.
* tools/wireshark/*: Source tree of Wireshark dissector plugin.
Added followings to configure.ac or Makefile.am.
configure.ac
* --with-wireshark-dissector: Enable support for building Wireshark
dissector.
* --with-ws-plugindir: Specify wireshark plugin directory that dissector
will installed.
* Added tools/wireshark/{Makefile,src/Makefile} to AC_CONFIG_FILES.
Makefile.am
* Added tools/wireshark/ to SUBDIR.
On my Fedora 20 box with mingw cross-compiler, the build failed with:
../../src/rpc/virnetclient.c: In function 'virNetClientSetTLSSession':
../../src/rpc/virnetclient.c:745:14: error: unused variable 'oldmask' [-Werror=unused-variable]
sigset_t oldmask, blockedsigs;
^
I traced it to the fact that mingw64-winpthreads installs a header
that does #define pthread_sigmask(...) 0, which means any argument
only ever passed to pthread_sigmask is reported as unused. This
patch works around the compilation failure, with behavior no worse
than what mingw already gives us regarding the function being a
no-op.
* configure.ac (pthread_sigmask): Probe for broken mingw macro.
* src/util/virutil.h (pthread_sigmask): Rewrite to something that
avoids unused variables.
Signed-off-by: Eric Blake <eblake@redhat.com>
Make it easy to install the shipped examples. The aim is to have
reasonably working templates so that distros only need to minimally
patch these and can feed things upstream more easily.
This was prompted by http://bugs.debian.org/725144
This partially reverts 5eb4b04211 and 62774afb6b.
Rewrite the domsuspend example from scratch. This time do it right.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Old versions of CIL did not understand the 'bool' data type,
but at least 1.7.3 does now cope. We can remove the old hack
which redefined bool and no longer compiles successfully.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Our option '--with-test-suite' could have never worked since it was
defined as AC_ARG_ENABLE([with-test-suite], ...), thus working only as
'--enable-with-test-suite', but documented in configure.ac as
AC_HELP_STRING([--with-test-suite], ...).
In my opinion, the help string is as it should be, but the option is
wrong.
The option has been broken since the introduction in commit 3a2fc27.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
As the python generator scripts are written in python2,
the ./configure script must check for python2 before checking for python
otherwise, on platforms where both python2 and python3 are available and
on which the default python points to python3, ./configure will try to use
the wrong one.
Signed-off-by: Lénaïc Huard <lenaic@lhuard.fr.eu.org>
The domain events demo program isn't really tied to domain
events anymore, so rename it to object events.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This patch resolves a compile issue caused by the
removal of examples/domsuspend code in commit
5eb4b04211. This issue
is only seen in a fresh checkout, but causes the build
and configure to fail.
We support gluster volumes in domain XML, so we also ought to
support them as a storage pool. Besides, a future patch will
want to take advantage of libgfapi to handle the case of a
gluster device holding qcow2 rather than raw storage, and for
that to work, we need a storage backend that can read gluster
storage volume contents. This sets up the framework.
Note that the new pool is named 'gluster' to match a
<disk type='network'><source protocol='gluster'> image source
already supported in a <domain>; it does NOT match the
<pool type='netfs'><source><target type='glusterfs'>,
since that uses a FUSE mount to a local file name rather than
a network name.
This and subsequent patches have been tested against glusterfs
3.4.1 (available on Fedora 19); there are likely bugs in older
versions that may prevent decent use of gfapi, so this patch
enforces the minimum version tested. A future patch may lower
the minimum. On the other hand, I hit at least two bugs in
3.4.1 that will be fixed in 3.5/3.4.2, where it might be worth
raising the minimum: glfs_readdir is nicer to use than
glfs_readdir_r [1], and glfs_fini should only return failure on
an actual failure [2].
[1] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00085.html
[2] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00086.html
* configure.ac (WITH_STORAGE_GLUSTER): New conditional.
* m4/virt-gluster.m4: new file.
* libvirt.spec.in (BuildRequires): Support gluster in spec file.
* src/conf/storage_conf.h (VIR_STORAGE_POOL_GLUSTER): New pool
type.
* src/conf/storage_conf.c (poolTypeInfo): Treat similar to
sheepdog and rbd.
(virStoragePoolDefFormat): Don't output target for gluster.
* src/storage/storage_backend_gluster.h: New file.
* src/storage/storage_backend_gluster.c: Likewise.
* po/POTFILES.in: Add new file.
* src/storage/storage_backend.c (backends): Register new type.
* src/Makefile.am (STORAGE_DRIVER_GLUSTER_SOURCES): Build new files.
* src/storage/storage_backend.h (_virStorageBackend): Documet
assumption.
Signed-off-by: Eric Blake <eblake@redhat.com>
The python binding now lives in
http://libvirt.org/git/?p=libvirt-python.git
that repo also provides an RPM which is upgrade compatible
with the old libvirt-python sub-RPM.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The QEMU backend was disabled on Mac OS X without a reason in the code
and due to refactors its difficult to understand when/why it was
disabled. With QEMU being supported on Mac OS X there is no reason to
disable QEMU on this platform.
The libvirt.so library has far too many library deps to allow
linking against it from setuid programs. Those libraries can
do stuff in __attribute__((constructor) functions which is
not setuid safe.
The virt-login-shell needs to link directly against individual
files that it uses, with all library deps turned off except
for libxml2 and libselinux.
Create a libvirt-setuid-rpc-client.la library which is linked
to by virt-login-shell. A config-post.h file allows this library
to disable all external deps except libselinux and libxml2.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
A future patch will allow disabling readline; doing this in an
isolated file instead of configure.ac will make the task easier.
* configure.ac: Move readline code...
* m4/virt-readline.m4: ...here.
Signed-off-by: Eric Blake <eblake@redhat.com>
The automake manual recommends against the use of disabling
maintainer mode by default:
https://www.gnu.org/software/automake/manual/automake.html#maintainer_002dmode
because when it is disabled, the user gets no indication if they
touch a file that would normally require a rebuild. Automake
1.11 changed things so that AM_MAINTAINER_MODE([enable]) will set
the mode to enabled by default; but RHEL 5 still uses automake 1.9,
where AM_MAINTAINER_MODE did not recognize an argument, and
therefore disables maintainer mode by default. Having the default
be different according to which version of automake built the
project is annoying, and I _have_ been bitten on RHEL 5 rebuilds
where the default disabled mode led to silently incorrect builds.
The automake manual admits that being able to disable maintainer
mode still makes sense for projects that still store generated
files from the autotools in version control; but we have dropped
that for several years now. As such, it's finally time to just
ditch the whole idea of maintainer mode, and unconditionally
rebuild autotools files if a dependency changes, without offering
a configure option to disable that mode.
* configure.ac (AM_MAINTAINER_MODE): Drop.
Signed-off-by: Eric Blake <eblake@redhat.com>