test_libvirt_lockd.aug is only generated when qemu driver is enabled.

* docs/news.html.in libvirt.spec.in: updates for release
* po/*.po*: fetched new localization and regenerated

This commit adds a new example to illustrate peer to
peer domain migration with virDomainMigrateToURI.
Signed-off-by: NSahid Orentino Ferdjaoui <sahid.ferdjaoui@cloudwatt.com>

Having two tiny files with a couple definitions didn't make
as much sense as one common file, especially since I plan to
add more definitions and use it in more places.

* docs/schemas/storageencryption.rng: Merge this...
* docs/schemas/storagefilefeatures.rng: ...and this, into...
* docs/schemas/storagecommon.rng: ...this new file.
* docs/schemas/Makefile.am (schema_DATA): Reflect renames.
* docs/schemas/storagevol.rng: Likewise.
* docs/schemas/domaincommon.rng: Likewise.
* libvirt.spec.in: Likewise.
* mingw-libvirt.spec.in: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

This uses the dbus api of systemd to check the power management
capabilities of the node.

* docs/news.html.in libvirt.spec.in: update for the release
* po/*.po*: pull updated translations and regenerate

This commit moves a few directories into more appropriate subpackages.
In a few cases a directory is owned by two subpackages, however this is
OK as long as the permissions and ownership for the directory are
consistent between them.

- %{_sysconfdir}/libvirt/qemu/

  Used by the qemu and network drivers.

  When building with separate driver modules, this directory is only
  owned by l-d-d-network. l-d-d-qemu has a hard dependency on
  l-d-d-network, which means this directory is created with the
  correct permissions and ownership, however it's clearer if both
  subpackages own the directory independently.

- %{_sysconfdir}/libvirt/nwfilter/

  Used by the nwfilter driver only.

  This directory is currently always owned by libvirt-daemon. This
  commit moves it into l-d-d-nwfilter when building with separate
  driver modules.

- %{_localstatedir}/run/libvirt/network/

  Used by the network and nwfilter drivers.

  When building without separate driver modules, this directory is
  should be owned by libvirt-daemon only if either of these drivers
  are enabled. When building with separate driver modules, this
  directory should be owned by l-d-d-nwfilter in addition to
  l-d-d-network.

- %{_datadir}/libvirt/networks/ and
  %{_datadir}/libvirt/networks/default.xml

  Used only by the %post scriptlet in libvirt-daemon-config-network.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

Libvirt tarball contains po/stamp-po file which prevents any po/*.gmo
file to be regenerated even if a corresponding po/*.po file is newer. By
removing the stamp-po file, all *.gmo files are properly updated if
required. This allows downstreams to provide patches that update
translations.

- docs/news.html.in libvirt.spec.in: update for the release
* po/*.po*: update localization and merge

In commit 72f7658b I've added a few
macros with bad bracing. Although they work as expected fix them so that
we use uniform syntax.

On Fedora 20, I added this to my '~/.rpmmacros':

%_without_udev 1
%_without_storage_mpath 1
%_without_storage_disk 1

and uninstalled systemd-devel (which also removed device-mapper-devel).
Then I ran 'make rpm', and inspected the results:

$ ldd ~/rpmbuild/BUILD/libvirt-1.2.2/daemon/.libs/libvirtd | grep syst
$

Then I reinstalled systemd-devel, where I now see:

$ ldd ~/rpmbuild/BUILD/libvirt-1.2.2/daemon/.libs/libvirtd | grep syst
  libsystemd-daemon.so.0 => /lib64/libsystemd-daemon.so.0 (0x00007ffb858ba000)
$

Oops - the build is non-deterministic, where the final binary
depends on my build environment.  The fix is to require
systemd-devel in all situations where the code base uses it.
Now ~/.rpmmacros can contain "%define _without_systemd_daemon 1"
to explicitly disable use of the library, but the library is now
a strict build requirement for normal builds; if systemd-devel
is not installed, the user now gets an up-front warning:

$ rpmbuild -ta libvirt-1.2.2.tar.gz
error: Failed build dependencies:
       systemd-devel is needed by libvirt-1.2.2-1.fc20.x86_64

* libvirt.spec.in (with_systemd_daemon): New variable.
(BuildRequires): Require systemd-devel for more than just udev.
(%configure): Make choice of systemd_daemon explicit.
Signed-off-by: NEric Blake <eblake@redhat.com>

On Fedora 20, with the following in my ~/.rpmmacros:

%_without_udev 1
%_without_storage_mpath 1

and with device-mapper-devel uninstalled, 'make rpm' fails with:

checking for libdevmapper.h... no
configure: error: You must install device-mapper-devel/libdevmapper >= 1.0.0 to compile libvirt
error: Bad exit status from /var/tmp/rpm-tmp.Wo9pOG (%build)

This is a rather late point to be issuing an error; better is
to flag missing packages up front.  The fix is to match the logic
in configure.ac on when devmapper is required (for both mpath and
storage).  While at it, rbd storage is not dependent on mpath.
With this patch applied, I now get:

$ rpmbuild -ta libvirt-1.2.2.tar.gz
error: Failed build dependencies:
       device-mapper-devel is needed by libvirt-1.2.2-1.fc20.x86_64

until either installing the package or further modifying
~/.rpmmacros to add "%_without_storage_disk 1".

* libvirt.spec.in (BuildRequires): Fix build when mpath is
disabled.
Signed-off-by: NEric Blake <eblake@redhat.com>

Generally, we try to make the spec file tweakable via user
variables, so that they can select a different subset of sub-rpms
to build.  We also try to explicitly list all driver config
options, rather than leaving the chance that the rpm build may be
non-deterministic based on what the user had installed locally.
But in the case of the recent bhyve hypervisor driver, there is
no port of bhyve to Linux, so it is easier to just blindly
disable it for now.  If someone ever does try to port bhyve to
Fedora, we can make the spec file conditional at that point.

* libvirt.spec.in (%configure): Don't try to build bhyve.
Signed-off-by: NEric Blake <eblake@redhat.com>

RHEL still uses the 3.4.0 package of libgfapi and the package is built
only for x86_64.

Similar to cf76c4b3, if modules are used, then nwfilter configuration
requires the nwfilter driver module.
Signed-off-by: NEric Blake <eblake@redhat.com>

This reverts commit 8d6c3659.

After further list discussion, it was decided that pulling in
wireshark as a dependency is a bit too much for the base 'libvirt'
package.  Remember also that 'libvirt-devel' is also not pulled in
by the base 'libvirt' - the metapackage exists for full
functionality of libvirtd, rather than to pull in all subpackages.

In general, the 'libvirt' metapackage should pull in all subpackages.
Fix this for the wireshark subpackage created in commit f9ada9f3.

* libvirt.spec.in (Requires): Add dependency.
Signed-off-by: NEric Blake <eblake@redhat.com>

When building modules, libvirt-daemon-config-network requires
libvirt-daemon-driver-network to ensure the 'default' network
is setup properly
Signed-off-by: NEric Blake <eblake@redhat.com>

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

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: NEric Blake <eblake@redhat.com>

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*.po*: updated localization from transifex and regenerated

This partially reverts 5eb4b042 and 62774afb.

Rewrite the domsuspend example from scratch. This time do it right.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit ff76566e moved around things in the specfiles to put
driver-specific files into their appropriate sub-packages (when
with_driver_modules == 1), but accidentally changed things so that the
deamon-driver-network and daemon-config-network files were only
included in a package when with_driver_modules == 0. This broke "make
rpm" on fedora (where with_driver_modules == 1).

This patch follows the pattern (already used for the files in other
sub-modules) of duplicating the files for the main package
(!with_driver_modules) and the sub-package (with_driver_modules).

The domain events demo program isn't really tied to domain
events anymore, so rename it to object events.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NLaine Stump <laine@laine.org>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

- systemctl and the %systemd_* RPM macros can take multiple unit names
  in the one invocation. Make use of this to avoid repeated systemd
  daemon reloads.

- virtlockd was only properly enabled and disabled when using systemd,
  but when systemd RPM macros were not available (e.g. on Fedora < 18).
  Make sure it's enabled when systemd RPM macros are present, or when
  using initscripts.

- Always use "reload" on virtlockd, not "condrestart". This allows it to
  cleanly re-execute itself without losing running state. Ignore any
  error should the reload fail.

- Move the reloading of virtlockd and libvirtd via their initscripts
  into the daemon package's %postun scriptlet. These services must be
  restarted after all of the libvirt-daemon-driver-* packages have
  been upgraded during the same RPM transaction.

- Add a %triggerpostun executed only when upgrading an older
  libvirt-daemon. As an older package would only reload libvirtd during
  %post, and the newer package would only reload libvirtd during
  %postun, such an upgrade would not reload libvirtd at all without the
  trigger.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

The libvirt-daemon package contains several driver-specific files,
directories, and script, which can be problematic when building the
package with multiple hypervisor support, e.g. both QEMU and Xen.

E.g. installing a QEMU+Xen enabled libvirt-daemon on a Xen-only system
will result in the creation of qemu and kvm groups and a qemu user.

Move the driver-specific files, directories, and script to the
respective driver subpackages.

Collapse the various {with_<hypervisor>} conditionals in the
libvirt-daemon package files section into a single {with_<hypervisor>}
conditional

Move some hypervisor-specific files in the libvirt-daemon subpackage
within conditionals for those hypervisors.

The daemon-config-{network,nwfilter} subpackages are built regardless
of whether or not with_driver_modules is defined, therefore don't
conditionally define their files list.

The %pre script in libvirt-daemon is specific to qemu, so only include
it if building with qemu support.

Ensure nwfilter files lists and dependencies are conditional upon
with_nwfilter being defined.

The domsuspend example code is a really old and bad exmample of (how not
to use) the libvirt API. Remove it as it's apparent that nobody tried to
use it. It was broken and nobody complained.

* configure.ac docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: update and merge localizations from transifex

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: NEric 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: NDaniel P. Berrange <berrange@redhat.com>

The previous attempt (commit d65e0e14) removed just one of two
libvirt-guests restarts that happened on libvirt-client update. Let's
remove the last one too :-)

https://bugzilla.redhat.com/show_bug.cgi?id=962225Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Restarting an active libvirt-guests.service is the equivalent of
doing:

/usr/libexec/libvirt-guests.sh stop
/usr/libexec/libvirt-guests.sh start

Which in a default configuration will managedsave every running VM,
and then restore them. Certainly not something we should do every
time the libvirt-client RPM is updated.

Just drop the try-restart attempt, I don't know what purpose it
serves anyways.

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