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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
