External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-10-31 18:33:11 +00:00
Code Issues Packages Projects Releases Wiki Activity
f5897820ca
libvirt/src/remote/libvirtd.service.in

50 lines
1.5 KiB
SYSTEMD
Raw Normal View History

Add support for systemd init service 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
2011-07-07 13:45:07 +00:00
[Unit]
Description=Virtualization daemon
virtlogd.socket: Tie lifecycle to libvirtd.service We already guarantee that virtlogd.socket is enabled/disabled along with libvirtd.service, but if libvirtd.service has just been installed and is started before rebooting, then virtlogd.socket will not be running and guest startup will fail. Add Requires=virtlogd.socket to libvirtd.service to make sure virtlogd.socket is always started along with libvirtd.service, and add Before=libvirtd.service to both virtlogd.socket and virtlogd.service so that virtlogd never disappears before libvirtd has exited. Also add PartOf=libvirtd.service to both virtlogd.socket and virtlogd.service, so that virtlogd can be shut down when not needed. Resolves: https://bugzilla.redhat.com/1372576
2016-09-06 13:16:24 +00:00
Requires=virtlogd.socket
virtlockd: fix systemd unit file dependancies After deploying virtlogd by default we identified a number of mistakes in the systemd unit file. virtlockd's relationship to libvirtd is the same as virtlogd, so we must apply the same unit file fixes to virtlockd Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-01-17 15:45:57 +00:00
Requires=virtlockd.socket
remote: use Wants instead of Requires for libvirtd sockets To facilitate upgrades from earlier versions of libvirt which did not use socket activation for libvirtd, we want to allow the libvirtd socket units to be disabled (masked). This can only be supported if we use the weaker Wants statement instead of Requires. Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-22 13:48:46 +00:00
# Use Wants instead of Requires so that users
# can disable these three .socket units to revert
# to a traditional non-activation deployment setup
Wants=libvirtd.socket
Wants=libvirtd-ro.socket
Wants=libvirtd-admin.socket
libvirtd: Explicit dependency on systemd-machined The libvirtd daemon uses systemd-machined D-Bus API when manipulating domains. The systemd-machined is D-Bus activated on demand. However, during system shutdown systemd-machined is stopped concurrently with libvirtd and virsh users also doing their final cleanup may transitively fail due to unavailability of systemd-machined. Example error message > libvirtd[1390]: 2017-12-20 18:55:56.182+0000: 32700: error : virSystemdTerminateMachine:503 : Refusing activation, D-Bus is shutting down. To circumvent this we need to explicitly specify both ordering and requirement dependency (to avoid late D-Bus activation) on systemd-machined. See [1] for the dependency debate. [1] https://lists.freedesktop.org/archives/systemd-devel/2018-January/040095.html
2018-01-10 22:06:41 +00:00
Wants=systemd-machined.service
Add support for systemd init service 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
2011-07-07 13:45:07 +00:00
Before=libvirt-guests.service
systemd: start libvirtd after network 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
2012-07-09 15:52:55 +00:00
After=network.target
systemd: require dbus service 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 4c7973e. 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.
2012-12-05 03:43:04 +00:00
After=dbus.service
libvirt does not logout of iscsi targets, causing system hang on shutdown 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: Eric Blake <eblake@redhat.com>
2013-02-28 20:46:19 +00:00
After=iscsid.service
Make sure apparmor is started before libvirtd If apparmor security driver is enabled in either qemu or lxc driver configuration and libvirtd starts before AppArmor, it will fail.
2014-03-03 10:26:43 +00:00
After=apparmor.service
Start daemon only after filesystems are mounted 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: Martin Kletzander <mkletzan@redhat.com>
2015-08-25 15:07:46 +00:00
After=local-fs.target
After=remote-fs.target
libvirtd: Add service dependency on systemd-logind At daemon startup we query logind for host PM support status. Without a service dependency host startup can trigger libvirtd errors like: error : virNodeSuspendSupportsTarget:336 : internal error: Cannot probe for supported suspend types warning : virQEMUCapsInit:949 : Failed to get host power management capabilities https://bugzilla.redhat.com/show_bug.cgi?id=1588288 Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Cole Robinson <crobinso@redhat.com>
2018-06-07 14:44:34 +00:00
After=systemd-logind.service
libvirtd: Explicit dependency on systemd-machined The libvirtd daemon uses systemd-machined D-Bus API when manipulating domains. The systemd-machined is D-Bus activated on demand. However, during system shutdown systemd-machined is stopped concurrently with libvirtd and virsh users also doing their final cleanup may transitively fail due to unavailability of systemd-machined. Example error message > libvirtd[1390]: 2017-12-20 18:55:56.182+0000: 32700: error : virSystemdTerminateMachine:503 : Refusing activation, D-Bus is shutting down. To circumvent this we need to explicitly specify both ordering and requirement dependency (to avoid late D-Bus activation) on systemd-machined. See [1] for the dependency debate. [1] https://lists.freedesktop.org/archives/systemd-devel/2018-January/040095.html
2018-01-10 22:06:41 +00:00
After=systemd-machined.service
daemon: improve Xen support in systemd service The xencommons service provides all the essential services such as xenstored, xenconsoled, etc. needed by the libvirt Xen driver, so libvirtd should be started after xencommons. The xendomains service uses Xen's xl tool to operate on any domains it finds running, even those managed by libvirt. Add a conflicts on the xendomains service to ensure it is not enabled when libvirtd is enabled. Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-31 18:02:48 +00:00
After=xencommons.service
Conflicts=xendomains.service
Add Documentation fields to systemd service files We point to the manpages where available and redirect to libvirt's homepage as a last resort.
2014-01-08 18:55:19 +00:00
Documentation=man:libvirtd(8)
Use https:// links for most sites This adds a rule to require https links for the libvirt, qemu and kvm websites. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-10-13 15:30:41 +00:00
Documentation=https://libvirt.org
Add support for systemd init service 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
2011-07-07 13:45:07 +00:00
[Service]
virNetServerRun: Notify systemd that we're accepting clients 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>
2014-02-21 12:06:42 +00:00
Type=notify
build: don't hardcode /etc in the config related files Substitute in the @sysconfigdir@ value instead of /etc. Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-18 15:17:07 +00:00
EnvironmentFile=-@sysconfdir@/sysconfig/libvirtd
remote: move timeout arg into sysconf file We need to give users the ability to customize the length of the shutdown timeout, or even disable timeouts entirely. Thus we must move the timeout arg into the sysconf file, instead of the service unit. Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-22 13:51:06 +00:00
ExecStart=@sbindir@/libvirtd $LIBVIRTD_ARGS
Add support for systemd init service 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
2011-07-07 13:45:07 +00:00
ExecReload=/bin/kill -HUP $MAINPID
Leave all child processes running when stopping systemd service 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: Mark McLoughlin <markmc@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2012-03-22 14:01:12 +00:00
KillMode=process
Configuring systemd to restart libvirt on failure 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=981974 Signed-off-by: Eric Blake <eblake@redhat.com>
2013-07-30 12:32:59 +00:00
Restart=on-failure
Increase default file handle limits for daemons Linux still defaults to a 1024 open file handle limit. This causes scalability problems for libvirtd / virtlockd / virtlogd on large hosts which might want > 1024 guest to be running. In fact if each guest needs > 1 FD, we can't even get to 500 guests. This is not good enough when we see machines with 100's of physical cores and TBs of RAM. In comparison to other memory requirements of libvirtd & related daemons, the resource usage associated with open file handles is essentially line noise. It is thus reasonable to increase the limits unconditionally for all installs. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-03-15 16:51:51 +00:00
# At least 1 FD per guest, often 2 (eg qemu monitor + qemu agent).
# eg if we want to support 4096 guests, we'll typically need 8192 FDs
# If changing this, also consider virtlogd.service & virtlockd.service
# limits which are also related to number of guests
LimitNOFILE=8192
Increase default task limit for libvirtd libvirtd can spawn threads/tasks when creating new domains for some hypervisors such as Xen's libxl driver, quickly reaching the cgroups pids controller default TasksMax setting of 512. When the limit is reached, attempting to create additional domains results in an error from the cgroups pids controller, e.g. kernel: [71282.213347] cgroup: fork rejected by pids controller in /system.slice/libvirtd.service Depending on domain type and configuration, anywhere from 4-7 threads/tasks may be created by libxl when starting a domain. In order to support 4096 domains, similar to commit 27cd763500, increase the TasksMax setting in libvirtd.service to 4096 * 8 = 32768 tasks.
2017-04-19 18:54:33 +00:00
# The cgroups pids controller can limit the number of tasks started by
# the daemon, which can limit the number of domains for some hypervisors.
# A conservative default of 8 tasks per guest results in a TasksMax of
# 32k to support 4096 guests.
TasksMax=32768
Add support for systemd init service 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
2011-07-07 13:45:07 +00:00
[Install]
WantedBy=multi-user.target
libvirtd: enable virtlockd/virtlogd socket activation on install When someone does 'systemctl enable libvirtd.service' we should also enable virtlockd.socket/virtlogd.socket, so that they can be auto-activated if libvirtd tries to access the sockets. Without this, people have to manually enable the units themselves via 'systemctl enable virtdlogd.socket'. This also ensures that if distros uses 'systemctl preset' for enabling 'libvirtd.service', then the virtdlogd.socket gets enabled without having to wait for the distro to update their presets file. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2015-12-07 12:46:27 +00:00
Also=virtlockd.socket
Also=virtlogd.socket
remote: add systemd socket units for UNIX/TCP sockets We don't do socket activation of libvirtd, since we need to unconditionally start libvirtd in order to perform autostart. This doesn't mean we can't have systemd socket units. Some use cases will not need libvirt's autostart & are thus free to use activation. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-30 15:41:10 +00:00
Also=libvirtd.socket
Also=libvirtd-ro.socket
Reference in New Issue Copy Permalink