Bug 503043

Summary: xm create fails to add vif PHYSDEV match rules for a domU with multiple network interfaces
Product: Red Hat Enterprise Linux 5 Reporter: Jiri Denemark <jdenemar>
Component: iptablesAssignee: Thomas Woerner <twoerner>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: medium    
Version: 5.4CC: jdenemar, tao, xen-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 460410 Environment:
Last Closed: 2013-03-22 13:39:47 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 Jiri Denemark 2009-05-28 13:49:45 UTC
+++ This bug was initially created as a clone of Bug #460410 +++

Description of problem:
When a domU is configured to have multiple network interfaces, it may fail to create the iptables rules to allow each of the domU's interfaces to bridge the dom0's firewall.

It seems to be a resources issue with iptables and the Xen scripts for networking - multiple network interfaces means that the iptables command is run in a very quick sequence or even concurrently to add vif PHYSDEV match rules resulting in resource contention.

Version-Release number of selected component (if applicable):


How reproducible:
A domU with 2 network interfaces I observed the problem 50% of the time.
A domU with 3 network interfaces I observed the problem 100% of the time 

Steps to Reproduce:
1. Set up a domU guest with more than one network interface - for example edit the /etc/xen/domuGuest  file and add line :
vif = [ '', '', '' ]

2. Start the domU with xm create 

  
Actual results:

After starting the domU we observe the iptables firewall rules :

ACCEPT     all  --  anywhere             anywhere            PHYSDEV match --physdev-in vif1.0
ACCEPT     all  --  anywhere             anywhere            PHYSDEV match --physdev-in vif1.1

And in the /var/log/messages we see:

iptables -A FORWARD -m physdev --physdev-in BLAH BLAH -j ACCEPT failed.
If you are using iptables, this may affect networking for guest domains.

If we strace the iptables command itself we see:

5087  setsockopt(3, SOL_IP, 0x40 /* IP_??? */, "filter.., 3840) = -1 EAGAIN (Resource temporarily unavailable)
5087  write(2, "iptables: Unknown error 18446744073709551615n", 45) = 45
5087  exit_group(1)                     = ?

Expected results:
We should see the xm create command for the domU run completely, create the domain and the PHYSDEV match rules for each vif should be present. Also no errors in /var/log/messages  

Additional info:

A patch to resolve the problem is attached. I adds a simple locking mechanism around the iptables command as it is run by the xen network scripts. It ensures that the iptables commands are  run one at a time.

--- Additional comment from mkearey on 2008-08-28 01:40:32 EDT ---

Created an attachment (id=315173)
patch to resolve iptables contention in xen network scripts

--- Additional comment from jdenemar on 2009-05-27 12:34:33 EDT ---

It's actually a bug in iptables, IMHO. If you run something like

for ((i=0;i<100;i++)); do iptables -A FORWARD -m physdev --physdev-in vif7.$i -j ACCEPT & done

quite a few of the calls will fail. Should we clone this bug for iptables?

Anyway we can easily workaround it by serializing iptables calls...

--- Additional comment from jdenemar on 2009-05-27 12:42:11 EDT ---

Created an attachment (id=345650)
Serialize iptables calls in hotplug scripts

Comment 1 Thomas Woerner 2013-03-22 13:39:47 UTC
Concurrent ip*tables and ebtables calls will lead to resource temporarily unavailable. All of these calls need to be serialized. Closing AS WONTFIX.