This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] Trouble with manual bridging on Xen3/CentOS 5

To: Teck Choon Giam <giamteckchoon@xxxxxxxxx>
Subject: Re: [Xen-users] Trouble with manual bridging on Xen3/CentOS 5
From: Digimer <linux@xxxxxxxxxxx>
Date: Mon, 02 May 2011 13:51:42 -0400
Cc: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 02 May 2011 10:52:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTi=_wBFxM7nwHcTDGCyyCO7ar49_sA@xxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <4DBB36EA.2030202@xxxxxxxxxxx> <BANLkTimE1YDM86_rYj6PHWqgDyRa1gQoHw@xxxxxxxxxxxxxx> <4DBC3DCE.4060206@xxxxxxxxxxx> <BANLkTi=Gjp7OdfTyF7DE9SVZ3uFn2W5uxA@xxxxxxxxxxxxxx> <4DBC7FE2.8010609@xxxxxxxxxxx> <BANLkTin0YEz0HDvnGYJ4Dt5pWRAGeaR61Q@xxxxxxxxxxxxxx> <4DBCBFB5.7070700@xxxxxxxxxxx> <BANLkTikZFwijVaz-N+i_dWvJKMee7NUsug@xxxxxxxxxxxxxx> <4DBCED01.6050400@xxxxxxxxxxx> <BANLkTikVvssbsifOJqOzzCfyuak_MW5d_Q@xxxxxxxxxxxxxx> <4DBED778.2070008@xxxxxxxxxxx> <BANLkTi=_wBFxM7nwHcTDGCyyCO7ar49_sA@xxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10
On 05/02/2011 01:33 PM, Teck Choon Giam wrote:
> On Tue, May 3, 2011 at 12:10 AM, Digimer <linux@xxxxxxxxxxx> wrote:
>> On 05/02/2011 12:04 PM, Teck Choon Giam wrote:
>>> Ok, mind to show me your brctl show output?  I am curious about what
>>> is the vif?.? assignment to your xenbr2 especially.  It is either
>>> vif?.1 or vif?.2.  Have you tried with vifname set in your domU
>>> configs to see whether the same problem persist?
>>> Thanks.
>> To get that info, I'd need to reconfigure a test cluster with the bugged
>> patch. If it's curiosity only, I'd like to set it aside. If it could
>> help with development though, let me know and I'll do so tonight.
> Curious only though but that might helps to determine one or more of
> your patches issue.  One of your patch at least is using vif?.N to get
> its physical ethN if I am not mistaken:
> https://bugzilla.redhat.com/attachment.cgi?id=492964&action=diff

That patch is now outdated, and was the one with the flaw.

> pdev=`echo $dev | sed -e "s/^vif\(.*\)\.\(.*\)$/peth\2/"`
> So if $dev is vif?.N here, the pdev will be pethN right?  However,
> since you are using system network configuration to configure your
> bridge, your physical ethN remain the same as it is and there isn't
> any pethN here I believe.  Correct me if I am wrong though :p

peth=pethN, yes. At the time though, I was /not/ configuring the xenbrX
devices in the system, I was letting Xen do it. When Xen does it, that
is when the 'pethX' devices were created. Now that I am using
system-built bridges, pethX devices no longer exist.

> And your next line is:
> mtu=`cat /sys/class/net/$pdev/mtu`
> So if $pdev not set or empty or pethN not found, you will have issue here... 
> ...

Exactly, however, $pdev was set to 'peth1' when the vif was about to be
connected to xenbr2. The results were the same; The script failed, but
the cause was different (the xenbr2 <-> peth1 mapping).

> Now let said you are using xen provided to do the bridging instead of
> using system network configuration... so pethN will be set by xen or
> rename real ethN to pethN and setup bridge name as ethN if I remember
> correctly... ... now if vif?.N where N is 1 for your xenbr2/peth2 you
> will have issue as well :p


> You might want to try setting vifname for your testing domU config to
> see whether does it resolve your issue?
> I haven't look closely for your other patches though and what I stated
> above hopefully make sense :p
> Thanks.
> Kindest regards,
> Giam Teck Choon

I was able to make it work with a slight modification to a suggestion
that Paolo gave me on IRC:


The change was that, at this point in the xen-network-common[-bonded].sh
scripts, the 'vif' special file didn't exist, so I directly grabbed the
MTU of the bridge instead. So far, this seems to be the winner. Testing
will tell if there are new/remaining issues.

E-Mail: digimer@xxxxxxxxxxx
AN!Whitepapers: http://alteeve.com
Node Assassin:  http://nodeassassin.org

Xen-users mailing list