On Fri, Jan 08, 2010 at 03:26:44PM -0500, Paul Kyzivat wrote:
> Inline...
> 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 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?
> (I wasn't directly involved - just relaying what I have heard):
> 1) shmmax & shmall values are no longer propagated into the Guest
hmm, that is a feature, IMHO, and you can easily adjust
the values per guest, so you are backwards compatible
here
> 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)
again, you can set the limit per guest to whatever you
like, so 42 or 1024 is as fine as 1024*1024, just set it
to the desired value
> 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.
I guess if you check what 'features' have been added
and take care to configure them properly, you can be
backward compatible to 2.0 releases if not even 1.x
releases (from the guest PoV)
> Is there an FAQ for migration from 2.2 to 2.3?
not really, should work out of the box, but of course
with new features added/turned on ...
> >>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-2.6.22.19-vs2.3.0.34.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?
strictly speaking ...
vs2.3.x .. development release
vs2.3.x.y ... 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
> 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.
so you are patching the kernel beyond the Linux-VServer
patch (which already makes it more prune to failures :)
> >>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
> great!
> >>- 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?
> I'm funny - I don't like like to mess with code that I don't
> understand well enough to support.
still you add patches to the kernel :)
> >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-2.6.22.19-vs2.3.0.34.diff
> until somebody is sufficiently motivated to move to the new kernel.
> >>- How will this stable version differ from vs2.3.0.34?
> >it will be thoroughly tested, have full CFS integration
> >and no known bugs :)
> Can you arrange for it to have no *unknown* bugs too? :-)
we'll try, but no guarantees there :)
best,
Herbert
> Thanks for the info/insight,
> Paul
Received on Mon Jan 11 18:33:13 2010