Bug 622649
| Summary: | Guest can not get ip adress because libvirt iptables rules were not added | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | yanbing du <ydu> |
| Component: | libvirt | Assignee: | Peter Krempa <pkrempa> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.0 | CC: | berrange, dallan, ddumas, dyuan, eblake, jialiu, jmiao, juzhou, kxiong, mshao, tools-bugs, xen-maint, yoyzhang |
| Target Milestone: | rc | Keywords: | TestOnly |
| Target Release: | 7.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-1.1.1-1.el7 | Doc Type: | Bug Fix |
| Doc Text: |
Libvirt uses transient iptables rules for managing NAT or bridging to virtual machine guests. Any external command that reloads iptables state ( such as running system-config-firewall) will overwrite the entries needed by libvirt. Consequently, after running any command or tool that changes the state of iptables, guests may lose access the network. To work around this issue, use the command 'service libvirtd reload' to restore libvirt's additional iptables rules.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 11:34:11 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: | |||
|
Description
yanbing du
2010-08-10 03:40:30 UTC
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. ** I'm wondering if this is related to bug 617505. I'm also seeing some weird behavior where system-config-firewall hangs trying to update the iptables rules, or where 'iptables -L' shows fewer rules than what I know I set up in system-config-firewall. In other words, this may be a kernel or iptables bug, rather than a libvirt bug. FYI, any time that system-config-firewall is run, it will blow away all the iptables rules created by libvirt. You need to run 'service libvirt reload' to re-create them. (In reply to comment #5) > FYI, any time that system-config-firewall is run, it will blow away all the > iptables rules created by libvirt. You need to run 'service libvirt reload' to > re-create them. Please re-test based on Daniel's suggestion. On the new host, before do any action, check the iptables, as following: [root@dhcp duyanbing]# service iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 2 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destination [root@dhcp duyanbing]# service libvirtd reload Reloading libvirtd configuration: [ OK ] [root@dhcp duyanbing]# service iptables status Table: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 MASQUERADE tcp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 2 MASQUERADE udp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 3 MASQUERADE all -- 192.168.122.0/24 !192.168.122.0/24 Chain OUTPUT (policy ACCEPT) num target prot opt source destination Table: mangle Chain PREROUTING (policy ACCEPT) num target prot opt source destination Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 CHECKSUM udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68 CHECKSUM fill Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 3 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 5 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 6 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 7 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 8 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 9 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 2 ACCEPT all -- 192.168.122.0/24 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 6 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 7 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destination [root@dhcp duyanbing]# system-config-firewall [root@dhcp duyanbing]# service iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21 5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 6 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 2 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destination Result:just like Daniel's comment, everytime after run system-config-firewall, need run 'service libvirt reload' to re-create libvirt iptables rules. As default, after install a new host with build-RHEL6-20100811.2, the iptables have the libvirtd related rules. # service iptables status Table: mangle Chain PREROUTING (policy ACCEPT) num target prot opt source destination Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 CHECKSUM udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68 CHECKSUM fill Table: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 MASQUERADE tcp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 2 MASQUERADE udp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 3 MASQUERADE all -- 192.168.122.0/24 !192.168.122.0/24 Chain OUTPUT (policy ACCEPT) num target prot opt source destination ... But, after system-config-firewall is run, it will blow away all the iptables rules created by libvirt. # system-config-firewall # service iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21 5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 6 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 2 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Libvirt uses transient iptables rules for managing NAT or bridging to virtual
machine guests. Any external command that reloads iptables state from scratch,
such as running system-config-firewall, will overwrite the entries needed by
libvirt.
> * Consequence
> What happens when the bug presents.
Guest VMs can no longer access the network, because the traffic is being
dropped by iptables rules that are too strict.
> * Workaround
> What actions, if any, reduce the bug’s effects or prevent it from
> presenting
> entirely.
After running any command that might change iptables state, such as
system-config-firewall, follow up with the command 'service libvirt reload' to
restore libvirt's additional iptables rules.
> * Result
> If the bug’s effect is only reduced, what consequences still flow;
> if the bug is prevented, what restrictions does the workaround impose.
Should be no restrictions - anyone with enough privileges to run
system-config-firewall also has enough privileges to run service libvirt
reload.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1,27 +1 @@
-Libvirt uses transient iptables rules for managing NAT or bridging to virtual
+Libvirt uses transient iptables rules for managing NAT or bridging to virtual machine guests. Any external command that reloads iptables state ( such as running system-config-firewall) will overwrite the entries needed by libvirt. Consequently, after running any command or tool that changes the state of iptables, guests may lose access the network. To work around this issue, use the command 'service libvirt reload' to restore libvirt's additional iptables rules.-machine guests. Any external command that reloads iptables state from scratch,
-such as running system-config-firewall, will overwrite the entries needed by
-libvirt.
-
-> * Consequence
-> What happens when the bug presents.
-
-Guest VMs can no longer access the network, because the traffic is being
-dropped by iptables rules that are too strict.
-
-> * Workaround
-> What actions, if any, reduce the bug’s effects or prevent it from
-> presenting
-> entirely.
-
-After running any command that might change iptables state, such as
-system-config-firewall, follow up with the command 'service libvirt reload' to
-restore libvirt's additional iptables rules.
-
-> * Result
-> If the bug’s effect is only reduced, what consequences still flow;
-> if the bug is prevented, what restrictions does the workaround impose.
-
-Should be no restrictions - anyone with enough privileges to run
-system-config-firewall also has enough privileges to run service libvirt
-reload.
Just noticed a typo in the recommended workaround for the problem...
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1 +1 @@
-Libvirt uses transient iptables rules for managing NAT or bridging to virtual machine guests. Any external command that reloads iptables state ( such as running system-config-firewall) will overwrite the entries needed by libvirt. Consequently, after running any command or tool that changes the state of iptables, guests may lose access the network. To work around this issue, use the command 'service libvirt reload' to restore libvirt's additional iptables rules.+Libvirt uses transient iptables rules for managing NAT or bridging to virtual machine guests. Any external command that reloads iptables state ( such as running system-config-firewall) will overwrite the entries needed by libvirt. Consequently, after running any command or tool that changes the state of iptables, guests may lose access the network. To work around this issue, use the command 'service libvirtd reload' to restore libvirt's additional iptables rules.
In RHEL 7 libvirt now uses firewalld which preserves firewall rules added by libvirt even through restarts: [root@winston ~]# iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE tcp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 MASQUERADE udp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 MASQUERADE all -- 192.168.122.0/24 !192.168.122.0/24 [root@winston ~]# systemctl restart firewalld [root@winston ~]# iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE tcp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 MASQUERADE udp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 MASQUERADE all -- 192.168.122.0/24 !192.168.122.0/24 I'm marking this as test-only and moving back to 7.0 as it's already fixed. According to Comment 30 from Peter, I tested it on RHEL-7.0-20140326.0, and iptables rules can get back after restarted firewalld. And the guest can ping to the target outside. # iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE tcp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 MASQUERADE udp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 MASQUERADE all -- 192.168.122.0/24 !192.168.122.0/24 # systemctl restart firewalld # iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE tcp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 MASQUERADE udp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 MASQUERADE all -- 192.168.122.0/24 !192.168.122.0/24 MASQUERADE tcp -- 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535 The only different is there is redundant rule for tcp MASQUERADE of 192.168.122.0/24. But it not affect this virtual network. Seen Comment 31,and i also get the same result,so set it as verified. This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |