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
|
Home