Bug 689377
| Summary: | libvirt 'dynamically' changed iptables vs. 'service iptables save' | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Jiri Kastner <jkastner> |
| Component: | libvirt | Assignee: | Laine Stump <laine> |
| Status: | CLOSED CANTFIX | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | crobinso, dallan, eblake, itxx00, xen-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-28 21:56:41 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Laine, I wonder if this has anything to do with the duplicate rules issue that was reported recently. (For others' reference, Dave is talking about Bug 772368) Anything is possible, but the strange thing in the case of Bug 772368 is that it's not *all* of the rules that are duplicated, only a few of them. That leads me to believe this isn't the issue. I can reproduce the issue with steps provided by Jiri Kastner. after iptables save then restarted and virsh net-destroy then net-start , the iptables rules are duplicated. (In reply to comment #3) > I can reproduce the issue with steps provided by Jiri Kastner. > after iptables save then restarted and virsh net-destroy then net-start , > the iptables rules are duplicated. and my libvirt version info: # virsh version Compiled against library: libvirt 0.10.2 Using library: libvirt 0.10.2 Using API: QEMU 0.10.2 Running hypervisor: QEMU 0.12.1 There is really nothing that libvirt can do about this, as iptables save will save *all* rules, and there is no way to mark particular rules as transient. (The best that could be done would be to attempt deleting existing rules that matched the rules about to be added, but that wouldn't help if the network config was changed - the existing saved rules would no longer match the new rules, so they would just stick around forever.) Once you have more than one entity on your host creating iptables rules, each of them needs to keep track of their own rules. "iptables save" simply is not a reasonable management interface, and shouldn't be used. This is just another symptom of the underlying unmanageability of iptables, which is what the firewalld project intends to solve. I'm inclined to close this as CANTFIX. I know what you mean,iptables is lousy at manage the rules, while libvirt does. Closing as CANTFIX as lain suggested, if anyone disagrees please reopen. |
Description of problem: 1) 'service iptables save' saves dynamic changes made by libvirt, but libvirt doesn't detect that and creates another one 2) completely ignore RH-Firewall-1-INPUT chain generated by system-config-securitylevel{,-tui} Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. define some iptables rules using system-config-securitylevel-tui 2. 'iptables -L' 3. install libvirt and start libvirtd 4. 'iptables -L' 5. 'service iptables save' 6. 'virsh net-destroy default' 7. 'iptables -L' 8. 'service iptables restart' 9. 'iptables -L' 10. 'virsh net-start default' 11. 'iptables -L' Actual results: .... Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable REJECT all -- anywhere anywhere reject-with icmp-port-unreachable ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable REJECT all -- anywhere anywhere reject-with icmp-port-unreachable ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable REJECT all -- anywhere anywhere reject-with icmp-port-unreachable RH-Firewall-1-INPUT all -- anywhere anywhere .... Expected results: iptables entries maintained in similar way as it system-config-securitylevel does. Additional info: