All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: help with bugs
@ 2005-08-05  9:12 Ian Pratt
  2005-08-05 13:20 ` Gerd Knorr
  0 siblings, 1 reply; 17+ messages in thread
From: Ian Pratt @ 2005-08-05  9:12 UTC (permalink / raw)
  To: Gerd Knorr; +Cc: xen-devel


> > I'd like to appeal for some help tracking down a couple of 
> bugs that 
> > we're struggling to reproduce:
> > 
> >  BUG62  eth0 -> veth0 in network script can loose network
> 
> I think the only sane way to fix this is to let the 
> distribution tools configure the network.  Thats a bit harder 
> to set up, but works more reliable.  

Yep, having the distro scripts do it always preferable. However, we do
need something that people can use in the interim. 

I guess people would still want the distro scripts to be able to cope
with enabling/disabling xen networking at run time rather than just
configuring it once at boot. 

> Also the "if{up|down} 
> <interface>" commands and the like will work as usual then.  
> Especially in case eth0 is configured via dhcp the ip address 
> copying is a bad idea.  Unfortunaly it isn't very good 
> documented how all this works, especially the new veth0 thing.

I'd be inclined to rename the physical interface to pethN, and create
veth0 as eth0. I think this should solve the DHCP issue.

> IMHO it would be good if the network start script checks 
> whenever any bridges are already present in the system and 
> don't touch the network setup if that is the case.  That 
> should catch both network setup being already done by the 
> distro start scripts or by an earlier network setup script 
> run (when xend is restarted).

I believe (hope?) it already copes wih xend restart.
If you're using distro or other scripts then you can disable it from
xend-config.sxp.

> The setup I'm running looks like this (classic 2.x setup, no 
> veth0/vid0.0 used), in boot.local:
> 
> 	ip link set eth0 name hw-eth0
> 	brctl addbr eth0
> 	brctl addif eth0 hw-eth0
> 	ip link set hw-eth0 up
> 	ip link set eth0 up
> 
> Then let the network scripts setup eth0 (now a bridge) as 
> usual and tell xend that "eth0" is the bridge device it 
> should add the vif interfaces to.

So you don't use veth0? This is dangerous if you run services in dom0
that are being used by the domUs.

Ian

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: help with bugs
@ 2005-08-10 18:39 Ian Pratt
  2005-08-10 19:00 ` Nivedita Singhvi
  0 siblings, 1 reply; 17+ messages in thread
From: Ian Pratt @ 2005-08-10 18:39 UTC (permalink / raw)
  To: Nivedita Singhvi, Gerd Knorr; +Cc: xen-devel

 
> Unfortunately, we might not be able to do this (we do not 
> want to force a rename of the physical device). Looking into this...

See the new network script I posted yesterday. Works fine for me on a
number of different boxes.

Ian

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: help with bugs
@ 2005-08-05 14:22 Ian Pratt
  0 siblings, 0 replies; 17+ messages in thread
From: Ian Pratt @ 2005-08-05 14:22 UTC (permalink / raw)
  To: Gerd Knorr; +Cc: xen-devel

> Hmm, just an idea, not sure how well that would work in 
> practice, maybe the network script should not even attempt to 
> copy the ip addresses, but instead use ifup and ifdown, i.e.
> something like this:

Do you think ifup/ifdown will do the right thing with the interface name
changed underneath them?

If so, that's a good soloution and we should adopt it. Please can
someone try?

Thanks,
Ian 
 
