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