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

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


  • To: Digimer <linux@xxxxxxxxxxx>
  • From: Teck Choon Giam <giamteckchoon@xxxxxxxxx>
  • Date: Sun, 1 May 2011 08:47:09 +0800
  • Cc: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sat, 30 Apr 2011 18:20:12 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V5tFnb7aYdBHcKHFHVUZBv+vb2SB4UYYE+R62V8hXT44B8fRJBPBSSBfytHeCw1YGL wHG9A7IJ7yEjDoJbwnef3uEFa9tyvtG1fQlVoDPUOpM3zvUkBbQmYx9w3lcczkow62HX ICUiIBh31uJhdVzOq1rt4xu9C0jyxxabjdlEU=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

On Sun, May 1, 2011 at 5:32 AM, Digimer <linux@xxxxxxxxxxx> wrote:
> On 04/30/2011 03:25 PM, Teck Choon Giam wrote:
>> On Sun, May 1, 2011 at 12:50 AM, Digimer <linux@xxxxxxxxxxx> wrote:
>>> On 04/29/2011 06:26 PM, Teck Choon Giam wrote:
>>>> On Sat, Apr 30, 2011 at 6:08 AM, Digimer <linux@xxxxxxxxxxx> wrote:
>>>>
>>>> (network-script /bin/true)
>>>
>>> That was the ticket. I was able to provision a new VM with two
>>> interfaces, however, the vifs were at MTU 1500 so I still have work to
>>> do. :)
>>
>> Glad to hear that ;)
>>
>> Whereby for MTU... maybe you want to try manually set those?  For example:
>>
>> To get the link of various ip link... ...
>> ip link show
>>
>> Then if you want to set the mtu for vif1.0 for instance... do something like:
>>
>> ip link set dev vif1.0 mtu 1412
>>
>> Of course in your case, vif1.0 or whatever appended with .0 for vif#.0
>> will be your xenbr0/eth0... so you might want to do something like:
>>
>> ip link set dev eth0 mtu 1412 << This can be configure in ifcfg-eth0
>> ip link set dev xenbr0 mtu 1412 << This also can be set in ifcfg-xenbr0
>> ip link set dev vif1.0 mtu 1412
>> ip link set dev vif2.0 mtu 1412
>>
>> OR using ifconfig to set the related interface mtu.
>>
>> so on... ... I don't think this is difficult to find the vif related
>> script in /etc/xen/scripts/ to add in the appropriate link for your
>> desired mtu value... ... IMO.  I think this is vif-common.sh as the
>> below codes:
>>
>> if [ "$type_if" = vif ]; then
>>     # Check presence of compulsory args.
>>     XENBUS_PATH="${XENBUS_PATH:?}"
>>     dev="${dev:?}"
>>
>>     vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "")
>>     if [ "$vifname" ]
>>     then
>>         if [ "$command" == "online" ] && ! ip link show "$vifname" 
>> >&/dev/null
>>         then
>>             do_or_die ip link set "$dev" name "$vifname" << THIS IS
>> WHERE YOU CAN ADD BUT I HAVE NOT EXPLODE THIS NOR TEST THIS WITH
>> APPENDED mtu "$mtu"
>>         fi
>>         dev="$vifname"
>>     fi
>> elif [ "$type_if" = tap ]; then
>>     # Check presence of compulsory args.
>>     : ${INTERFACE:?}
>>
>>     # Get xenbus_path from device name.
>>     # The name is built like that: "tap${domid}.${devid}".
>>     dev_=${dev#tap}
>>     domid=${dev_%.*}
>>     devid=${dev_#*.}
>>
>>     XENBUS_PATH="/local/domain/0/backend/vif/$domid/$devid"
>> fi
>>
>>
>> Something like:
>>
>> do_or_die ip link set "$dev" name "$vifname" mtu "$vifmtu"
>>
>> Or if doesn't work just split to another line:
>>
>> do_or_die ip link set "$dev" name "$vifname"
>> do_or_die ip link set dev "$vifname" mtu "$vifmtu"
>>
>> Or use ifconfig... ...
>>
>> Of course you will need to set $vifmtu somewhere before the above or
>> use a function/line to get its bridge/parent interface name
>> (xenbr0/eth0) mtu value ... ... this is purely talking rubbish from me
>> without testing... just thoughts/ideas :p
>>
>> Example:
>>
>> Get parent/bridge interface mtu value for xenbr0:
>>
>> local vifmtu=`ip link show xenbr0|head -n 1|sed 's@.*\Wmtu\W@@'|sed 
>> 's@\W.*@@'`
>>
>> Or even better way is we know vif#.N where N will be the bridge number:
>>
>> local myxenbrN=`echo $vifname | cut -f2 -d '.'`
>> local myxenbrname="xenbr${myxenbrN}"
>> local vifmtu=`ip link show ${myxenbrname}|head -n 1|sed
>> 's@.*\Wmtu\W@@'|sed 's@\W.*@@'`
>> do_or_die ip link set "$dev" name "$vifname" mtu "$vifmtu"
>>
>> Again, the above are ideas/thoughts without testing at all and I might
>> be totally wrong :p
>>
>> Hope this helps!
>>
>> Thanks.
>>
>> Kindest regards,
>> Giam Teck Choon
>
> Hi Giam,
>
>  This was the approach I took, which resulted in this patch:
>
> https://bugzilla.redhat.com/attachment.cgi?id=495998&action=diff
>
>  The trick with doing it manually is that the bridge's MTU is set to
> the lowest MTU of all attached ifs. So if a new vif comes up at 1500 and
> is then connected to a bridge that had been at 9000, all traffic >1500
> bytes will die on the bridge. So, as you explored, I had to edit the
> userland scripts to up the vif's MTU before it connected to the bridge.
>
>  I'd done this earlier, but it was bugged. While trying to solve that
> new bug, Pasi suggested I take the bridge control out of Xen's control
> and that prompted the experimenting that got me in trouble. :)
>

Pasi is right about to use system network configuration so that xend
and system network are separated.  Can you explain how it was bugged?
Is it sometimes get set and sometimes not?  Have you try to give a
small sleep interval such as 3 seconds before setting the related mtu?

Thanks.

Kindest regards,
Giam Teck Choon

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


 


Rackspace

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