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.
Go to file
Laine Stump b89c4991da network: add an nftables backend for network driver's firewall construction
Support using nftables to setup the firewall for each virtual network,
rather than iptables. The initial implementation of the nftables
backend creates (almost) exactly the same ruleset as the iptables
backend, determined by running the following commands on a host that
has an active virtual network:

  iptables-save >iptables.txt
  iptables-restore-translate -f iptables.txt

(and the similar ip6tables-save/ip6tables-restore-translate for an
IPv6 network). Correctness of the new backend was checked by comparing
the output of:

  nft list ruleset

when the backend is set to iptables and when it is set to nftables.

This page was used as a guide:

  https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables

The only differences between the rules created by the nftables backed
vs. the iptables backend (aside from a few inconsequential changes in
display order of some chains/options) are:

1) When we add nftables rules, rather than adding them in the
system-created "filter" and "nat" tables, we add them in a private
table (ie only we should be using it) created by us called "libvirt"
(the system-created "filter" and "nat" tables can't be used because
adding any rules to those tables directly with nft will cause failure
of any legacy application attempting to use iptables when it tries to
list the iptables rules (e.g. "iptables -S").

(NB: in nftables only a single table is required for both nat and
filter rules - the chains for each are differentiated by specifying
different "hook" locations for the toplevel chain of each)

2) Since the rules that were added to allow tftp/dns/dhcp traffic from
the guests to the host are unnecessary in the context of nftables,
those rules aren't added.

(Longer explanation: In the case of iptables, all rules were in a
single table, and it was always assumed that there would be some
"catch-all" REJECT rule added by "someone else" in the case that a
packet didn't match any specific rules, so libvirt added these
specific rules to ensure that, no matter what other rules were added
by any other subsystem, the guests would still have functional
tftp/dns/dhcp. For nftables though, the rules added by each subsystem
are in a separate table, and in order for traffic to be accepted, it
must be accepted by *all* tables, so just adding the specific rules to
libvirt's table doesn't help anything (as the default for the libvirt
table is ACCEPT anyway) and it just isn't practical/possible for
libvirt to find *all* other tables and add rules in all of them to
make sure the traffic is accepted. libvirt does this for firewalld (it
creates a "libvirt" zone that allows tftp/dns/dhcp, and adds all
virtual network bridges to that zone), however, so in that case no
extra work is required of the sysadmin.)

3) nftables doesn't support the "checksum mangle" rule (or any
equivalent functionality) that we have historically added to our
iptables rules, so the nftables rules we add have nothing related to
checksum mangling.

(NB: The result of (3) is that if you a) have a very old guest (RHEL5
era or earlier) and b) that guest is using a virtio-net network
device, and c) the virtio-net device is using vhost packet processing
(the default) then DHCP on the guest will fail. You can work around
this by adding <driver name='qemu'/> to the <interface> XML for the
guest).

There are certainly much better nftables rulesets that could be used
instead of those implemented here, and everything is in place to make
future changes to the rules that are used simple and free of surprises
(e.g. the rules that are added have coresponding "removal" commands
added to the network status so that we will always remove exactly the
rules that were previously added rather than trying to remove the
rules that "the current build of libvirt would have added" (which will
be incorrect the first time we run a libvirt with a newly modified
ruleset). For this initial implementation though, I wanted the
nftables rules to be as identical to the iptables rules as possible,
just to make it easier to verify that everything is working.

The backend can be manually chosen using the firewall_backend setting
in /etc/libvirt/network.conf. libvirtd/virtnetworkd will read this
setting when it starts; if there is no explicit setting, it will check
for availability of FIREWALL_BACKEND_DEFAULT_1 and then
FIREWALL_BACKEND_DEFAULT_2 (which are set at build time in
meson_options.txt or by adding -Dfirewall_backend_default_n=blah to
the meson commandline), and use the first backend that is available
(ie, that has the necessary programs installed). The standard
meson_options.txt is set to check for nftables first, and then
iptables.

Although it should be very safe to change the default backend from
iptables to nftables, that change is left for a later patch, to show
how the change in default can be undone if someone really needs to do
that.

Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel P. Berrangé <berrange@redhat.com>
2024-05-22 23:20:07 -04:00
.ctags.d
.github/workflows github: Update lockdown message when opening a PR 2024-05-15 12:31:23 +02:00
.gitlab/issue_templates
build-aux virshtest: Prepare for testing against output files 2024-04-02 14:24:30 +02:00
ci ci: Introduce Ubuntu 24.04 2024-05-14 15:17:23 +02:00
docs docs: Fix broken links 2024-05-21 12:21:52 +02:00
examples examples: Define _GNU_SOURCE for more examples 2024-02-07 18:01:03 +01:00
include libvirt: Introduce virDomainGraphicsReload API 2024-03-08 17:00:15 +01:00
po network: add an nftables backend for network driver's firewall construction 2024-05-22 23:20:07 -04:00
scripts scripts/rpcgen: skip tests if tirpc is not present 2024-05-08 15:57:13 +01:00
src network: add an nftables backend for network driver's firewall construction 2024-05-22 23:20:07 -04:00
subprojects Move src/keycodemapdb -> subprojects/keycodemapdb 2023-04-17 15:02:38 +02:00
tests network: use previously saved list of firewall removal commands 2024-05-22 23:20:07 -04:00
tools vsh: Fix '--help' option for virsh/virt-admin 2024-05-16 09:03:48 +02:00
.ctags
.dir-locals.el
.editorconfig
.gitattributes
.gitignore Revert ".gitignore: Ignore cscope and other *tags files" 2023-02-08 17:24:31 +01:00
.gitlab_pages_redirects docs: gitlab redirects: Drop '/libvirt' prefix for hosting the web through gitlab pages 2024-02-13 16:56:49 +01:00
.gitlab-ci.yml gitlab-ci: Switch coverity job to AlmaLinux 9 2024-05-14 15:52:33 +02:00
.gitmodules Move src/keycodemapdb -> subprojects/keycodemapdb 2023-04-17 15:02:38 +02:00
.gitpublish gitpublish: Tweak prefix 2023-12-05 11:48:28 +01:00
.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: stop looking for iptables/ip6tables/ebtables at build time 2024-05-22 23:20:07 -04:00
meson_options.txt network: add an nftables backend for network driver's firewall construction 2024-05-22 23:20:07 -04:00
meson.build network: add an nftables backend for network driver's firewall construction 2024-05-22 23:20:07 -04:00
NEWS.rst NEWS: Mention '--help' bug in virsh and virt-admin 2024-05-16 09:03:49 +02:00
README.rst docs: update docs pointing to old mailing list addrs 2023-10-31 10:04:27 +00:00
run.in run: add ability to set selinux context 2023-08-23 14:22:36 -05:00

GitLab CI Build Status

CII Best Practices

Translation status

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

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:

Further details on contacting the project are available on the website:

https://libvirt.org/contact.html