virProcessKillPainfullyDelay() currently almost always returns 1 or -1,
even though the documentation indicates that it should return 0 if the
process was terminated gracefully. But the computation of the return
code is faulty and the only case where it currently returns 0 is when it
is called with the pid of a process that does not exist.
Since no callers ever even distinguish between the 0 and 1 response
codes, simply get rid of the distinction and return 0 for both cases.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Like the Description, these are intended to be displayed to the
user, so it makes sense to have them towards the top of the file
before all the information that systemd will parse to calculate
dependencies.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Hypervisors are referred to by their user-facing name rather
than the name of their libvirt driver, the monolithic daemon is
explicitly referred to as legacy, and a consistent format is
used throughout.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently we only set this for the main sockets, which means
that
$ systemctl stop virtqemud.socket
will make the socket disappear from the filesystem while
$ systemctl stop virtqemud-ro.socket
won't. Get rid of this inconsistency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This results in all sockets for a service being enabled when a
single one of them is.
The -tcp and -tls sockets are intentionally excluded, because
enabling them should require explicit action on the
administrator's part; moreover, disabling them should not result
in the local sockets being disabled too.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
systemd will automatically infer this dependency based on the
socket's Service=foo.service setting.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We have already declared the mirror relationship, so this one
is now redundant.
Moreover, this version was incomplete: it only ever worked for
the monolithic daemon, but the modular daemons for QEMU and Xen
also want the sockets to be active.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Requires/Wants only tells systemd that the corresponding unit
should be started when the current one is, but that could very
well happen in parallel. For virtlogd/virtlockd, we want the
socket to be already active when the hypervisor driver is
started.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Only the main socket is actually necessary for the service to be
usable.
In the past, we've had security issues that could be exploited via
access to the read-only socket, so a security-minded administrator
might consider disabling all optional sockets. This change makes
such a setup possible.
Note that the services will still try to activate all their
sockets on startup, even if they have been disabled. To make sure
that the optional sockets are never started, they will have to be
masked.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This is the strongest relationship that can be declared between
two units, and causes the service to be terminated immediately
if its main socket disappears. This is the behavior we want.
Note that we don't do the same for the read-only/admin sockets,
because those are not as critical for the core functionality of
services as the main socket it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We want to make sure that, at any given time, we have either the
modular daemons or the monolithic one running, never both. In
order to achieve that, make every single modular unit conflict
with the corresponding libvirtd unit.
We set both Conflicts=libvirtd.unit and After=libvirtd.unit: this
tells systemd that, whenever virtfood.unit and libvirtd.unit are
part of the same transaction, the former should win out.
Thanks to this, if both the modular daemons and the monolithic
one have been enabled because of outdated automation or a simple
mistake of the administrator, the request to start libvirtd at
boot will be ignored and the result will be a regular modular
deployment.
If the request to start libvirtd is made when the modular daemons
are already running, we have no way to prevent systemd from
complying with that request; however, thanks to the way the
conflict relationship has been declared, they will be shut down
cleanly before libvirtd is started. From the user's point of
view, the transition from modular to monolithic will be
completely transparent: it's basically the same scenario as a
regular package upgrade, just with an extra twist.
Note that, while switching from modular to monolithic at runtime
happens automatically, going back requires manual intervention,
i.e. starting all the necessary sockets one by one. That's okay:
the goal here is to prevent misconfiguration and force of habit
to accidentally disrupt a working setup, not to encourage the
scenario. In a correctly configured and managed host, it should
never occur.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Up until now the files have been used as template for most
services, but now that those have been converted to common
templates we can drop parametrization and make it clear that
these files are for libvirtd only.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that the migration to common templates has been completed,
we no longer need these.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
All services are still listing their input files explicitly, so
no changes to the output files will occur yet.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We already use templating to generate sockets, which are all
based off libvirtd's. Push the idea further, and extend it to
cover services as well.
This is more challenging, as the various modular daemons each have
their own needs in terms of what system services needs to be
available before they can be started, which other components of
libvirt they depend on, and so on.
In order to make this sort of per-service tweaks possible, we
introduce a Python script that can merge two systemd units
together. The script is aware of the semantics of systemd's unit
definition format, so it can intelligently merge sections
together.
This generic systemd unit merging mechanism will also supersede
the extremely ad-hoc @deps@ variable, which is currently used in
a single scenario.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We're about to change the defaults and start migrating to common
templates: in order to be able to switch units over one at a
time, make the input files that are currently used explicit
rather than implicit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
These will be useful during the upcoming migration to common
templates for systemd units and will be dropped as soon as all
services have been converted.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It is currently considered required, but we're soon going to
provide a default that will be suitable for most services.
Since all services currently provide a value explicitly, we
can implement a default without breaking anything.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
They're similar to the existing socket_in/socket_out variables
and will make future changes nicer.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The idea behind these is to prevent running both modular daemons
and monolithic daemon at the same time. We will implement a more
effective solution for that shortly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
send-email scans the commit messages to figure out the default set of
addresses to put into CC, Acked-by/Reviewed-by, etc-by being among
them. We're quite strict about CC-ing people on libvirt-list, since
most developers are subscribed to the list anyway. Respect the rule by
avoiding CCing people solely based on the fact that they've done review
of any of previous revisions.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The network metadata support is a new feature in the upcoming
release, not a removed one. Place it accordingly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virBitmapFormat returns the string that should be freed.
All strings in three ADD_BITMAP calls in qemuDomainGetGuestVcpusParams
are contained in tmp. So memory leak is possible here without VIR_FREE.
Fixes: 0108deb944
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The actual versioning policy[1] is a bit more nuanced, and in
particular there are scenarios in which the monthly release
is intentionally skipped, but overall it's not inaccurate to
claim that the release cadence of the Go bindings follows the
one of the C library.
[1] https://gitlab.com/libvirt/libvirt-go-module/-/blob/master/VERSIONING.rst
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that providing the value is optional, we can remove almost
all uses.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For most services, the socket paths can be derived trivially from
the name of the daemon: for virtqemud, for example, they will be
/run/libvirt/virtqemud-sock
/run/libvirt/virtqemud-sock-ro
/run/libvirt/virtqemud-admin-sock
libvirtd and virtproxyd are the exceptions, since their socket
paths will be
/run/libvirt/libvirt-sock
/run/libvirt/libvirt-sock-ro
/run/libvirt/libvirt-admin-sock
So we still need to be able to provide a custom @sockprefix@ in
those cases, but in the most common scenario we can do away with
the requirement by introducing a sensible default.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For most services, the value provided explicitly matches the
documented default.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
