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

Re: [Xen-devel] Network still broken, new issue as well , 7468:17a9f111fa93

I have to run a very old changeset just to boot my SMP dom0, opened up a
bug on this a few days ago. Ever since version started showing
up. Have tried many changesets with no joy. On my UP machine things
behave better in general, matter of fast I have a domU up for almost 5
days now with only minor issues on the UP P4 test box, but the
networking testing is limited by the APCI issues.


I can understand the issues with configs and the points are valid. My
experience in the past has taught me that stricter configs actually lead
to less human error, less bugs in the code,  and less ghost chasing by
all parties involved, which in turn leads to higher productivity in

I intentionally throw lots of variations in my configs for the purpose
of learning and testing, it is a double edged sword to be sure.


On Tue, 2005-10-25 at 18:40 +0100, Ewan Mellor wrote:
> On Fri, Oct 21, 2005 at 10:26:30PM -0400, Ted Kaczmarek wrote:
> > I see 2 vifs for a domU that has nics = 1 , this happens on 4 out of 10
> > domU's. grepping my configs make me think that something has changed the
> > way they are interpreted, all the the domU's using mac, bridge have 2
> > vifs, where the one that ony have mac declared have 1 vif.
> > 
> > [Snip nics]
> >
> >  grep vif idom*
> > idom1:vif = ['mac=AA:00:00:00:00:17','bridge=xen-br0']
> > [Snip]
> > idom10:vif = [ 'mac=AA:00:00:00:01:08, bridge=xen-br0' ]
> Here, idom1 is declared using two strings, but idom10 is declared using just
> one.  I'm guessing a little here, but from reading the code it looks like this
> means that idom1 has two vifs, one with a default bridge and the given MAC,
> and one with a random MAC and the given bridge, whereas idom10 has one vif,
> with the given MAC and bridge.
> I think this is fairly sensible behaviour.  Whether it is a regression or not,
> I'm not sure.  It might actually have been a long-standing bug that has been
> masked by other long standing bugs, and now we're doing things as intended.
> The vifs= setting seems to only apply if the number of entries in vif= is less
> than the number specified in vifs=.  In that case, the rest of the vifs are
> created, with default details.  This is fairly barbaric, as you've found out.
> We probably ought to have a "extra_vifs" setting or something, to make it
> clear that they are separate from those configured using vif= and to make it
> clear that this number is not a limit, to avoid the kind of confusion you've
> suffered.
> That said, I'm pushing back on configuration file format changes at the
> moment, because we are trying to stabilise for release, and though the format
> is pretty hideous, many people have stable configurations now, and I don't
> want to break them without strong justification.
> > idom5:vif = ['mac=AA:00:00"00"01:04' , 'bridge=xen-br0']
> This MAC has quotation marks in it.  Lord only knows what that does, but it
> can't be doing what you want, so I'd fix that ;-)
> Regarding your other network problems, if you are still suffering once you've
> changed your configuration, then please submit a full set of logs.  The
> scripts involved have changed recently, as you know, but they are very
> difficult to test, because we don't have a great variation of network
> topologies available.  I'd be looking for
> ifconfig
> brctl show
> cat /var/log/syslog
> cat /var/log/debug
> cat /var/log/xend.log
> Ewan.

Xen-devel mailing list



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