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

From: Paul Kyzivat <>
Date: Fri 08 Jan 2010 - 21:40:16 GMT
Message-ID: <>


Herbert Poetzl wrote:
> 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
>>>> - patch-
>>>> 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
>>>> - patch-
>>>> 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- When
>>>> we migrated to patch- 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

Nobody realized they needed to use this new feature to achieve the old
functionality. Once we discovered the problem that is exactly what we did.

>> 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

Ditto the above, though the application was acting stupidly.

>> 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)

Live and learn. We will have to be careful to do that.

>> 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- 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


Can you say anything about the stability of
patch- from a practical perspective?
Its been unchanged for some time now. Would you consider it suitable for
"production" use?

>>>> 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.
> so you are patching the kernel beyond the Linux-VServer
> patch (which already makes it more prune to failures :)

Not *me*, but yes. We have people in charge of the kernel.
We tell them we need the vserver functionality. They apply the patch,
and merge with other patches. (Mostly specialized hw stuff I think.)

This is a negotiation over how to get the IPv6 functionality along with
everything else.

We haven't really had much in the way of kernel problems.

>>>> 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-
>>> 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 :)

Most likely our kernel people would do the porting, if we did it.
But they are certainly not expert in either vserver or IPv6.

A lot of the porting can be done by anybody as long as the code being
patched hasn't changed too much. But when things don't work right, they
might not be in a position to diagnose the problem. And then it would be
hard to come back and ask you nice people.

Of course that may also be true merging patches. But I expect we won't
be patching the same things.


>>> 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-
>> 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 19:07:01 2010

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 11 Jan 2010 - 19:07:02 GMT by hypermail 2.1.8