build: avoid $(srcdir) in *_SOURCES

Trying to enable automake's subdir-objects option resulted in
the creation of literal directories such as src/$(srcdir)/remote/.
I traced this to the fact that we had used a literal $(srcdir)
in a location that later fed an automake *_SOURCES variable.
This has also been reported as an automake bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
but it's better to fix our code than to wait for an automake fix.

Some things to remember that affect VPATH builds, and where an
in-tree build is blissfully unaware of the issues: if a VPATH
build fails to find a file that was used as a prereq of any
other target, then the rule for that file will expand $@ to
prefer the current build dir (bad because a VPATH build on a
fresh checkout will then stick $@ in the current directory
instead of the desired srcdir); conversely, if a VPATH build
finds the file in srcdir but decides it needs to be rebuilt,
then the rule for that file will expand $@ to include the
directory where it was found out-of-date (bad for an explicit
listing of $(srcdir)/$@ because an incremental VPATH build will
then expand srcdir twice).  As we want these files to go into
srcdir unconditionally, we have to massage or avoid $@ for any
recipe that involves one of these files.

Therefore, this patch removes all uses of $(srcdir) from any
generated file name that later feeds a *_SOURCES variable, and
then rewrites all the recipes to generate those files to
hard-code their creation into srcdir without the use of $@.

