When images are on mounted filesystems, there is no guarantee libvirtd
will start before they are mounted.  Since we want to start after both
local and remote filesystems are mounted, we need to add both local-fs
and remote-fs as targets that should precede starting libvirtd service.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

If apparmor security driver is enabled in either qemu or lxc
driver configuration and libvirtd starts before AppArmor, it will fail.

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: NMichal Privoznik <mprivozn@redhat.com>

We point to the manpages where available and redirect to libvirt's
homepage as a last resort.

This will create a respawn behaviour in case libvirt
process exits due to nonzero exit code, is terminated
by a signal, an operation times out or the configured
watchdog timeout is triggered.
see http://www.freedesktop.org/software/systemd/man/systemd.service.html
and https://bugzilla.redhat.com/show_bug.cgi?id=981974Signed-off-by: NEric Blake <eblake@redhat.com>

There's a quite old bug entry here:

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

I just stumbled over that very issue on F18. Doing a little bit
debugging of the shutdown sequence, it turns out that - at least on my
F18 installation - libvirtd is shutdown *after* iscsid, which makes it
impossible for libvirt to perform the logout of the iscsi session properly.

This patch simply adds another startup dependancy on iscsid.service
which in turn delays iscsid shutdown until after libvirtd has stopped.
Having that applied, the system shuts down properly again.
Signed-off-by: NEric Blake <eblake@redhat.com>

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

The initscript and upstart services depend on dbus starting
before libvirtd.  When we first wrote the systemd script, we
tried to do the same, but we depended on dbus.target (which
does not exist) in comparison to network.target (which does
exist), so we removed that in commit 4c7973e1.  But we still
need dbus up and running first, especially now that we want
to support shutdown inhibition via dbus (whereas we originally
needed dbus only for firewall control).

http://www.freedesktop.org/software/systemd/man/systemd.target.html
explains how a target (such as network.target) is just a collection
of common services bundled together, and why we want network.target
but dbus.service.

* daemon/libvirtd.service.in (Unit): Depend on dbus starting
first.

Domains configured with autostart may fail to start if the host
network stack has not been started.  E.g. when using bridged
networking autostarting a domain can fail with

libvirtd[1403]: 2012-06-20 13:23:49.833+0000: 1485: error :
qemuAutostartDomain:177 : Failed to autostart VM 'test': Cannot get
interface MTU on 'br0': No such device

Adding syslog.target is obsolete, avahi.target does not
exist and dbus.target is also obsolete
Reported-by: NLennart Poettering <lpoetter@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There is no 'udev.target' unit in systemd (only 'udev.service')
yet libvirtd's unit file had a dep on one. There's no compelling
reason for a dep on udev, so remove it altogether.
Reported-by: NAvi Kivity <avi@redhat.com>

Currently the libvirt.service unit file for systemd does not
specify any kill mode. So systemd kills off every process
inside its cgroup. ie all dnsmasq processes, all virtual
machines. This obviously not what we want. Set KillMode=process
so that it only kills the top level process of libvirtd

* daemon/libvirtd.service.in: Add KillMode=process
Reported-By: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

One of my latest patches (d8db0f96) created support for setting
the limit for the maximum of opened files by qemu user. However,
since libvirtd keeps one FD opened per domain (well, for qemu at least)
it will likely hit this limit on huge scenarios.

This patch adds support for a systemd init service for libvirtd
and libvirt-guests. The libvirtd.service is *not* written to use
socket activation, since we want libvirtd to start on boot so it
can do guest auto-start.

The libvirt-guests.service is pretty lame, just exec'ing the
original init script for now. Ideally we would factor out the
functionality, into some shared tool.

Instead of

  ./configure --with-init-script=redhat

You can now do

  ./configure --with-init-script=systemd

Or better still:

  ./configure --with-init-script=systemd+redhat

We can also now support install of the upstart init script

* configure.ac: Add systemd, and systemd+redhat options to
  --with-init-script option
* daemon/Makefile.am: Install systemd services
* daemon/libvirtd.sysconf: Add note about unused env variable
  with systemd
* daemon/libvirtd.service.in: libvirtd systemd service unit
* libvirt.spec.in: Add scripts to installing systemd services
  and migrating from legacy init scripts
* tools/Makefile.am: Install systemd services
* tools/libvirt-guests.init.sh: Rename to tools/libvirt-guests.init.in
* tools/libvirt-guests.service.in: systemd service unit