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 <jbottom...@parallels.com> wrote: > On Sun, 2014-12-28 at 11:03 -0800, Keith Keller wrote: > > Hi Kir, > > > > On 2014-12-27, Kir Kolyshkin <k...@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@openvz.org > https://lists.openvz.org/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users