[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.