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
Bingo.
> 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:
https://bugzilla.redhat.com/attachment.cgi?id=496016&action=diff
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.
--
Digimer
E-Mail: digimer@xxxxxxxxxxx
AN!Whitepapers: http://alteeve.com
Node Assassin: http://nodeassassin.org
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home