1a72b83d56
The bit of code that sets the firewalld zone was previously a part of the function networkAddFirewallRules(), which is not called for networks with <forward mode='open'/>. Setting the 'libvirt' zone for the bridge device of virtual networks that also add firewall rules is usually necessary in order to get the expected traffic through without modifying firewalld's default zone (which would be a bad idea, because that would affect all the other host interfaces set to the default zone), but in general we would *not* want the bridge device for a mode='open' virtual network to be automatically placed in the "libvirt" zone. However, a user might want to *explicitly* set some other firewalld zone for mode='open' networks, and libvirt's network config is a convenient place to do that. We enable this by moving the code that sets the firewalld zone into a separate function that is called for all forward modes that use a bridge device created/managed by libvirt (nat, route, isolated, open). If no zone is specified, then the bridge device will be in whatever zone interfaces are put in by default, but if the <bridge> element has a "zone" attribute, then the new bridge device will be placed in the specified zone. NB: This function is only called when the network is started, and *not* when the firewall rules of an active network are reloaded at virtnetworkd restart time, because the firewalld zone of an interface isn't something that gets inadvertantly changed as a part of some other unrelated action. For example all iptables rules are cleared by a firewalld restart, including those rules added by libvirt, but there is no blanket action that changes the zone of all interfaces, so it's useful for libvirt to reload its rules when restarting virtnetworkd, but pointless to re-add the interface to its preferred zone. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/215 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com> |
||
|---|---|---|
| .ctags.d | ||
| .github/workflows | ||
| .gitlab/issue_templates | ||
| build-aux | ||
| ci | ||
| docs | ||
| examples | ||
| include | ||
| po | ||
| scripts | ||
| src | ||
| subprojects | ||
| tests | ||
| tools | ||
| .ctags | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab_pages_redirects | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .gitpublish | ||
| .mailmap | ||
| AUTHORS.rst.in | ||
| config.h | ||
| configmake.h.in | ||
| CONTRIBUTING.rst | ||
| COPYING | ||
| COPYING.LESSER | ||
| gitdm.config | ||
| libvirt-admin.pc.in | ||
| libvirt-lxc.pc.in | ||
| libvirt-qemu.pc.in | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| meson_options.txt | ||
| meson.build | ||
| NEWS.rst | ||
| README.rst | ||
| run.in | ||
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: