43a0881274
A user reported that if they set <forward mode='nat|route' dev='blah'>
starting the network would fail if the device 'blah' didn't already
exist.
This is caused by using "iif" and "oif" in nftables rules to check for
the forwarding device - these two commands work by saving the named
interface's ifindex (an unsigned integer) when the rule is added, and
comparing it to the ifindex associated with the packet's path at
runtime. This works great if the interface both 1) exists when the
rule is added, and 2) is never deleted and re-created after the rule
is added (since it would end up with a different ifindex).
When checking for the network's bridge device, it is okay for us to
use "iif" and "oif", because the bridge device is created before the
firewall rules are added, and will continue to exist until just after
the firewall rules are deleted when the network is shutdown.
But since the forward device might be deleted/re-added during the
lifetime of the network's firewall rules, we must instead us "oifname"
and "iifname" - these are much less efficient than "Xif" because they
do a string compare of the interface's name rather than just comparing
two integers (ifindex), but they don't require the interface to exist
when the rule is added, and they can properly cope with the named
interface being deleted and re-added later.
Fixes:
|
||
|---|---|---|
| .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: