On 3/20/20 5:25 AM, nshirokovskiy wrote:
Hi, all.
Some time ago I posted RFC [1] concerning an issue of unresponsive
libvird during restart if there is large number of VMs that have network
filters on their interfaces. It was identified that in most cases we
don't need actually to reinstall network filter rules on daemon restart.
Thus I proposed patches [2] that check whether we need to reapply rules
or not.
The first version has a drawback that daemon won't reapply rules if
someone mangled them between daemon stop and start (and this can be done
just by restarting firewalld). The second one is just ugly :)
Around that time Florian Westphal in a letter off the mailing list
suggested to use {iptables|ebtables}-restore to apply rules in one
binary call. These binaries has --noflush option so that we won't reset
current state of tables. We also need one more -L call for
iptables/ebtables to query current filter state to be able to construct
input for restore binaries.
So are you considering doing something with this idea? At the end of our
discussion, both libvirt and firewalld people agreed that we're gaining
nothing from setting our rules via firewalld passthrough, and we would
be potentially gaining *a lot* by setting them in batch mode with
"iptables-restore -n".
Perhaps we could just add a new firewall backend (in util/virfirewall.c)
that checked for the presence of iptables-restore (and ip6tables-restore
and ebtables-restore), and if they are found it would use a backend that
just put all the rules for each layer together in a temporary file and
send them to *-restore (the internals would need to be reorganized a
bit, so that args like -w, -l, and -n could be added in during
virFirewallApply (if necessary) rather than when initially adding rules).
Ooh! I just tried it, and iptables-restore also accepts (and acts on)
lines with "-D" to delete rules! So we could do everything in a single
go - intermixing -D and -A rules in the same file (to minimize the time
when the firewall would be incorrect while still taking advantage of the
efficiency of doing everything in a batch).
I wonder can we use this approach? I see currently only one issue - we
won't use firealld to spawn rules. But why we need to spawn rules
through firewalld if it present? We use passthrough mode anyway. I tried
to dig history for hints but didn't found anything. Patch [3] introduced
spawning rules thru firewalld-cmd.
Nikolay
[1] [RFC] Faster libvirtd restart with nwfilter rules
https://www.redhat.com/archives/libvir-list/2018-September/msg01206.html
[2] nwfilter: don't reinstantiate filters if they are not changed
v1: https://www.redhat.com/archives/libvir-list/2018-October/msg00904.html
v2: https://www.redhat.com/archives/libvir-list/2018-October/msg01317.html
[3] network: use firewalld instead of iptables, when available
v0: https://www.redhat.com/archives/libvir-list/2012-April/msg01236.html
v1: https://www.redhat.com/archives/libvir-list/2012-August/msg00447.html
...
v4: https://www.redhat.com/archives/libvir-list/2012-August/msg01097.html
