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

[Teck Choon Giam <giamteckchoon@xxxxxxxxx>]

On Tue, May 3, 2011 at 1:51 AM, Digimer <linux@xxxxxxxxxxx> wrote:
> 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.

So can you verify that for your xenbr2 those vif/tap are ending with
{vif,tap}Y.2 instead of {vif,tap}Y.1?  That is why I am asking for
your brctl show output :p

One thing though, if doing anything related to HVM... ... tap/vif
related devices might be created slightly slower (sorry, can't
remember if is vif or tap)... as xen created vif as well regardless
you are using HVM which using tap devices.  This is something that
caught me when I create patch to support tap devices if antispoofing
is enabled.  (sorry for this off-topic)... ...

Your qemu-ifup patch especially the below line:

pdev=`echo $1 | sed -e "s/^tap\(.*\)$/eth\1/"`

If I read correctly, you are trying to convert tapN to ethN right?  I
can't remember xen <=3.1 naming for tap/vif devices... if it is
{tap/vif}N then it is fine but for xen4, tap/vif naming is
{tap/vif}Y.N though so your above patch will have issue in xen4 or
xen3.4 I think as you will get tap3.1 to eth3.1 instead of eth1... ...
I think it is {tap/vif}N mostly for xen <=3.1 and sorry I got bad
memory about different version of xen about the naming change in
vif/tap devices.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users