[Users] The future of OpenVZ: Virtuozzo Core

[James Bottomley]

On Sun, 2014-12-28 at 11:03 -0800, Keith Keller wrote:
> Hi Kir,
> 
> On 2014-12-27, Kir Kolyshkin <kir at openvz.org> wrote:
> >
> > On 12/27/2014 03:12 AM, Benjamin Henrion wrote:
> >> Any chance to see openvz against mainline one day?
> >
> > Maybe this is rarely visible, but we are working hard on it for the last 
> 
> [snip]
> 
> It's possible Benjamin may be asking about actually running OpenVZ
> against a mainline kernel.  Right now, according to the docs, that is an
> experimental and incomplete feature:
> 
> http://openvz.org/Vzctl_for_upstream_kernel
> 
> The quick install docs still recommend using the OpenVZ-supported kernel.
> 
> http://openvz.org/Quick_installation
> 
> So maybe a better way of asking this question might be, are there any
> plans to make the upstream kernel the officially supported kernel for
> OpenVZ?  It may take a while to transition that direction, but it'd be
> good to know whether that's even planned, or whether the OpenVZ kernel
> will still be maintained and recommended for full OpenVZ functionality.

Probably not, in the same way the officially supported kernel of RHEL
isn't upstream.  What we intend to do is to follow upstream (and
upstream first) in the same way Red Hat does.  However, we have the same
problem RHEL does in that we need a kernel that's correctly configured
and has been QA'd and may need some additional patches backporting
(because container features we need in OpenVZ may be ahead of what's in
the current upstream or being pushed upstream) before we can offer
support.

The goal is to reduce the size of the patch that has to be applied, but
even if the patch diff reaches zero, we'd still have to build the
supported kernel for you because supporting what someone else builds
becomes a massive fishing expedition into how it was built and
configured.  Also note that container development doesn't stop just
because everything that was in OpenVZ has gone upstream, so the vzkernel
will probably be the first one to contain the new features on upstream
track and that alone, given that Parallels is the major developer of new
container features, will probably keep the patch diff non-zero.

However, as of kernel 3.14, enough of OpenVZ is upstream to bring up
OpenVZ containers on the vanilla kernel. To enable this, there are
versions of vzctl in Fedora and Debian at least.  You need to make sure
the kernel is configured properly (all the cgroups and namespaces turned
on including CONFIG_USER_NS) and it's still missing the kernel memory
isolation accounting (without this, one container can kill the system by
running it out of kernel resources, like inodes or dentries) but unless
you have hostile applications, this is unlikely to be a problem.  Please
don't report bugs against this configuration and even if you use the
mailing list, make sure to say you're using a custom kernel (an
preferably try to see if the bug is still present with the official vz
kernel).

Finally, we do think that after one more go around at the Linux Storage,
Filesystem and MM summit in March, we should get the kernel memory
accounting patches into 3.19 or 3.20.

James Bottomley