WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] unpredictible multiple bridge behaviour.

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] unpredictible multiple bridge behaviour.
From: "Chris Fanning" <christopher.fanning@xxxxxxxxx>
Date: Wed, 21 Mar 2007 18:25:43 +0100
Delivery-date: Wed, 21 Mar 2007 10:24:49 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sAdSm6blo1+XO41MijnYnUTzAtbMa94dU75oMJE5arCml+pcTr/CuNICIeHbnv/VKTlI9uOd+xkVpX5D7PvvuM4P+IkOAsDMfNhtmIF1ISjGMjYGw4e282csIcFcAeUx42AWjJ+mtxf7g+Jd62cEFQMiwGQguFCj4szCJdpDwU0=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X1HHfrNFTtEypykDAArHrmP7CtTiKpbCouSeB5naHWe0zz/w18cvWykY1VfF1f5w81dEcdmhv57DEmVyMr4Dp73iNRWzoXOEiMuTybishnT7iMl/S/SiSsL6PWEvyk9bOifM7Al7dhIpW6oW7lxsxABNOuUB9QRvIV764PY79ZM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070321182447.GA30168@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <215ff4410703210841p160f9e3ag3a0deb07eca121c1@xxxxxxxxxxxxxx> <20070321182447.GA30168@xxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

you can work around the problem by specifying static mac addresses
and using a bit of udev magic in domU.

Yep, that did it.
Still, I wonder why this had never been a problem before upgrade.

Thanks,
Chris.

On 3/21/07, jez <jez@xxxxxxxxxx> wrote:
On Wed, Mar 21, 2007 at 04:41:30PM +0100, Chris Fanning wrote:
> Hi,
>
> I'm using two bridges.
> Since upgrading from 3.0-2 to 3.0-4 the vif's are randomly
> interchanged when passed to domU.
>
> sometimes vif1.0 gets assigned to eth0 and vif1.1 to eth1 on domU
> sometimes vif1.1 gets assigned to eth0 and vif1.0 to eth1 on domU
>
> I've tried two 'my-network-bridge' scripts.
>

Hi Chris

Assuming that the output of "brctl show" (ignoring the bridge-id
field), looks like this:

   bridge name     bridge id               STP enabled     interfaces
   xenbr0          8000.feffffffffff       no              vif0.0
                                                           peth0
   xenbr1          8000.feffffffffff       no              vif0.1
                                                           peth1

then you don't need to worry about the bridge building script you are
running.

I have no idea why your vif interfaces are being assigned randomly to
eth interfaces in your domUs, but a quick test here suggests that
you can work around the problem by specifying static mac addresses
and using a bit of udev magic in domU. The following are instructions
on how to acheive this.

1. In the configuration file for a domU, specify a static mac address
   and a bridge for each interface as follows:

   vif = [ 'mac=00:16:3e:00:00:11, bridge=xenbr0',
           'mac=00:16:3e:00:00:22, bridge=xenbr1' ]

   Make sure you put commas in all the right places.

2. Then inside the domU create a file called /etc/udev/vm-local.rules
   and put the following in it:

     SUBSYSTEM=="net", ATTRS{address}=="00:16:3e:00:00:11", NAME="eth0"
     SUBSYSTEM=="net", ATTRS{address}=="00:16:3e:00:00:22", NAME="eth1"

3. Now just add a symlink to the udev rules directory so that your
   rules file, vm-local.rules, is processed before all the other rules
   files. The following works on my distro:

      cd /etc/udev/rules.d
      ln -s ../vm-local.rules  010_vm-local.rules

   Make sure that your symlink ends in ".rules" or it will be ignored.

Now, every time you start this domU, udev should ensure that eth0 and
eth1 are always the same devices.

Probably not the answer you were hoping for, but hopefully it helps.

jez


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


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