* src/Makefile.am (REMOTE_DRIVER_GENERATED): Drop $(srcdir); VPATH
builds know how to find the files, and automake subdir-objects
fails with it in place.
(LXC_MONITOR_PROTOCOL_GENERATED, (LXC_MONITOR_GENERATED)
(ACCESS_DRIVER_GENERATED, LOCK_PROTOCOL_GENERATED): Likewise.
(*_client_bodies.h): Hard-code rules to write into srcdir, as
VPATH tries to build $@ locally if missing.
(util/virkeymaps.h): Likewise.
(lxc/lxc_monitor_dispatch.h): Likewise.
(access/viraccessapi*): Likewise.
(locking/lock_daemon_dispatch_stubs.h): Likewise.
* daemon/Makeflie.am (DAEMON_GENERATED, remote_dispatch.h):
Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>

fixup DAEMON_GENERATED
build: use library rather than cross-directory compilation

If we use subdir-objects with automake, any reference to a
cross-directory .c file will result in automake creating
rules that track dependency in the cross directory.  But this
presents a problem during 'make distclean' - if the cross
directory is cleaned up first, then the daemon directory will
be left with dangling references to .Po dependency files that
no longer exist.

Meanwhile, referring to the cross-directory .c file means
that we are compiling the file twice - once in src, and once
in daemon.  Better is to compile just once in src into a
convenience library, and then use that library from daemon.

The tests directory had a similar situation of a cross-directory
.c file; to solve that, we actually need a convenience library.

* daemon/Makefile.am (DAEMON_SOURCES): Drop .c files...
(libvirtd_LDADD): ...and instead use library.
(libvirtd_conf_la_SOURCES): Declare a new convenience library.
(libvirtd_LDFLAGS): Drop duplicate flag.
* tests/Makefile.am (libvirtdconftest_SOURCES): Drop .c file...
(libvirtdconftest_LDADD): ..and instead use library.

Signed-off-by: Eric Blake <eblake@redhat.com>
tests: check remaining .x files

We have been adding new .x files without keeping the list of
*-structs files up-to-date.  This adds the support for the
recent additions.

In the process of testing this, I also noticed that Fedora 19's
use of dwarves-1.10 (providing pdwtags version 1.9) was producing
a single line on stderr but still giving enough useful info on
stdout that we could check structs; the real goal of checking
stderr separately from stdout was to avoid the bug in dwarves-1.9
where stdout was empty (see bug http://bugzilla.redhat.com/772358).

* src/Makefile.am (struct_prefix, PROTOCOL_STRUCTS): Add missing
struct tests.
(PDWTAGS): Work with Fedora 19 pdwtags.
(lxc_monitor_protocol-struct, lock_protocol-struct): New rules.
* src/lxc_monitor_protocol-structs: New file.
* src/lock_protocol-structs): Likewise.
* cfg.mk (generated_files): Enlarge list.

Signed-off-by: Eric Blake <eblake@redhat.com>
build: use automake subdir-objects

Automake 2.0 will enable subdir-objects by default; in preparation
for that change, automake 1.14 outputs LOADS of warnings:

daemon/Makefile.am:38: warning: source file '../src/remote/remote_protocol.c' is in a subdirectory,
daemon/Makefile.am:38: but option 'subdir-objects' is disabled
automake-1.14: warning: possible forward-incompatibility.
automake-1.14: At least a source file is in a subdirectory, but the 'subdir-objects'
automake-1.14: automake option hasn't been enabled.  For now, the corresponding output
automake-1.14: object file(s) will be placed in the top-level directory.  However,
automake-1.14: this behaviour will change in future Automake versions: they will
automake-1.14: unconditionally cause object files to be placed in the same subdirectory
automake-1.14: of the corresponding sources.
automake-1.14: You are advised to start using 'subdir-objects' option throughout your
automake-1.14: project, to avoid future incompatibilities.
daemon/Makefile.am:38: warning: source file '../src/remote/lxc_protocol.c' is in a subdirectory,
daemon/Makefile.am:38: but option 'subdir-objects' is disabled
...

As automake 1.9 also supported this option, and the previous patches
fixed up the code base to work with it, it is safe to now turn it on
unconditionally.

* configure.ac (AM_INIT_AUTOMAKE): Enable subdir-objects.
* .gitignore: Ignore .dirstamp directories.
* src/Makefile.am (PDWTAGS, *-protocol-struct): Adjust to
new subdir-object location of .lo files.

Signed-off-by: Eric Blake <eblake@redhat.com>
qemu: endjob returns a bool

Osier Yang pointed out that ever since commit 31cb030, the
signature of qemuDomainObjEndJob was changed to return a bool.
While comparison against 0 or > 0 still gives the right results,
it looks fishy; we also had one place that was comparing < 0
which is effectively dead code.

* src/qemu/qemu_migration.c (qemuMigrationPrepareAny): Fix dead
code bug.
(qemuMigrationBegin): Use more canonical form of bool check.
* src/qemu/qemu_driver.c (qemuAutostartDomain)
(qemuDomainCreateXML, qemuDomainSuspend, qemuDomainResume)
(qemuDomainShutdownFlags, qemuDomainReboot, qemuDomainReset)
(qemuDomainDestroyFlags, qemuDomainSetMemoryFlags)
(qemuDomainSetMemoryStatsPeriod, qemuDomainInjectNMI)
(qemuDomainSendKey, qemuDomainGetInfo, qemuDomainScreenshot)
(qemuDomainSetVcpusFlags, qemuDomainGetVcpusFlags)
(qemuDomainRestoreFlags, qemuDomainGetXMLDesc)
(qemuDomainCreateWithFlags, qemuDomainAttachDeviceFlags)
(qemuDomainUpdateDeviceFlags, qemuDomainDetachDeviceFlags)
(qemuDomainBlockResize, qemuDomainBlockStats)
(qemuDomainBlockStatsFlags, qemuDomainMemoryStats)
(qemuDomainMemoryPeek, qemuDomainGetBlockInfo)
(qemuDomainAbortJob, qemuDomainMigrateSetMaxDowntime)
(qemuDomainMigrateGetCompressionCache)
(qemuDomainMigrateSetCompressionCache)
(qemuDomainMigrateSetMaxSpeed)
(qemuDomainSnapshotCreateActiveInternal)
(qemuDomainRevertToSnapshot, qemuDomainSnapshotDelete)
(qemuDomainQemuMonitorCommand, qemuDomainQemuAttach)
(qemuDomainBlockJobImpl, qemuDomainBlockCopy)
(qemuDomainBlockCommit, qemuDomainOpenGraphics)
(qemuDomainGetBlockIoTune, qemuDomainGetDiskErrors)
(qemuDomainPMSuspendForDuration, qemuDomainPMWakeup)
(qemuDomainQemuAgentCommand, qemuDomainFSTrim): Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
build: avoid obsolete AC_HELP_STRING

Autoconf states that AC_HELP_STRING is obsolete, and that new
programs should use AS_HELP_STRING.  We also had instances of
not properly quoting the macro usage, and not relying on autoconf's
word-wrapping abilities to avoid long lines.  I validated that this
commit has no impact to the generated configure file.

* configure.ac (AC_ARG_WITH, AC_ARG_ENABLE): Autoconf recommends
the use of AS_HELP_STRING.  Also, use proper quoting and wrap long
lines.
* m4/virt-apparmor.m4 (LIBVIRT_CHECK_APPARMOR): Likewise.
* m4/virt-selinux.m4 (LIBVIRT_CHECK_SELINUX): Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
build: fix regression in requiring yajl for new enough qemu

Jonathan Lebon reported an issue to me off-list about his build
failing to use qemu because he failed to install yajl-devel.  But
I recalled specifically tweaking configure.ac to die in that
situation (commits 350583c, ba9c38b).  After a bit more
head-scratching, we found the cause of the regression: commit
654c709 rearranged things so that the qemu version check now
occurs before AC_ARG_WITH has had a chance to set either
$with_qemu or $with_yajl.

Coincidentally, this fix aligns with a documentation patch that
was just posted to the autoconf mailing list :)
http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/8324

