Bug 1544937
Summary: | libvirtd and firewalld need to be able to be restarted in co-ordination with each other, preserving post firewalld effective transaction set virtual client connections | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | R P Herrold <herrold> | ||||
Component: | libvirt | Assignee: | Laine Stump <laine> | ||||
Status: | CLOSED NOTABUG | QA Contact: | yalzhang <yalzhang> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.4 | CC: | berrange, crobinso, dyuan, fjin, herrold, laine, libvirt-maint, rbalakri, xuzhang, yafu, ztehypervisor | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | 1348434 | Environment: | |||||
Last Closed: | 2018-04-19 19:04:05 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
R P Herrold
2018-02-13 19:41:59 UTC
We absolutely should *not* restart libvirtd automatically when firewalld is restarted. When libvirtd has decided to use firewalld, it should not matter if firewalld is restarted. Libvirt can carry on using it once it has started again. The situation described in the original bug was talking bout the situation where the host is initially not running firewalld at all, and the user switches from using "iptables" init script, to using firewalld. Alternatively the reverse where the host is using firewalld, and it is then stopped & uninstalled and iptables initscript activated. Those iptables<->firewalld switch scenarios are the ones libvirt doesn't intend to support without a restart. @Daniel Berrange Concur as to your comment #2 ... I was really surprised to run into the issue, but seemingly it arises with manipulations of the firewalld (and a side application [fail2ban] ex EPEL) also working on the iptables doing ACD's [root@router ~]# rpm -qa fail\* fail2ban-server-0.9.7-1.el7.noarch fail2ban-firewalld-0.9.7-1.el7.noarch fail2ban-systemd-0.9.7-1.el7.noarch fail2ban-sendmail-0.9.7-1.el7.noarch fail2ban-0.9.7-1.el7.noarch [root@router ~]# rpm -qa libvir\* fire\* | sort firefox-52.6.0-1.el7.centos.x86_64 firewall-applet-0.4.4.4-6.el7.noarch firewall-config-0.4.4.4-6.el7.noarch firewalld-0.4.4.4-6.el7.noarch firewalld-filesystem-0.4.4.4-6.el7.noarch libvirt-3.2.0-14.el7_4.7.x86_64 libvirt-client-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-config-network-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-config-nwfilter-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-interface-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-lxc-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-network-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-nodedev-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-nwfilter-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-qemu-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-secret-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-core-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-disk-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-iscsi-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-logical-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-mpath-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-rbd-3.2.0-14.el7_4.7.x86_64 libvirt-daemon-driver-storage-scsi-3.2.0-14.el7_4.7.x86_64 libvirt-glib-1.0.0-1.el7.x86_64 libvirt-libs-3.2.0-14.el7_4.7.x86_64 libvirt-python-3.2.0-3.el7_4.1.x86_64 NB: libvirt listens on dbus for notifications of firewalld being restarted, and reloads all of the rules it needs (without itself restarting) when this happens. Also, whenever libvirtd is restarted, it removes and reloads all of its iptables rules as part of the startup. So as long as firewalld isn't permanently stopped, but just restarted, there shouldn't be any problem. So are you saying that you get this message in a situation where firewalld has not been stopped, but is just being restarted? Can you provide an exact set of steps to reproduce the problem? cron and systemd are doing it -- I have to dig a bit I also see the 'race condition' bug on ip6tables -- I was not previously aware that that was present perhaps that is in play as well Created attachment 1397099 [details]
log extract on affected unit, which I will use to hunt with
This is troubling:
[herrold@centos-7 tmp]$ nl firewalld-presence.txt | grep -i "perhaps"
48 Feb 13 14:13:04 router ip6tables.init: ip6tables: Flushing firewall rules: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
58 Feb 13 14:14:06 router ip6tables.init: ip6tables: Flushing firewall rules: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
[herrold@centos-7 tmp]$
that race bug I mentioned in Comment 5 is: https://bugzilla.redhat.com/show_bug.cgi?id=1486803 the other race bug was: https://bugzilla.redhat.com/show_bug.cgi?id=1477413 which is already cross-referenced in an UN-numbered comment: by: Lukas Vrabec 2018-02-14 07:40:55 EST (Note that libvirt already uses "-w" on iptables and ip6tables commands (and --concurrent on ebtables commands) if the local binaries of those applications support it.) I'm not seeing anything for us to do here. If there is some event that's causing firewalld to stop running, that is beyond libvirt's control (it should be fixed, but the fix will be elsewhere). Since we've stated that we don't want libvirt to automatically switch backends without restarting the daemon, I think this should just be closed. |