The current sanlock plugin requires a central management
application to manually add <lease> elements to each guest,
to protect resources that are assigned to it (eg writable
disks). This makes the sanlock plugin useless for usage
in more ad hoc deployment environments where there is no
central authority to associate disks with leases.

This patch adds a mode where the sanlock plugin will
automatically create leases for each assigned read-write
disk, using a md5 checksum of the fully qualified disk
path. This can work pretty well if guests are using
stable disk paths for block devices eg /dev/disk/by-path/XXXX
symlinks, or if all hosts have NFS volumes mounted in
a consistent pattern.

The plugin will create one lockspace for managing disks
with filename /var/lib/libvirt/sanlock/__LIBVIRT__DISKS__.
For each VM disks, there will be another file to hold
a lease /var/lib/libvirt/sanlock/5903e5d25e087e60a20fe4566fab41fd
Each VM disk lease is usually 1 MB in size. The script
virt-sanlock-cleanup should be run periodically to remove
unused lease files from the lockspace directory.

To make use of this capability the admin will need to do
several tasks:

 - Mount an NFS volume (or other shared filesystem)
   on /var/lib/libvirt/sanlock
 - Configure 'host_id' in /etc/libvirt/qemu-sanlock.conf
   with a unique value for each host with the same NFS
   mount
 - Toggle the 'auto_disk_leases' parameter in qemu-sanlock.conf

Technically the first step can be skipped, in which case
sanlock will only protect against 2 vms on the same host
using the same disk (or the same VM being started twice
due to error by libvirt).

* src/locking/libvirt_sanlock.aug,
  src/locking/sanlock.conf,
  src/locking/test_libvirt_sanlock.aug: Add config params
  for configuring auto lease setup
* libvirt.spec.in: Add virt-sanlock-cleanup program, man
  page
* tools/virt-sanlock-cleanup.in: Script to purge unused
  disk resource lease files

Introduce a configuration file with a single parameter
'require_lease_for_disks', which is used to decide whether
it is allowed to start a guest which has read/write disks,
but without any leases.

* libvirt.spec.in: Add sanlock config file and augeas
  lens
* src/Makefile.am: Install sanlock config file and
  augeas lens
* src/locking/libvirt_sanlock.aug: Augeas master lens
* src/locking/test_libvirt_sanlock.aug: Augeas test file
* src/locking/sanlock.conf: Example sanlock config
* src/locking/lock_driver_sanlock.c: Wire up loading
  of configuration file

Parthelper is only compiled if both --with-libvirtd
and --with-storage-disk are set.
Signed-off-by: NRuben Kerkhof <ruben@rubenkerkhof.com>

When building rpms for newer Fedora or RHEL, take advantage of the
newer netcf packaging to guarantee interface snapshot support.

* libvirt.spec.in (BuildRequires): Bump minimum version on
platforms that support netcf 0.1.8.

The XenAPI driver works like the ESX and PHyp driver by using its
own HTTPS based remote protocol.

The VMware driver works like the OpenVZ driver by using a commandline
tool for management. It dosen't use it's own remote protocol.

* configure.ac docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: updated translations and regenerated

Sanlock is a project that implements a disk-paxos locking
algorithm. This is suitable for cluster deployments with
shared storage.

* src/Makefile.am: Add dlopen plugin for sanlock
* src/locking/lock_driver_sanlock.c: Sanlock driver
* configure.ac: Check for sanlock
* libvirt.spec.in: Add a libvirt-lock-sanlock RPM

This allows qemu to create files in /var/cache/libvirt/qemu/, and
specifically is required to fix virDomainMemoryPeek.

* configure.ac libvirt.spec.in docs/news.html.in: update and document
  the release
* po/*.po*: update localizations for german, polish, spanish, ukrainian
  and vietnamese coming from transifex, regenerate

To install it, disable libvirtd sysv initscript:
    chkconfig libvirtd off
    service libvirtd stop

and enable libvirtd upstart job:
    cp  /usr/share/doc/libvirt-*/libvirtd.upstart \
        /etc/init/libvirtd.conf
    initctl reload-configuration
    initctl start libvirtd

Test:
    initctl status libvirtd
libvirtd start/running, process 3929
    killall -9 libvirtd
    initctl status libvirtd
libvirtd start/running, process 4047

