9293644d8a
(This paragraph is for historical reference only, described only to avoid confusion of past use of the name with its new use) In a past life, virFirewallBackend had been a private static in virfirewall.c that was set at daemon init time, and used to globally (i.e. for all drivers in the daemon) determine whether to directly execute iptables commands, or to run them indirectly via the firewalld passthrough API. This was removed in commit d566cc55, since we decided that using the firewalld passthrough API is never appropriate. Now the same enum, virFirewallBackend, is being reintroduced, with a different meaning and usage pattern. It will be used to pick between using nftables commands or iptables commands (in either case directly handled by libvirt, *not* via firewalld). Additionally, rather than being a static known only within virfirewall.c and applying to all firewall commands for all drivers, each virFirewall object will have its own backend setting, which will be set during virFirewallNew() by the driver who wants to add a firewall rule. This will allow the nwfilter and network drivers to each have their own backend setting, even when they coexist in a single unified daemon. At least as important as that, it will also allow an instance of the network driver to remove iptables rules that had been added by a previous instance, and then add nftables rules for the new instance (in the case that an admin, or possibly an update, switches the driver backend from iptables to nftable) Initially, the enum will only have one usable value - VIR_FIREWALL_BACKEND_IPTABLES, and that will be hardcoded into all calls to virFirewallNew(). The other enum value (along with a method of setting it for each driver) will be added later, when it can be used (when the nftables backend is in the code). Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@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:
- users@lists.libvirt.org (for user discussions)
- devel@lists.libvirt.org (for development only)
Further details on contacting the project are available on the website: