Re: [vserver] Need advice on which path to take for IPv6 support

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