I looked into the possibility to use the upstart script from Ubuntu or
at least getting inspiration from it but that's not possible. "expect
daemon" is a nice thing but it only works if the process is defined with
exec stanza instead of script ... no script. Unfortunately, with exec
stanza environment variables can only be set within upstart script
(i.e., configuration in /etc/sysconfig/libvirtd can't work). Hence, we
need to use script stanza, source sysconfig, and execute libvirtd
without --daemon. For similar reasons we can't use limit stanza and need
to handle DAEMON_COREFILE_LIMIT in job's script.

The systemtap directory for tapsets is called

  /usr/share/systemtap/tapset

Not

 /usr/share/systemtap/tapsets

* daemon/Makefile.am,libvirt.spec.in: s/tapsets/tapset/

* configure.ac docs/news.html.in libvirt.spec.in: update for the release
* po/*.po*: update polish translation and regenerate

The new iohelper binary was missing from the packaging spec

The Open Nebula driver has been unmaintained since it was first
introduced. The only commits have been for tree-wide cleanups.
It also has a major design flaw, in that it only knows about guests
that it has created itself, which makes it of very limited use.

Discussions wrt evolution of the VMWare ESX driver, concluded that
it should limit itself to single-node ESX operation and not try to
manage the multi-node architecture of VirtualCenter. Open Nebula
is a cluster like Virtual Center, not a single node system, so
the same reasoning applies.

The DeltaCloud project includes an Open Nebula driver and is a much
better fit architecturally, since it is explicitly targetting the
distributed multihost cluster scenario.

Thus this patch deletes the libvirt Open Nebula driver with the
recommendation that people use DeltaCloud for managing it instead.

* configure.ac: Remove probe for xmlrpc & --with-one arg
* daemon/Makefile.am, daemon/libvirtd.c, src/Makefile.am: Remove
  ONE driver build
* src/opennebula/one_client.c, src/opennebula/one_client.h,
  src/opennebula/one_conf.c, src/opennebula/one_conf.h,
  src/opennebula/one_driver.c, src/opennebula/one_driver.c: Delete
  files
* autobuild.sh, libvirt.spec.in, mingw32-libvirt.spec.in: Remove
  build rules for Open Nebula
* docs/drivers.html.in, docs/sitemap.html.in: Remove reference
  to OpenNebula
* docs/drvone.html.in: Delete file

Among others, the missing radvd dependency showed up as:

error: Failed to start network ipv6net
error: Cannot find radvd - Possibly the package isn't installed: No such file
or directory

even when radvd was installed, because the RADVD preprocessor
symbol was missing at configure time.

* libvirt.spec.in (with_network): Add BuildRequires for radvd,
iptables, and ip6tables.
(BuildRequires): Add libxslt and augeas for docs and test.
(with_libvirtd): Add module-init-tools for modprobe.
(with_nwfilter): Add BuildRequires for ebtables.
(with_esx): Fix esx build on RHEL 5, thanks to curl-devel rename.

* libvirt.spec.in (Requires): Reorganize requirements a bit; no
functional change.

The xen RPM in Fedora isn't new enough to support libxl builds
yet. Disable it until Fedora 16

* libvirt.spec.in: Disable libxl on Fedora < 16

Add a new xen driver based on libxenlight [1], which is the primary
toolstack starting with Xen 4.1.0.  The driver is stateful and runs
privileged only.

Like the existing xen-unified driver, the libxenlight driver is
accessed with xen:// URI.  Driver selection is based on the status
of xend.  If xend is running, the libxenlight driver will not load
and xen:// connections are handled by xen-unified.  If xend is not
running *and* the libxenlight driver is available, xen://
connections are deferred to the libxenlight driver.

V6:
 - Address several code style issues noted by Daniel Veillard
 - Make drive work with xen:/// URI
 - Hold domain object reference while domain is injected in
   libvirt event loop.  Race found and fixed by Markus Groß.

V5:
 - Ensure events are unregistered when domain private data
   is destroyed.  Discovered and fixed by Markus Groß.

V4:
 - Handle restart of libvirtd, reconnecting to previously
   started domains
 - Rebased to current master
 - Tested against Xen 4.1 RC7-pre (c/s 22961:c5d121fd35c0)

V3:
  - Reserve vnc port within driver when autoport=yes

V2:
  - Update to Xen 4.1 RC6-pre (c/s 22940:5a4710640f81)
  - Rebased to current master
  - Plug memory leaks found by Stefano Stabellini and valgrind
  - Handle SHUTDOWN_crash domain death event

[1] http://lists.xensource.com/archives/html/xen-devel/2009-11/msg00436.html

When building for an older distro, it's convenient to just
tell rpmbuild to define dist (for example, to .el6_0), rather
than also remembering to define rhel to 6.

* libvirt.spec.in: Guess %{rhel} based on %{dist}.
Based on an idea by Jiri Denemark.

As the file may grow quite a bit especially with debug turned on.
* daemon/libvirtd.logrotate.in daemon/Makefile.am libvirt.spec.in:
  add new logrotate file for the daemon log

* libvirt.spec.in (Requires): Add gnutls-utils, for virt-pki-validate.
Suggested by Daniel P. Berrange.

libvirt-guests invokes functions in gettext.sh, so we need to
require gettext package in spec file.

Demo with the fix:
% rpm -q gettext
package gettext is not installed

% rpm -ivh libvirt-client-0.8.8-1.fc14.x86_64.rpm
error: Failed dependencies:
	gettext is needed by libvirt-client-0.8.8-1.fc14.x86_64

* libvirt.spec.in

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463

The problem was that, since a bridge always acquires the MAC address
of the connected interface with the numerically lowest MAC, as guests
are started and stopped, it was possible for the MAC address to change
over time, and this change in the network was being detected by
Windows 7 (it sees the MAC of the default route change), so on each
reboot it would bring up a dialog box asking about this "new network".

The solution is to create a dummy tap interface with a MAC guaranteed
to be lower than any guest interface's MAC, and attach that tap to the
bridge as soon as it's created. Since all guest MAC addresses start
with 0xFE, we can just generate a MAC with the standard "0x52, 0x54,
0" prefix, and it's guaranteed to always win (physical interfaces are
never connected to these bridges, so we don't need to worry about
competing numerically with them).

Note that the dummy tap is never set to IFF_UP state - that's not
necessary in order for the bridge to take its MAC, and not setting it
to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed
in the output of the ifconfig command.

I chose to not auto-generate the MAC address in the network XML
parser, as there are likely to be consumers of that API that don't
need or want to have a MAC address associated with the
bridge.

Instead, in bridge_driver.c when the network is being defined, if
there is no MAC, one is generated. To account for virtual network
configs that already exist when upgrading from an older version of
libvirt, I've added a %post script to the specfile that searches for
all network definitions in both the config directory
(/etc/libvirt/qemu/networks) and the state directory
(/var/lib/libvirt/network) that are missing a mac address, generates a
random address, and adds it to the config (and a matching address to
the state file, if there is one).

docs/formatnetwork.html.in: document <mac address.../>
docs/schemas/network.rng: add nac address to schema
libvirt.spec.in: %post script to update existing networks
src/conf/network_conf.[ch]: parse and format <mac address.../>
src/libvirt_private.syms: export a couple private symbols we need
src/network/bridge_driver.c:
    auto-generate mac address when needed,
    create dummy interface if mac address is present.
tests/networkxml2xmlin/isolated-network.xml
tests/networkxml2xmlin/routed-network.xml
tests/networkxml2xmlout/isolated-network.xml
tests/networkxml2xmlout/routed-network.xml: add mac address to some tests

The name convention of device mapper disk is different, and 'parted'
can't be used to delete a device mapper disk partition. e.g.

Name                 Path
-----------------------------------------
3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1

Error: Expecting a partition number.

This patch introduces 'dmsetup' to fix it.

Changes:
  - New function "virIsDevMapperDevice" in "src/utils/utils.c"
  - remove "is_dm_device" in "src/storage/parthelper.c", use
    "virIsDevMapperDevice" instead.
  - Requires "device-mapper" for 'with-storage-disk" in "libvirt.spec.in"
  - Check "dmsetup" in 'configure.ac' for "with-storage-disk"
  - Changes on "src/Makefile.am" to link against libdevmapper
  - New entry for "virIsDevMapperDevice" in "src/libvirt_private.syms"

Changes from v1 to v3:
  - s/virIsDeviceMapperDevice/virIsDevMapperDevice/g
  - replace "virRun" with "virCommand"
  - sort the list of util functions in "libvirt_private.syms"
  - ATTRIBUTE_NONNULL(1) for virIsDevMapperDevice declaration.

e.g.

Name                 Path
-----------------------------------------
3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1

Vol /dev/mapper/3600a0b80005ad1d7000093604cae912fp1 deleted

Name                 Path
-----------------------------------------

* configure.ac docs/news.html.in libvirt.spec.in: bump version and add docs
* po/*.po*: updated Gujarati, Polish and Dutch localisations and regenerated

The logging functions are enhanced so that immediately prior to
the first log message being printed to any output channel, the
libvirt package version will be printed.

eg

 $ LIBVIRT_DEBUG=1 virsh
 18:13:28.013: 17536: info : libvirt version: 0.8.7
 18:13:28.013: 17536: debug : virInitialize:361 : register drivers
 ...

The 'configure' script gains two new arguments which can be
used as

   --with-packager="Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10"
   --with-packager-version="1.fc14"

to allow distros to append a custom string with package specific
data.

The RPM specfile is modified so that it appends the RPM version,
the build host, the build date and the packager name.

eg

 $ LIBVIRT_DEBUG=1 virsh
 18:14:52.086: 17551: info : libvirt version: 0.8.7, package: 1.fc13 (Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10)
 18:14:52.086: 17551: debug : virInitialize:361 : register drivers

Thus when distro packagers receive bug reports they can clearly
see what version was in use, even if the bug reporter mistakenly
or intentionally lies about version/builds

* src/util/logging.c: Output version data prior to first log message
* libvirt.spec.in: Include RPM release, date, hostname & packager
* configure.ac: Add --with-packager & --with-packager-version args

* configure.ac libvirt.spec.in docs/news.html.in: bump version and add
  documentation
* po/*po*: regenerate po and pot files

When I build libvirt without libvirtd, I receive some errors:
cp: cannot stat `/home/wency/rpmbuild/BUILDROOT/libvirt-0.8.6-1.el6.x86_64/etc/libvirt/qemu/networks/default.xml': No such file or directory

My build step:
# ./autogen.sh --without-libvirtd
# make dist
# rpmbuild --nodeps --define "_sourcedir `pwd`" --define "_without_libvirtd 1" -ba libvirt.spec

The reason is we disable network when we do not build libvirt daemon in configure.ac.
After fixing this bug, I build libvirt without libvirtd, I receive other errors:
RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/share/doc/libvirt-0.8.6/html/32favicon.png
   /usr/share/doc/libvirt-0.8.6/html/api.html
..
Signed-off-by: NWen Congyang <wency@cn.fujitsu.com>

A number of the libvirt APIs require the use of cgroups. This is not
enabled by default on a RHEL6 install. After discussion with cgroups
team, it was decided that upon installation of the libvirt RPM, we
should automatically turn on the cgroups service. This will activate a
default configuration that turns on all cgroups controllers libvirt
requires for full operation.

* libvirt.spec.in: Provide vmware conditionals.

starting a service during rpm installation is impolite. It is even worse if done
during upgrade, for a service that was explicitly turned off.

- configure.ac libvirt.spec.in: bump version, add a missing systemtap
  build requirement
- docs/news.html.in: add informations about the release
- po/*: updated Polish and Dutch localizations, and regenerated
- tests/qemuxml2argvtest.c: Fix build problem

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

Regression of forcing 0700 permissions (which breaks guest startup
because the qemu user can't see /var/lib/libvirt/*.monitor) was
introduced in commit 66823690, as part of libvirt 0.8.2.

* libvirt.spec.in (%files): Drop %{_localstatedir}/lib/libvirt,
since libvirt depends on libvirt-client.
(%files client): Guarantee 755 permissions on
%(_localstatedir}/lib/libvirt, since the qemu user must be able to
do pathname resolution to a subdirectory.

Suggested by danpb, as it's not up-to-date anymore and
lacks many functions that were added to libvirtd.

* configure.ac libvirt.spec.in: new version
* docs/news.html.in: update news page and improve format
* po/*.po*: Update po again

Adds initial support for dtrace static probes in libvirtd
daemon, assuming use of systemtap dtrace compat shim on
Linux. The probes are inserted for network client connect,
disconnect, TLS handshake states and authentication protocol
states.

This can be tested by running the xample program and then
attempting to connect with any libvirt client (virsh,
virt-manager, etc).

 # stap examples/systemtap/client.stp
  Client fd=44 connected readonly=0
  Client fd=44 auth polkit deny pid:24997,uid:500
  Client fd=44 disconnected
  Client fd=46 connected readonly=1
  Client fd=46 auth sasl allow test
  Client fd=46 disconnected

The libvirtd.stp file should also really not be required,
since it is duplicated info that is already available in
the main probes.d definition file. A script to autogenerate
the .stp file is needed, either in libvirtd tree, or better
as part of systemtap itself.

* Makefile.am: Add examples/systemtap subdir
* autobuild.sh: Disable dtrace for mingw32
* configure.ac: Add check for dtrace
* daemon/.gitignore: Ignore generated dtrace probe file
* daemon/Makefile.am: Build dtrace probe header & object
  files
* daemon/libvirtd.stp: SystemTAP convenience probeset
* daemon/libvirtd.c: Add connect/disconnect & TLS probes
* daemon/remote.c: Add SASL and PolicyKit auth probes
* daemon/probes.d: Master probe definition
* daemon/libvirtd.h: Add convenience macro for probes
  so that compilation is a no-op when dtrace is not available
* examples/systemtap/Makefile.am, examples/systemtap/client.stp
  Example systemtap script using dtrace probe markers
* libvirt.spec.in: Enable dtrace on F13/RHEL6
* mingw32-libvirt.spec.in: Force disable dtrace