Bug 1943817

Summary: Libvirt errors due to the fact that it issues iptables commands when default firewall in RHEL 8 is nftables
Product: Red Hat Enterprise Linux 8 Reporter: Strahil Nikolov <hunter86_bg>
Component: libvirtAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.3CC: laine, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-03-28 00:26:04 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:

Description Strahil Nikolov 2021-03-27 17:19:14 UTC 
Description of problem:
Libvirt is using iptables commands that fail and they mess with other output.

Version-Release number of selected component (if applicable):
libvirt-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-bash-completion-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-client-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-config-network-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-config-nwfilter-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-interface-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-network-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-nodedev-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-nwfilter-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-qemu-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-secret-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-core-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-disk-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-gluster-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-iscsi-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-iscsi-direct-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-logical-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-mpath-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-rbd-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-driver-storage-scsi-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-kvm-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-dbus-1.3.0-2.module+el8.3.0+6423+e4cb6418.x86_64
libvirt-glib-3.0.0-1.el8.x86_64
libvirt-libs-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
python3-libvirt-6.0.0-1.module+el8.3.0+6423+e4cb6418.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Install 'Virtualization Host' group and cockpit-machines
2.Start libvirt
3.Create a network via cockpit
4.Update a static entry for the DHCP server


Actual results:
[root@rhel8 ~]# virsh net-update nat1 add ip-dhcp-host "<host mac='52:54:00:10:d4:42' name='sles15' ip='192.168.100.221' />" --live --config
error: Failed to update network nat1
error: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --insert LIBVIRT_INP --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT' failed: iptables: No chain/target/match by that name.

Expected results:
No errors should be generated.

Additional info:
Comment 1 Strahil Nikolov 2021-03-27 18:40:29 UTC 
Reinstalling libvirt module fixed the issue (this time I used the default network):
# virsh net-update default add ip-dhcp-host "<host mac='52:54:00:b4:df:94' name='sles15' ip='192.168.100.151' />" --live --config
Updated network default persistent config and live state


Seems that it's not a libvirt issue after all.
Comment 2 Laine Stump 2021-03-28 00:26:04 UTC 
Actually you are seeing Bug 1942805 (which I cloned from the year-old Fedora Bug 1813830 just a couple days ago when I realized standard RHEL8 is now using a libvirt version new enough to have the bug, but not new enough to have the fix (and it wasn't backported). It happens if firewalld is restarted while libvirtd.service is enabled and running. The workaround is that if you restart firewalld.service, just restart libvirtd.service right after that. See Bug 1942805 for more details.

*** This bug has been marked as a duplicate of bug 1942805 ***