Bug 1942805
| Summary: | cannot restart default network and firewalld: iptables: No chain/target/match by that name. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Laine Stump <laine> | |
| Component: | libvirt | Assignee: | Laine Stump <laine> | |
| Status: | CLOSED ERRATA | QA Contact: | yalzhang <yalzhang> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 8.4 | CC: | agedosier, alex.iribarren, berrange, clalancette, ehadley, extras-qa, hunter86_bg, itamar, jdenemar, jfehlig, jforbes, jsuchane, laine, libvirt-maint, mpitt, rjones, steve, veillard, virt-maint, virt-maint, yalzhang, ymankad | |
| Target Milestone: | rc | Keywords: | Triaged, ZStream | |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | libvirt-6.0.0-36.el8 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | 1813830 | |||
| : | 1958301 (view as bug list) | Environment: | ||
| Last Closed: | 2021-11-09 18:00:11 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: | ||||
| Bug Depends On: | 1813830 | |||
| Bug Blocks: | 1958301 | |||
|
Description
Laine Stump
2021-03-25 03:12:23 UTC
*** Bug 1943817 has been marked as a duplicate of this bug. *** Reproduce this bug on libvirt-6.0.0-35.module+el8.5.0+10709+b3edb581.x86_64 1. Ensure libvirtd is started when the firewalld is running; # systemctl restart firewalld; systemctl restart libvirtd; virsh net-start default 2. destroy the network and stop firewalld; # virsh net-destroy default; systemctl stop firewalld Network default destroyed # virsh net-list --all; firewall-cmd --get-active-zones Name State Autostart Persistent ---------------------------------------------- default inactive yes yes FirewallD is not running 2. Start the firewalld, then try to start the network; # systemctl start firewalld; virsh net-start default error: Failed to start network default error: internal error: Failed to apply firewall rules /usr/sbin/iptables -w --table filter --insert LIBVIRT_INP --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT: iptables: No chain/target/match by that name. And test on libvirt-7.3.0-1.module+el8.5.0+11004+f4810536.x86_64 which should include the patch, the result is pass. > I can also `systemctl stop firewalld` and `systemctl start firewalld`, and everything is still in order.
When I change the firewalld status since libvirtd started, no matter from inactive to active or vice versa, or just restart, it will clear all the rules and chains. And the NAT for the default network will not work, not "still in order".
I remember there was a related bugzilla comment a long time ago, but I can not find it now. I remember its general idea was “do not change firewalld status when libvirtd is running” or “restart libvirtd once firewalld status changes, including restart”. Maybe my memory or understanding is wrong. And I never test such scenarios nor consider it as a bug. But seems the behavior is different now. What do you think about it? Please help to confirm. And please help to check scenario 2, network fail to start after firewalld restart.
Test on libvirt-6.0.0-36.module+el8.5.0+11222+c889b3f3.x86_64 with scenarios as below:
Scenario 1: Same steps as the reproduce procedure "do both together":
1) ensure the network is active:
# virsh net-list --all
Name State Autostart Persistent
--------------------------------------------
default active yes yes
2) destroy network and stop firewalld:
# virsh net-destroy default; systemctl stop firewalld
Network default destroyed
# virsh net-list --all; firewall-cmd --get-active-zones
Name State Autostart Persistent
----------------------------------------------
default inactive yes yes
FirewallD is not running
3) start firewalld and try to start the network, it can start successfully, which is expected.
# systemctl start firewalld; virsh net-start default
Network default started
Scenario 2: start network after restart firewalld, network can not start successfully. It happens about 80% of all the times I have tried.
# cat restart_test.sh
#!/bin/bash
# this is to confirm the env is clean
systemctl restart libvirtd
virsh net-start default
virsh net-list --all
systemctl restart firewalld; systemctl restart libvirtd;
echo "*************before firewalld restart*****************"
iptables -L
systemctl restart firewalld
echo "*************after firewalld restart*************************"
iptables -L
virsh net-destroy default;
virsh net-start default;
# ./restart_test.sh
Network default started
Name State Autostart Persistent
--------------------------------------------
default active yes yes
*************before firewalld restart*****************
Chain INPUT (policy ACCEPT)
target prot opt source destination
LIBVIRT_INP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
LIBVIRT_FWX all -- anywhere anywhere
LIBVIRT_FWI all -- anywhere anywhere
LIBVIRT_FWO all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
LIBVIRT_OUT all -- anywhere anywhere
Chain LIBVIRT_INP (1 references)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain LIBVIRT_OUT (1 references)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
ACCEPT tcp -- anywhere anywhere tcp dpt:bootpc
Chain LIBVIRT_FWO (1 references)
target prot opt source destination
ACCEPT all -- 192.168.124.0/24 anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain LIBVIRT_FWI (1 references)
target prot opt source destination
ACCEPT all -- anywhere 192.168.124.0/24 ctstate RELATED,ESTABLISHED
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain LIBVIRT_FWX (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
*************after firewalld restart*************************
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Network default destroyed
error: Failed to start network default
error: internal error: Failed to apply firewall rules /usr/sbin/iptables -w --table filter --insert LIBVIRT_INP --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT: iptables: No chain/target/match by that name.
The thing that you're remembering is that it's not supported to either stop firewalld (and have it remain stopped) or start firewalld (and have it remain started) while a single libvirtd is running - if you do this you need to restart libvirtd. The test that you're running *should* be working properly though, because you only stop firewalld and then immediately start it (which is effectively the same as a restart, which is fine). My guess is that possibly you are running iptables -L and attempting to start the default network the final time so soon after firewalld has been restarted that there hasn't yet been time for libvirtd to receive and process the dbus message telling it that firewalld has been restarted. Try putting a sleep 5 or something into the script just before the final "iptables -L". Assuming my theory is correct, I don't think there is any way for libvirt to guarantee a successful start of a network in this case - it doesn't know that firewalld has restarted until it gets the dbus message, but that message won't arrive until some time after all of libvirt's chains/rules have already been removed by the firewalld restart; if libvirt tries to start a new network during that time, it won't know that it's chains are temporarily missing, and so will be correct in complaining about it. As long as the rules are "eventually" added back, and a delayed attempt to start a new network is successful without any other intervention, then I think we've done the best that we can do. Hi laine, after sleep 10, it still fail, please help to have a look: # rpm -q libvirt firewalld libvirt-6.0.0-35.module+el8.4.0+10230+7a9b21e4.x86_64 firewalld-0.8.2-6.el8.noarch # cat test.sh #!/bin/bash # this is to confirm the env is clean systemctl restart libvirtd virsh net-start default virsh net-list --all systemctl restart firewalld; sleep 5; systemctl restart libvirtd; echo "*************before firewalld restart*********************" sleep 5 iptables -L systemctl restart firewalld echo "*************after firewalld restart*************************" echo "sleep 10 here:" sleep 10 iptables -L virsh net-destroy default; virsh net-start default; # ./test.sh Network default started Name State Autostart Persistent ------------------------------------------------ default active yes yes host-bridge active no yes hostdev-net active no yes *************before firewalld restart********************* Chain INPUT (policy ACCEPT) target prot opt source destination LIBVIRT_INP all -- anywhere anywhere ...(the Chains, rules are all expected)... *************after firewalld restart************************* sleep 10 here: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Network default destroyed error: Failed to start network default error: internal error: Failed to apply firewall rules /usr/sbin/iptables -w --table filter --insert LIBVIRT_INP --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT: iptables: No chain/target/match by that name. Sorry, I used the old version in comment 14. With new version libvirt-6.0.0-36.module+el8.5.0+11222+c889b3f3.x86_64, when I set sleep time, the result is as expected. Set the bug to be verified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:4191 |