* m4/virt-lib.m4 (LIBVIRT_CHECK_LIB, LIBVIRT_CHECK_LIB_ALT)
(LIBVIRT_CHECK_PKG): Populate defaults earlier.
* configure.ac (AC_ARG_WITH): Likewise for drivers.

Signed-off-by: Eric Blake <eblake@redhat.com>
docs, comments: minor typo fixes

Signed-off-by: Oskari Saarenmaa <os@ohmu.fi>
Signed-off-by: Eric Blake <eblake@redhat.com>
virDomainDefParseXML: set the argument of virBitmapFree to NULL after calling virBitmapFree

After freeing the bitmap pointer, it must set the pointer to NULL.
This will avoid any other use of the freed memory of the bitmap pointer.

https://bugzilla.redhat.com/show_bug.cgi?id=1006710

Signed-off-by: Liuji (Jeremy) <jeremy.liu@huawei.com>
Fix cgroups when all are mounted on /sys/fs/cgroup

Some users in Ubuntu/Debian seem to have a setup where all the
cgroup controllers are mounted on /sys/fs/cgroup rather than
any /sys/fs/cgroup/<controller> name. In the loop which detects
which controllers are present for a mount point we were modifying
'mnt_dir' field in the 'struct mntent' var, but not always restoring
the original value. This caused detection to break in the all-in-one
mount setup.

Fix that logic bug and add test case coverage for this mount
setup.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Update docs about user namespace for LXC

Mention that user namespace can be enabled using the UID/GID
mapping schema.

Fix typo in link anchor for container args in domain XML docs.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add test for the nodemask double free crash

Commit ef5d51d fixed a crash for numatune with auto placement and
nodeset specified:
<numatune>
    <memory mode='preferred' placement='auto' nodeset='0'/>
</numatune>
LXC: umount the temporary filesystem created by libvirt

The devpts, dev and fuse filesystems are mounted temporarily.
there is no need to export them to container if container shares
the root directory with host.

Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
LXC: introduce lxcContainerUnmountForSharedRoot

Move the unmounting private or useless filesystems for
container to this function.

Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
DBus: introduce virDBusIsServiceEnabled

This patch introduces virDBusIsServiceEnabled, we can use
this method to get if the service is supported.

In one case, if org.freedesktop.machine1 is unavailable on
host, we should skip creating machine through systemd.

Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Fix virsystemdtest for previous commit

The change to query org.freedesktop.DBus.ListActivatableNames
to detect systemd broke the test suite, since we did not have
stubs to respond to this dbus call.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
build: require libnl-3 if netcf uses it

Commits 9298bfb and f6c2951 both tried to make it possible to
select the correct libnl (1 vs. 3) according to what netcf
used, when both libraries are installed.  This works to avoid
libnl-3 when netcf used libnl-1.  But on the converse side, if
only libnl-1 development code is installed, while netcf uses
libnl-3, then configure happily uses libnl-1 anyways, leading
to a test failure:

$ VIR_TEST_DEBUG=1 ./virdrivermoduletest
TEST: virdrivermoduletest
 1) Test driver "network"                                             ... OK
 2) Test driver "storage"                                             ... OK
 3) Test driver "nodedev"                                             ... OK
 4) Test driver "secret"                                              ... OK
 5) Test driver "nwfilter"                                            ... OK
 6) Test driver "interface"
... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion
`0' failed.
Aborted

It's much nicer to prevent this at configure time, by requiring that
if we know what netcf used, then we want the same libnl version.  As
before, this can be bypassed by someone who knows what they are doing
by setting LIBNL_CFLAGS (perhaps useful to the rare person where the
build box has a different version of netcf than the installation box).

* configure.ac (LIBNL): If we can prove netcf used libnl-3, then
don't let configure succeed with libnl-1.

Signed-off-by: Eric Blake <eblake@redhat.com>
api-docs: Fix description of virConnectGetType() API function

This fixes the description of virConnectGetType() API function in
API documentation to match the real functionality that it can be
used to get driver name, and provide a hint on how to learn about
full capabilities.

Signed-off-by: Michal Novotny <minovotn@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Repair the search on libvirt.org

First make sure that the input is xhtml as the stylesheets expect
namespaced element, then use a span element instead of a as a
is treated specially, finally adjust the makefile to check for
the new span element and replace it with the PHP code
virsh domjobinfo: Do not return 1 if job is NONE

https://bugzilla.redhat.com/show_bug.cgi?id=1006864

Commit 38ab1225 changed the default value of ret from true to false but
forgot to set ret = true when job is NONE. Thus, virsh domjobinfo
returned 1 when there was no job running for a domain but it used to
(and should) return 0 in this case.