> 	ifdown eth0
> 	ip link set eth0 name peth0
> 	ip link set veth0 name eth0
> 	brctl addbr xen-br0
> 	brctl addif xen-br0 peth0
> 	brctl addif xen-br0 vif0.0
> 	ip link set peth0 up
> 	ip link set vif0.0 up
> 	ip link set xen-br0 up
> 	ifup eth0
> 
> At least suse, fedora and debian have ifup and ifdown to 
> control interfaces, not sure about others ...
> 
> > So you don't use veth0?
> 
> No.  Partly because it's not entriely clear to me how the 
> setup should look like (hope I got it right above), partly 
> because the same setup works for both xen2 and xen3 then.  
> And, no, I don't run services for the domUs on dom0 ...
> 
>   Gerd
> 
> --
> panic("it works"); /* avoid being flooded with debug messages */
> 

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: help with bugs
@ 2005-08-04 21:48 Ian Pratt
  2005-08-04 22:21 ` Sean Dague
  0 siblings, 1 reply; 17+ messages in thread
From: Ian Pratt @ 2005-08-04 21:48 UTC (permalink / raw)
  To: Sean Dague; +Cc: xen-devel

> >  BUG62  eth0 -> veth0 in network script can loose network
> I can make this bug come and go at will based on which of the 
> 2 network interfaces are part of the bridge.  I added that 
> information into the bugzilla bug, hopefully that helps.

Are you changing the default 'netdev' at the top of the network script?

I take it that if you try and get it to work on eth1 it fails?

BTW: I'd like to see a few changes in the way this stuff works anyhow.

Firstly, rename network to network-bridge.

Next, I'd make it such that it's possible to have multiple
network-script lines, each with parameters e.g. something like:

(network-script ( network-bridge ( bridge xen-br0 ) ( netdev eth0 ) ) )
(network-script ( network-bridge ( bridge xen-br1 ) ( netdev eth1 ) ) )

[having multiple interfaces should result in multiple vif0.x and vethX
devices]

And then the vif-script along with default parameters e.g.

( vif-script ( vif-bridge ( bridge xen-br0 ) ( antispoof no ) ) )

Do others agree?
Could someone work up a patch?

Thanks,
Ian

 

^ permalink raw reply	[flat|nested] 17+ messages in thread
* RE: help with bugs
@ 2005-08-04 21:02 Ian Pratt
  2005-08-04 21:29 ` David F Barrera
  0 siblings, 1 reply; 17+ messages in thread
From: Ian Pratt @ 2005-08-04 21:02 UTC (permalink / raw)
  To: David F Barrera; +Cc: xen-devel

> >I'd like to appeal for some help tracking down a couple of bugs that 
> >we're struggling to reproduce:
> >
> > BUG62  eth0 -> veth0 in network script can loose network
> >  
> >
> I've been able to reproduce this problem frequently on SLES 9 
> SP2 based platforms, x86 and x86_64. It seems that when I 
> first reported the problem it happened very infrequently, and 
> I could not reliably reproduce it. Now, I seems to be 
> happening all the time on my SLES 9 boxes; curiously, it does 
> not seem to happen on my FC/RH boxes.

Is there anything unusal about the SLES9 setup, e.g. multiple phsical
interfaces, alias addresses on interfaces etc?

Have you tried my suggestion of adding 'promisc' to the ifconfig up
lines in the script?

Thanks,
Ian

^ permalink raw reply	[flat|nested] 17+ messages in thread
* help with bugs
@ 2005-08-04 15:04 Ian Pratt
  2005-08-04 19:53 ` Anthony Liguori
                   ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Ian Pratt @ 2005-08-04 15:04 UTC (permalink / raw)
  To: xen-devel



I'd like to appeal for some help tracking down a couple of bugs that
we're struggling to reproduce:

 BUG62  eth0 -> veth0 in network script can loose network
 BUG130 time running fast bug
 BUG76  shared irq's fail under high load

These are all pretty serious and it would be good to get fixed before
3.0-testing-r1 

If you can make them exhibit frequently on your system it would be
useful to know.

Thanks,
Ian

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2005-08-10 19:00 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-05  9:12 help with bugs Ian Pratt
2005-08-05 13:20 ` Gerd Knorr
2005-08-10 18:38   ` Nivedita Singhvi
  -- strict thread matches above, loose matches on Subject: below --
2005-08-10 18:39 Ian Pratt
2005-08-10 19:00 ` Nivedita Singhvi
2005-08-05 14:22 Ian Pratt
2005-08-04 21:48 Ian Pratt
2005-08-04 22:21 ` Sean Dague
2005-08-04 21:02 Ian Pratt
2005-08-04 21:29 ` David F Barrera
2005-08-04 21:55   ` Paul Larson
2005-08-05  3:10     ` David F Barrera
2005-08-04 15:04 Ian Pratt
2005-08-04 19:53 ` Anthony Liguori
2005-08-04 20:18 ` Sean Dague
2005-08-04 20:49 ` David F Barrera
2005-08-05  8:29 ` Gerd Knorr

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.