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

Re: [Xen-devel] XEN - networking and performance



On Wed, 2011-10-12 at 05:50 +0100, D. Duckworth wrote:
> > auto lo
> > iface lo inet loopback
> >
> > auto switch
> > iface switch inet static
> >       address 192.168.101.16
> >       netmask 255.255.255.0
> >       gateway 192.168.101.1
> >       bridge_ports eth2
> >
> > And just use that 'bridge=switch' in all my configuration. And that
> > seems to work just fine - wouldn't that be best way of providing
> > the first network setup to users? I would think the majority of
> folks
> > do something akin to this?
> 
> Well I said a lot of things but not that it's broken. :) Not that I
> couldn't, though. The above stuff works in Debian, but Arch Linux has
> no ifup, neither does bsd. 

If you know how to setup a bridge on those systems please could you
update http://wiki.xen.org/xenwiki/HostConfiguration/Networking to add
links to the relevant Arch / BSD documentation. A couple of simple
examples for the most common case would also be useful.

> So those maintainers have to port Xen's code with patches making it
> time expensive (and painfully dull). Instead the whole routine that
> removes interfaces, adds new bridges, sets iptables, etc. should
> simply be deleted.

We agree and this is why with the xl toolstack we do not support the use
of these scripts or ever call out to them automatically (they haven't
actually been deleted, since xend still uses them). With xl we recommend
that folks use their distribution provided mechanisms to setup the host
network configuration. 

We made some attempt mitigate the network-* insanity for xend users, by
making it such that the script will only do the mad things if it is
(heuristically) detected that the admin hasn't already set something up
themselves, it's not clear how effective this strategy was in practice,
even better is to just comment out the relevant line in your
xend-config.sxp IMHO. Hopefully it is explained below why we aren't
doing any wholesale reworking of how xend does things.

None of that really addresses the complexity of the existing vif-*
scripts. I suspect that deprecating the network-* ones for xl has
effectively deprecated all but the vif-bridge one since e.g. vif-nat
depends quite heavily on the setup which network-nat has done.

There is probably scope for providing a much simpler vif-bridge script
for use with xl, the existing one does have some odd stuff in it.

For more complex scenarios like nat etc there is certainly value in
having examples of how people have done stuff and as James suggested
we'd certainly like to see people posting (or writing up on the wiki)
their own configurations and scripts etc.

> One question that has been bugging me is the xm/xl thing. What are the
> exact plans, will xl indeed be phased in while xm will be phased out
> and what will/won't be supported by xl? Or did I misinterpret it. Imho
> a suggestion to switch over should only be come out when xl becomes
> 'distribution-grade stable'.

xend has been effectively unmaintained for several releases now and
there is nobody who is willing to step up and support it. Unless someone
steps up as a maintainer it will become more deprecated with time and in
a few releases I expect it will be removed from the tree.

On the other hand we are actively developing xl and supporting it.

In 4.1 we recommended that people try xl and report the bugs and missing
features which would prevent them from transitioning from xend. We are
doing our best to address these bugs and short-comings as they are
reported to us. It is our hope that we can fully recommend xl in the 4.2
or 4.3 time scale. Obviously if people delay trying xl until we've
switched to it then there is something of a chicken and egg problem wrt
making sure it supports their needs.

It seems that you have several issues which are impacting you but I'm
having trouble digesting them all out of your mails. Posting
individually about any the specific issues which you have that are
preventing you from using xl (or indeed Xen generally) will ensure a
much greater chance that someone will notice and do something about
them. I'm sorry to say that posting long rants is unlikely to have the
same effect...

Thanks,
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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