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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:> BUG76 shared irq''s fail under high load > >I can repro this very easily. If there''s anything I can do to help track this down let me know. Regards, Anthony Liguori>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 > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Aug 04, 2005 at 04:04:34PM +0100, Ian Pratt wrote:> > > 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 networkI 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.> 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 > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:>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.> 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 > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sean Dague wrote:> On Thu, Aug 04, 2005 at 04:04:34PM +0100, Ian Pratt wrote: > >> >>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 networkYep, working on this one. --Nivedita I didn''t see your original mail, so not sure if you listed any others - but was workin on 103 which seems to have gone awayin current code (we''re trying to narrow it to the NET GRANT code (not yet confirmed).> 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.>> BUG130 time running fast bug >> BUG76 shared irq''s fail under high load >>thanks, Nivedita _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2005-08-04 at 13:49 -0700, Nivedita Singhvi wrote:> Sean Dague wrote: > > > On Thu, Aug 04, 2005 at 04:04:34PM +0100, Ian Pratt wrote: > > > >> > >>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 > > Yep, working on this one. --Nivedita > > I didn''t see your original mail, so not sure if you listed > any others - but was workin on 103 which seems to have gone > awayin current code (we''re trying to narrow it to the > NET GRANT code (not yet confirmed).Niv, the NETDEV GRANT code is not enabled in the x86-64 Dom0 kernel. So that should not be the cause.> > > 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. > > > >> BUG130 time running fast bug > >> BUG76 shared irq''s fail under high load > >> > > thanks, > Nivedita > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- Jerone Young IBM Linux Technology Center jyoung5@us.ibm.com 512-838-1157 (T/L: 678-1157) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jerone Young wrote:>>any others - but was workin on 103 which seems to have gone >>awayin current code (we''re trying to narrow it to the >>NET GRANT code (not yet confirmed). > > > Niv, the NETDEV GRANT code is not enabled in the x86-64 Dom0 kernel. So > that should not be the cause.It was accidentally enabled, we had thought, actually. But yes, it''s possibly unrelated. thanks, Nivedita _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:>>>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? > >No, nothing unusual. In fact, in one case, I have a machine that has both SLES 9 and FC3. When I build Xen on SLES 9 and boot Dom0, I can recreate the problem. On the same machine, when I build Xen on FC3 and boot Dom0, the problem does not occur. I built Xen the same way in both instances; the setups are the same with regards to Xen, the only variable (and a big one) is the distro.>Have you tried my suggestion of adding ''promisc'' to the ifconfig up >lines in the script? > >Yes, and the problem still occurred.>Thanks, >Ian > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2005-08-04 at 16:29 -0500, David F Barrera wrote:> > Ian Pratt wrote: > > >>>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? > > > > > No, nothing unusual. In fact, in one case, I have a machine that has > both SLES 9 and FC3. When I build Xen on SLES 9 and boot Dom0, I can > recreate the problem. On the same machine, when I build Xen on FC3 and > boot Dom0, the problem does not occur. I built Xen the same way in both > instances; the setups are the same with regards to Xen, the only > variable (and a big one) is the distro.David, is this one of the boxes that has to use eth1 instead of eth0? I have some like this and haven''t seen the problem you describe, even with SLES9, so I don''t know if either of those is important to the problem. -- Thanks, Paul Larson plars@linuxtestproject.org http://www.linuxtestproject.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I didn''t see your original mail, so not sure if you listed > any others - but was workin on 103 which seems to have gone > awayin current code (we''re trying to narrow it to the NET > GRANT code (not yet confirmed).NET_GRANT is currently disabled by default because bugs were revealed when we tried to enable it. Steve Hand is looking into this. Best, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Aug 04, 2005 at 10:48:50PM +0100, Ian Pratt wrote:> > > 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?No actually, I guess I''m not even clear why veth0 exists, as everything works quite nicely for me without it functioning. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On Thu, Aug 04, 2005 at 10:48:50PM +0100, Ian Pratt wrote: > > > > 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? > > No actually, I guess I''m not even clear why veth0 exists, as > everything works quite nicely for me without it functioning.If you''re running services in dom0 that are used by other domains you are liable to get head-of-line blocking or even deadlock of the domU''s networking unless you use veth0: all of the domU''s skb''s could end up getting queued in dom0 socket buffers. veth0 avoids this by copying packets destined for dom0 and giving the buffer back to the domU. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nivedita Singhvi
2005-Aug-05 00:07 UTC
[PATCH] network -> network-bridge rename WAS: Re: [Xen-devel] RE: help with bugs
Ian Pratt wrote:> BTW: I''d like to see a few changes in the way this stuff works anyhow. > > Firstly, rename network to network-bridge.Ian, I had started something along these lines. Just for grins, resubmitting a freshly regenerated patch that just does above.> Next, I''d make it such that it''s possible to have multiple > network-script lines, each with parameters e.g. something like:I started this - but it became less than desirable to stick all of this into xend. That is, what I was thinking was - we simply point the tools to a configuration file that''s a top level script, and hide all of the meat of the work inside those scripts. If we change the syntax, we wouldn''t require a change to the tools, would be one advantage.> (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?Or we could do the above.. Signed-off-by: Nivedita Singhvi (niv@us.ibm.com) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Paul Larson wrote:>On Thu, 2005-08-04 at 16:29 -0500, David F Barrera wrote: > > >>Ian Pratt wrote: >> >> >> >>>>>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? >>> >>> >>> >>> >>No, nothing unusual. In fact, in one case, I have a machine that has >>both SLES 9 and FC3. When I build Xen on SLES 9 and boot Dom0, I can >>recreate the problem. On the same machine, when I build Xen on FC3 and >>boot Dom0, the problem does not occur. I built Xen the same way in both >>instances; the setups are the same with regards to Xen, the only >>variable (and a big one) is the distro. >> >> >David, is this one of the boxes that has to use eth1 instead of eth0? I >have some like this and haven''t seen the problem you describe, even with >SLES9, so I don''t know if either of those is important to the problem. > >No, this box only has one nic, eth0. I should point out that my machines have SLES 9 *SP2*, the latest GA version of SLES 9. Come to think of it, the problem did not happen on it when it was just SLES 9. Can you update your system to SLES 9 SP2?> > >------------------------------------------------------------------------ > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> writes:> 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 networkI 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. 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. 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). 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. cheers, Gerd -- panic("it works"); /* avoid being flooded with debug messages */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Aug 05, 2005 at 12:48:33AM +0100, Ian Pratt wrote:> > On Thu, Aug 04, 2005 at 10:48:50PM +0100, Ian Pratt wrote: > > > > > 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? > > > > No actually, I guess I''m not even clear why veth0 exists, as > > everything works quite nicely for me without it functioning. > > If you''re running services in dom0 that are used by other domains you > are liable to get head-of-line blocking or even deadlock of the domU''s > networking unless you use veth0: all of the domU''s skb''s could end up > getting queued in dom0 socket buffers. > > veth0 avoids this by copying packets destined for dom0 and giving the > buffer back to the domU.Is there a test case for this? I''ve been running some services in dom0 and apparently running without veth0 for quite some time. It would be good to have a test that shows this problem. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I''d be inclined to rename the physical interface to pethN, and create > veth0 as eth0. I think this should solve the DHCP issue.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: 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 */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > If you''re running services in dom0 that are used by other > domains you > > are liable to get head-of-line blocking or even deadlock of > the domU''s > > networking unless you use veth0: all of the domU''s skb''s > could end up > > getting queued in dom0 socket buffers. > > > > veth0 avoids this by copying packets destined for dom0 and > giving the > > buffer back to the domU. > > Is there a test case for this? I''ve been running some > services in dom0 and apparently running without veth0 for > quite some time. It would be good to have a test that shows > this problem.I haven''t tried this, but I suspect it would work: * run a ttcp receiver in dom0 with a very large socket buffer size * connect to it with a ttcp transmitter in domU (again, large sock buffer) * with data in flight, ^Z the dom0 receiver I''d expect to see the ntworking of the domU (and potentially other domU''s) start to run very slowly or even grind to a halt. You may need multiple parallel tcp connections to trigger this. Using UDP makes it happen much more easily. If you''re using veth0 you shouldn''t have the problem. [There are plans for making the backend buffer management more dynamic that would mitigate the effect on other domU''s, but this wouldn''t completely obviate the need for veth0 as a single domU could still end up with all of its buffers being held by dom0. There''s a partial fix for TCP (not UDP) whereby we have dom0 release it''s mapping of the domU buffer as soon as its sent the TCP ACK, rather than when it finally frees the skb when the client reads it. Possibly the cleanest option would be to add a hook in the local receive path that would enable us to copy&unmap any packets destined for local delivery. Anyhow, not for 3.0.0 ...] Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/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 */ >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Gerd Knorr wrote:>>I''d be inclined to rename the physical interface to pethN, and create >>veth0 as eth0. I think this should solve the DHCP issue. > > > 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: > > 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 eth0Unfortunately, we might not be able to do this (we do not want to force a rename of the physical device). Looking into this... thanks, Nivedita> 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:>>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, yup, will have feedback by tmrw. thanks, Nivedita _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel