Applied on top of [1] that restores reinstantiating filters on daemon reload.
Note the fragile issue mentioned in ebiptablesDumpIstalledRules in respect to list
of firewall tables we are using.
I wonder can we instead of caching instantiate rules faster in the end? There
is iptables-restore if we instantiate directly. And in case of firewalld
mode why we instantiate filters via firewalld dbus interface after all? We use
passthrough interface so looks like firewalld don't account our rules in any
way. May be all we need is reloading rules on firewalld reload and always
instantiate thru binaries? Then we can do things fast.
Diff from v1 [2]:
------------
Approach is changed. Instead of checking whether applied filters changed
or not (so we can miss firewall changes from outside) let's check that
don't change both - rules we are going to apply and rules in firewall in
comparion to previous instantiation.
[1] [PATCH] nwfilter: intantiate filters on loading driver
https://www.redhat.com/archives/libvir-list/2018-October/msg00787.html
[2] [PATCH RFC 0/4] nwfilter: don't reinstantiate filters if they are not changed
https://www.redhat.com/archives/libvir-list/2018-October/msg00904.html
[3] [RFC] Faster libvirtd restart with nwfilter rules
https://www.redhat.com/archives/libvir-list/2018-September/msg01206.html
which continues in
https://www.redhat.com/archives/libvir-list/2018-October/msg00657.html
Nikolay Shirokovskiy (2):
firewall: add dump function
nwfilter: don't reinstantiate rules if there is no need to
src/libvirt_private.syms | 1 +
src/nwfilter/nwfilter_ebiptables_driver.c | 387 +++++++++++++++++++++++++++++-
src/util/virfirewall.c | 111 +++++++++
src/util/virfirewall.h | 3 +
4 files changed, 500 insertions(+), 2 deletions(-)
--
1.8.3.1