Hi, I wrote a little script that should help you for building of Linux-Vserver from source code. You can choose your version of Kernel, patch, and Util-Vserver. It can be easily adapted from Debian to other distributions: http://dokuwicri.univ-reims.fr/files/vs-tools2/vs-tools/install-stage1.sh http://dokuwicri.univ-reims.fr/files/vs-tools2/vs-tools/install-stage1.cf.sample Herbert Poetzl a écrit : > On Thu, Jan 07, 2010 at 01:04:39PM -0500, Paul Kyzivat wrote: > >> Hello - this is my first time posting here. >> > > >> The project I am working on is currently using: >> - kernel 2.6.22.10 >> - patch-2.6.22.10-vs2.2.0.5.diff >> > > >> That is working for us, but now we want to have support for IPv6 in the >> guests. I am trying to decide the most practical way to get there. >> > > >> At the moment, the most straightforward path seems to be: >> - kernel 2.6.22.19 >> - patch-2.6.22.19-vs2.3.0.34.diff >> > > >> We are seriously considering that. But some of our people are >> concerned that we might have migration issues to deal with, or at >> least extra testing if we go that way, and are desirous of a more >> minimalist change. >> > > >> (We had previously been using patch-2.6.14.3-vs2.01.diff. When >> we migrated to patch-2.6.22.10-vs2.2.0.5.diff some of our guests >> encountered incompatibilities that we didn't discover until after >> the fact. >> > > just curious, what were the incompatibilities you discovered? > > >> That is making people gun shy. There is also some concern over >> switching from a "stable" release to a "development" release.) >> > > actually it is an experimental release :) > > >> So I've also been investigating the possibility of adding the IPv6 >> capabilities to the vserver version we have. I see that was done for >> some vserver versions via additional patches from: >> http://people.linux-vserver.org/~bonbons/ipv6/ >> But there isn't such a patch for our kernel/vserver combination. >> > > >> I also note some discussion on your mailing list here that you >> are getting ready to release a new *stable* vs release. >> > > we are on the verge to a devel release, which will be > the basis for further stabilization and testing which > should ultimately result in a new stable release, but > there are quite some things to do till then, and till > now the interest in helping with testing is quite low, > so it might take a while ... > > >> Depending on when that is to be available, maybe we should be >> considering that one too. >> > > you might consider a recent 2.6.31/32 kernel and patch > as it will be the basis for that upcoming stable, and > simply switch to that stable version once it is available > > >> I have some questions whose answers should help decide among the >> possibilities: >> > > >> - Is there a way to determine what user impacting changes there >> are between the version we are on and some newer version, say >> patch-2.6.22.19-vs2.3.0.34.diff? >> > > that's not really 'newer' it is just a different branch, > same kernel/time .... > > >> (I have looked at the change logs, but I can't easily extrapolate >> how those changes would affect existing user code.) >> > > most likely there are no effects at all > > >> - Would it make *any* sense to try porting one of the IPv6 patches >> to vs2.2.0.5??? >> > > not really, but feel free to do so if you like :) > > >> - When do you expect to release the next stable version? >> > > when it's ready ... feel free to speed that up by donations > or contributions (mostly time or resources) > > >> - What kernels with that next stable version support? >> > > most likely 2.6.31+ > > >> - How will this stable version differ from vs2.3.0.34? >> > > it will be thoroughly tested, have full CFS integration > and no known bugs :) > > HTH, > Herbert > > >> Thanks, >> Paul (Kyzivat) >> > > > -- Laurent Spagnol Administrateur Linux Université de Reims Centre de Ressources Informatiques Campus du Moulin de la Housse BP 1039 - 51687 Reims cedex 2 Tel: 03.26.91.88.32 Fax: 03.26.91.31.87