systemd provides a number of standard RPM macros but they don't quite satisfy our requirements, as evidenced by the fact that we have already built some custom tooling around them. Scenarios that the standard macros don't cover and that we're already addressing with our custom ones: * for some services (libvirtd, virtnetworkd, virtnwfilterd) there are multiple conditions that might lead to a restart, and we want to make sure that they're not needlessly restarted several times per transaction; * some services (virtlogd, virtlockd) must not be restarted during upgrade, so we have to reload them instead. Issues that neither the standard macros nor our custom ones address: * presets for units should be applied when the unit is first installed, not when the package that contains it is. The package split that happened in 9.1.0 highlighted why this last point is so important: when virtproxyd and its sockets were moved from libvirt-daemon to the new libvirt-daemon-proxy package, upgrades from 9.0.0 caused presets for them to be applied. On a platform such as Fedora, where modular daemons are the default, this has resulted in breaking existing deployments in at least two scenarios. The first one is machines that were configured to use the monolithic daemon, either because the local admin had manually changed the configuration or because the installation dated back to before modular daemons had become the default. In this case, virtproxyd.socket being enabled resulted in a silent conflict with libvirtd.socket, which by design shares the same path, and thus a completely broken setup. The second one is machines where virtproxy-tls.socket, which is disabled by default, had manually been enabled: in this case, applying the presets resulted in it being disabled and thus a loss of remote availability. Note that these are just two concrete scenarios, but the problem is more generic. For example, if we were to add more units to an existing package, per the current approach they wouldn't have their presets applied. The new macros are designed to avoid all of the pitfalls mentioned above. As a bonus, they're also simpler to use: where the current approach requires restarts and other operations to be handled separately, the new one integrates the two so that, for each scriptlet, a single macro call is needed. https://bugzilla.redhat.com/show_bug.cgi?id=2210058 Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Libvirt API for virtualization
Libvirt provides a portable, long term stable C API for managing the virtualization technologies provided by many operating systems. It includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER Hypervisor.
For some of these hypervisors, it provides a stateful management daemon which runs on the virtualization host allowing access to the API both by non-privileged local users and remote users.
Layered packages provide bindings of the libvirt C API into other languages including Python, Perl, PHP, Go, Java, OCaml, as well as mappings into object systems such as GObject, CIM and SNMP.
Further information about the libvirt project can be found on the website:
License
The libvirt C API is distributed under the terms of GNU Lesser General Public License, version 2.1 (or later). Some parts of the code that are not part of the C library may have the more restrictive GNU General Public License, version 2.0 (or later). See the files COPYING.LESSER
and COPYING
for full license terms & conditions.
Installation
Instructions on building and installing libvirt can be found on the website:
https://libvirt.org/compiling.html
Contributing
The libvirt project welcomes contributions in many ways. For most components the best way to contribute is to send patches to the primary development mailing list. Further guidance on this can be found on the website:
https://libvirt.org/contribute.html
Contact
The libvirt project has two primary mailing lists:
- libvirt-users@redhat.com (for user discussions)
- libvir-list@redhat.com (for development only)
Further details on contacting the project are available on the website: