[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] unpredictible multiple bridge behaviour.
On Wed, Mar 21, 2007 at 06:25:43PM +0100, Chris Fanning wrote: > 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. > The problem might actually spring from udev on domU. On my debian systems it keeps a record of mac -> eth mappings in a generated udev rules file called /etc/udev/rules.d/z25_persistent-net.rules. When I started switching between using both Xen and UML with the same filesystem images I ran into eth naming problems - specifically, eth0 incremented it's interface number by one each time I booted (eth1, eth2, eth3 ...). The problem had something to do with the different ways that mac addresses were generated. I haven't had time to look into it properly. I put the following in my vm-local.rules file, which solves things for me: KERNEL=="eth*", NAME="%k" I didn't recommend this to you because your symtoms are obviously different. However, you might want to try it since it has the advantage that you can use domU config files without static macs: vif = [ 'bridge=xenbr0', 'bridge=xenbr1' ] In short, it's conceivable that the algorithm used to generate mac addresses changed between Xen versions and that this had an effect because your system had been keeping track of previous mac addresses. If this is the cause, another fix might be to just remove the file containing the generated mac -> eth address mappings if one exists in your system. I don't bother with this because I'm still using the same images for Xen, UML, kvm, etc. I'm sure that clears things up! ;-) jez _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |