Herbert Poetzl wrote:
> 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 22.214.171.124
>> - patch-126.96.36.199-vs188.8.131.52.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 184.108.40.206
>> - patch-220.127.116.11-vs18.104.22.168.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-22.214.171.124-vs2.01.diff. When
>> we migrated to patch-126.96.36.199-vs188.8.131.52.diff some of our guests
>> encountered incompatibilities that we didn't discover until after
>> the fact.
> just curious, what were the incompatibilities you discovered?
(I wasn't directly involved - just relaying what I have heard):
1) shmmax & shmall values are no longer propagated into the Guest
I know there is a faq that covers this, and we have used it to fix the
problem. But we didn't catch it until it caused trouble.) A guest app
that had a lot of code to optimize how it uses memory started acting funny.
2) getrlimit(RLIMIT_NOFILE, ...) returns 1024*1024
(used to return 1024)
Similar issue to the other one. We had an application that was reporting
performance degredation on the new version. Turns out it was trying to
close all RLIMIT_NOFILE files in lots of processes. Turns out that
closing a million non-existent files takes a lot longer than closing 1k
non-existent files.) I don't know if we fixed it or just told him not to
be so stupid.
I think that is all water over the dam now. But we hope to avoid
surprises in the future.
Is there an FAQ for migration from 2.2 to 2.3?
>> 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 :)
Well, IIUC, patch-184.108.40.206-vs220.127.116.11.diff is a "development" release.
If we were to use one of the ipv6 patches on a 2.2 release we would be
using "experimental" code. Right?
>> 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:
>> 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
As smart as that probably is, I think it will be difficult to get past
the 2.6.22 kernel any time soon. I believe we require some special
kernel patches that aren't available for newer kernels. But don't quote
me on that.
>> I have some questions whose answers should help decide among the
>> - Is there a way to determine what user impacting changes there
>> are between the version we are on and some newer version, say
> 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 vs18.104.22.168???
> not really, but feel free to do so if you like :)
>> - When do you expect to release the next stable version?
I'm funny - I don't like like to mess with code that I don't understand
well enough to support.
> 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+
OK. Then we will probably stick with patch-22.214.171.124-vs126.96.36.199.diff
until somebody is sufficiently motivated to move to the new kernel.
>> - How will this stable version differ from vs188.8.131.52?
> it will be thoroughly tested, have full CFS integration
> and no known bugs :)
Can you arrange for it to have no *unknown* bugs too? :-)
Thanks for the info/insight,
Received on Mon Jan 11 17:53:33 2010