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>
The decision is based only on whether Polkit support is enabled,
so there's no need to go through it again for every single
service.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The meaning of the _def suffix might not be immediately obvious,
especially since it's also used to refer to the output of the
meson-gen-def.py script elsewhere in the same file.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The information is not used anywhere right now, but the
documentation for virt_daemon_units claims it's mandatory.
We also intend to actually start using it later on.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This tells systemd that the services in question support the
native socket activation protocol.
virtlogd and virtlockd, just like all the other daemons, implement
the necessary handshake.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
While systemd will automatically match foo.socket with foo.service
based on their names, it's nicer to connect the two explicitly.
This is what we do for all services, with virtlogd and virtlockd
being the only exceptions.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This annotation being missing resulted in virtlogd and virtlockd
being marked as "indirect" services, i.e. services that cannot
be started directly but have to be socket activated instead.
While this is our preferred configuration, we shouldn't prevent
the admin to start them at boot if they want to.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When libvirtd, virtlog and virtlockd are enabled, we want their
admin sockets to be enabled for socket activation as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/
Co-authored-by: Weblate <noreply@weblate.org>
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
Commit 93af79fb removed a cleanup label in favor of returning error
values directly in certain cases. But the final return value was changed
from -1 to 0. If we get to the end of the function, that means that
we've waited for the process to exit but it still exists. So we should
return -1. The error message was still being set correctly, but we were
returning a success status (0).
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In a modular daemon configuration, virtxend does not support the
virNetwork* APIs. It should open a connection to virtnetworkd when
using those APIs, but currently always opens a connection to
"xen:///system". Switch to using virGetConnectNetwork to obtain a
valid connection instead of using the hardcoded URI.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
