mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-01-22 12:35:17 +00:00
0756415f14
When a system has enabled the iptables/ip6tables services rather than firewalld, there is no explicit ordering of the start of those services vs. libvirtd. This creates a problem when libvirtd.service is started before ip[6]tables, as the latter, when it finally is started, will remove all of the iptables rules that had previously been added by libvirt, including the custom chains where libvirt's rules are kept. This results in an error message similar to the following when a user subsequently tries to start a new libvirt network: "Error while activating network: Call to virNetworkCreate failed: internal error: Failed to apply firewall rules /usr/sbin/ip6tables -w --table filter --insert LIBVIRT_FWO \ --in-interface virbr2 --jump REJECT: ip6tables: No chain/target/match by that name." (Prior to logging this error, it also would have caused failure to forward (or block) traffic in some cases, e.g. for guests on a NATed network, since libvirt's rules to forward/block had all been deleted and libvirt didn't know about it, so it couldn't fix the problem) When this happens, the problem can be remedied by simply restarting libvirtd.service (which has the side-effect of reloading all libvirt-generated firewall rules) Instead, we can just explicitly stating in the libvirtd.service file that libvirtd.service should start after ip6tables.service and ip6tables.service, eliminating the race condition that leads to the error. There is also nothing (that I can see) in the systemd .service files to guarantee that firewalld.service will be started (if enabled) prior to libvirtd.service. The same error scenario given above would occur if libvirtd.service started before firewalld.service. Even before that, though libvirtd would have detected that firewalld.service was disabled, and then turn off all firewalld support. So, for example, firewalld's libvirt zone wouldn't be used, and most likely traffic from guests would therefore be blocked (all with no external indication of the source of the problem other than a debug-level log when libvirtd was started saying that firewalld wasn't in use); also libvirtd wouldn't notice when firewalld reloaded its rules (which also simultaneously deletes all of libvirt's rules). I'm not aware of any reports that have been traced back to libvirtd.service starting before firewalld.service, but have seen that error reported multiple times, and also don't see an existing dependency that would guarantee firewalld.service starts before libvirtd.service, so it's possible it's been happening and we just haven't gotten to the bottom of it. This patch adds an After= line to the libvirtd.service file for each of iptables.service, ip6tables.service, and firewalld.servicee, which should guarantee that libvirtd.service isn't started until systemd has started whichever of the others is enabled. This race was diagnosed, and patch proposed, by Jason Montleon in https://bugzilla.redhat.com/1723698 . At the time (April 2019) danpb agreed with him that this change to libvirtd.service was a reasonable thing to do, but I guess everyone thought someone else was going to post a patch, so in the end nobody did. Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
.. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
:target: https://gitlab.com/libvirt/libvirt/pipelines
:alt: GitLab CI Build Status
.. image:: https://travis-ci.org/libvirt/libvirt.svg
:target: https://travis-ci.org/libvirt/libvirt
:alt: Travis CI Build Status
.. image:: https://bestpractices.coreinfrastructure.org/projects/355/badge
:target: https://bestpractices.coreinfrastructure.org/projects/355
:alt: CII Best Practices
==============================
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:
https://libvirt.org
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
============
Libvirt uses the GNU Autotools build system, so in general can be built
and installed with the usual commands, however, we mandate to have the
build directory different than the source directory. For example, to build
in a manner that is suitable for installing as root, use:
::
$ mkdir build && cd build
$ ../configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make
$ sudo make install
While to build & install as an unprivileged user
::
$ mkdir build && cd build
$ ../configure --prefix=$HOME/usr
$ make
$ make install
The libvirt code relies on a large number of 3rd party libraries. These will
be detected during execution of the ``configure`` script and a summary printed
which lists any missing (optional) dependencies.
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:
https://libvirt.org/contact.html