[Users] The future of OpenVZ: Virtuozzo Core

[jjs - mainphrame]

Very interesting!

So, after reading this, I installed vzctl-core on my fedora 21 box, from
the stock repositories, and just for giggles, I issued the command "vzctl
create 101".

It did the right thing and created a default Centos 6 container.

However, I immediately noticed that the vzlist command is missing. Excuse
the dumb question, but what is the new way to list vz containers?

Thanks & Regards,

JJ

On Sun, Dec 28, 2014 at 12:17 PM, James Bottomley <jbottomley at parallels.com>
wrote:

> 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
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20141231/67a2c258/attachment.html>