On Sat, Feb 01, 2014 at 11:44:36AM +0100, Adrian Reyer wrote:
> Hi,
> On Sat, Feb 01, 2014 at 09:26:23AM +0000, Gordan Bobic wrote:
>> Can some of the LXC components in the kernel be used in
>> place of the relevant VServer components to make the patch
>> smaller and easier to maintain? Or if the VServer component
>> is "better" (I use the term loosely because what kernel
>> maintainers deem "better" isn't necessarily what other people
>> deem "better"), trying to push a patch to do that upstream?
> I have not checked the code, but I have the impression Herbert
> uses new features that arrive in the kernel and enhance or
> replace features he implemented himself earlier.
> E.g. memory limits now done with cgroups.
Spot on! We already replaced the Linux-VServer scheduler
(which could do a few things the current cgroup scheduler is
still not able to accomplish) and the memory accounting
with cgroups and those are not the only integrations done
so far.
Basically as soon as mainline provides somewhat adequate
solutions to the problems we solved 10 years ago, we try
to switch to the mainline subsystem.
> I have the impression Herbert is not intrested in the hassle
> involved in trying to get some code included into mainline
> kernels.
Correct. I tried for some time, but as it only results in
me having a lot more work and thus less time to spend on
interesting things, I gave up on that.
The code is free and open, so everybody interested can try
to get this or that bit into mainline, I'll even help out
if that person has questions regarding the code.
> I personally regard the vserver an ever decreasing patch in
> terms of size as more features arrive within the kernel.
> If it evolves like I hope, one day we will have all features in
> mainline accompanied by util-vserver, which I like much, much
> better than any lxc-tools I have seen so far.
That is what we are hoping for (since a few years now :)
Unfortunately I think that features like IP Isolation and
CoW Link Breaking will not be available in the foreseeable
future.
>> I'm not sure about the general use case, but the impression
>> I get from listening on the list is that most people tend
>> to use LTS kernels because that is what the distro kernels
>> tend to be based on. Would it perhaps be more reasonable to
>> focus on maintaining the patch only for LTS kernels? They are
>> still moving targets, but at least they would be fewer moving
>> targets.
> We mostly use the 3.4 and 3.10 kernels we provide ourselves
> and for many szenarios a longterm supported kernel is just
> the right thing. However, there are szenarios where you need
> more recent kernels and would like to have VServer support
> nonetheless. Obvious one are new hardware only supported by
> recent kernels and missing backports. A new feature would
> e.g. live migration of a VServer to some other host by using
> criu (http://criu.org/). I have not looked deeply into this
> one, minimum kernel is 3.11. But it seems to me criu could
> enable me to actually live-migrate VServers I run on top of
> DRBD-Clusters. If I get it right, criu actually came from
> OpenVZ and the most recent LXC uses criu for exactly the same
> purpose.
Let me know how that works once you do.
best,
Herbert
> To my understanding, VServer can do everything mainline can
> plus the added features. Same time not limited to a specific
> cpu architecture. If mainline supports freezing tasks, VSevrer
> will. If mainline starts and cook dinner, VServer will be able
> to do so as well.
>> Thank you for VServer. I still firmly believe that it is the
>> "best" of the 3 available chroot virtualization solutions for
>> Linux, especially due to it's hashify feature.
> Same here.
> Regards,
> Adrian
> --
> LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
> Fon: +49 (7 11) 78 28 50 90 - Fax: +49 (7 11) 78 28 50 91
> Mail: lihas_at_lihas.de - Web: http://lihas.de
> Linux, Netzwerke, Conulting & Support - USt-ID: DE 227 816 626 Stuttgart
Received on Sat Feb 1 13:13:00 2014