Looking forward to 2015, we have very exciting news to share on the future on OpenVZ. But first, let's take a quick look into OpenVZ history.
Linux Containers is an ancient technology, going back to last century. Indeed it was 1999 when our engineers started adding bits and pieces of containers technology to Linux kernel 2.2. Well, not exactly "containers", but rather "virtual environments" at that time -- as it often happens with new technologies, the terminology was different (the term "container" was coined by Sun only five years later, in 2004).
Anyway, in 2000 we ported our experimental code to kernel 2.4.0test1, and in January 2002 we already had Virtuozzo 2.0 version released. From there it went on and on, with more releases, newer kernels, improved feature set (like adding live migration capability) and so on.
It was 2005 when we finally realized we made a mistake of not employing the open source development model for the whole project from the very beginning. This is when OpenVZ was born as a separate entity, to complement commercial Virtuozzo (which was later renamed to Parallels Cloud Server, or PCS for short).
Now it's time to admit -- over the course of years OpenVZ became just a little bit too separate, essentially becoming a fork (perhaps even a stepchild) of Parallels Cloud Server. While the kernel is the same between two of them, userspace tools (notably vzctl) differ. This results in slight incompatiblities between the configuration files, command line options etc. More to say, userspace development efforts need to be doubled.
Better late than never; we are going to fix it now! We are going to merge OpenVZ and Parallels Cloud Server into a single common open source code base. The obvious benefit for OpenVZ users is, of course, more features and better tested code. There will be other much anticipated changes, rolled out in a few stages.
As a first step, we will open the git repository of RHEL7-based Virtuozzo kernel early next year (2015, that is). This has become possible as we changed the internal development process to be more git-friendly (before that we relied on lists of patches a la quilt but with home grown set of scripts). We have worked on this kernel for quite some time already, initially porting our patchset to kernel 3.6, then rebasing it to RHEL7 beta, then final RHEL7. While it is still in development, we will publish it so anyone can follow the development process.
Our kernel development mailing list will also be made public. The big advantage of this change for those who want to participate in the development process is that you'll see our proposed changes discussed on this mailing list before the maintainer adds them to the repository, not just months later when the the code is published and we'll consider any patch sent to the mailing list. This should allow the community to become full participants in development rather than mere bystanders as they were previously.
Bug tracking systems have also diverged over time. Internally, we use JIRA (this is where all those PCLIN-xxxx and PSBM-xxxx codes come from), while OpenVZ relies on Bugzilla. For the new unified product, we are going to open up JIRA which we find to me more usable than Bugzilla. Similar to what Red Hat and other major Linux vendors do, we will limit access to security-sensitive issues in order to not compromise our user base.
Last but not least, the name. We had a lot of discussions about naming, had a few good candidates, and finally unanimously agreed on this one:
Virtuozzo Core
Please stay tuned for more news (including more formal press release from Parallels). Feel free to ask any questions as we don't even have a FAQ yet.
Merry Christmas and a Happy New Year!
Linux Containers is an ancient technology, going back to last century. Indeed it was 1999 when our engineers started adding bits and pieces of containers technology to Linux kernel 2.2. Well, not exactly "containers", but rather "virtual environments" at that time -- as it often happens with new technologies, the terminology was different (the term "container" was coined by Sun only five years later, in 2004).
Anyway, in 2000 we ported our experimental code to kernel 2.4.0test1, and in January 2002 we already had Virtuozzo 2.0 version released. From there it went on and on, with more releases, newer kernels, improved feature set (like adding live migration capability) and so on.
It was 2005 when we finally realized we made a mistake of not employing the open source development model for the whole project from the very beginning. This is when OpenVZ was born as a separate entity, to complement commercial Virtuozzo (which was later renamed to Parallels Cloud Server, or PCS for short).
Now it's time to admit -- over the course of years OpenVZ became just a little bit too separate, essentially becoming a fork (perhaps even a stepchild) of Parallels Cloud Server. While the kernel is the same between two of them, userspace tools (notably vzctl) differ. This results in slight incompatiblities between the configuration files, command line options etc. More to say, userspace development efforts need to be doubled.
Better late than never; we are going to fix it now! We are going to merge OpenVZ and Parallels Cloud Server into a single common open source code base. The obvious benefit for OpenVZ users is, of course, more features and better tested code. There will be other much anticipated changes, rolled out in a few stages.
As a first step, we will open the git repository of RHEL7-based Virtuozzo kernel early next year (2015, that is). This has become possible as we changed the internal development process to be more git-friendly (before that we relied on lists of patches a la quilt but with home grown set of scripts). We have worked on this kernel for quite some time already, initially porting our patchset to kernel 3.6, then rebasing it to RHEL7 beta, then final RHEL7. While it is still in development, we will publish it so anyone can follow the development process.
Our kernel development mailing list will also be made public. The big advantage of this change for those who want to participate in the development process is that you'll see our proposed changes discussed on this mailing list before the maintainer adds them to the repository, not just months later when the the code is published and we'll consider any patch sent to the mailing list. This should allow the community to become full participants in development rather than mere bystanders as they were previously.
Bug tracking systems have also diverged over time. Internally, we use JIRA (this is where all those PCLIN-xxxx and PSBM-xxxx codes come from), while OpenVZ relies on Bugzilla. For the new unified product, we are going to open up JIRA which we find to me more usable than Bugzilla. Similar to what Red Hat and other major Linux vendors do, we will limit access to security-sensitive issues in order to not compromise our user base.
Last but not least, the name. We had a lot of discussions about naming, had a few good candidates, and finally unanimously agreed on this one:
Please stay tuned for more news (including more formal press release from Parallels). Feel free to ask any questions as we don't even have a FAQ yet.
Merry Christmas and a Happy New Year!


Comments
You should have done that way earlier.
Android has gone the same path, where development is "dumped" once in a while.
When can we hope for OpenVZ in Mainline? Never?
> Android has gone the same path, where development is "dumped"
> once in a while.
No. Android is doing "dumps" for every release, so they are working on something and once it's ready they push it to their public repo.
What we are going to do is to always have an up-to-date repository, i.e. all changes will be visible immediately, not once we feel "Virtuozzo Cherry Pie" is ready.
Now, the current delay is just organizational.
> When can we hope for OpenVZ in Mainline? Never?
Not sure why you are so skeptical. How do you track our progress?
So far very big portion of OpenVZ is already upstream -- to the point vzctl can be used on top of the recent upstream kernel. In terms of number of kernel patches we have in upstream kernel, it's close to 2000. In terms of features -- we have PID and net namespaces, some cgroup controllers (to replace UBC), and finally we even have checkpointing and live migration (in form of CRIU, see http://criu.org). This is years of work of our engineers that enable projects such as Docker and LXC.
Now, the big missing pieces are ploop and kernel memory controller. We are working on latter and is going to work on former.
The big one I am wondering about is the hypervisor and the ability to run it alongside containers on the same server.
Also wondering about Parallels Cloud Storage.
Parallels Cloud Storage will most probably require a separate license.
Мира тебе и пельменей :)
One major question though: 3.10, used in RHEL7, is more than 1.5 years old which is all young and fresh for enterprise but hopelessly ancient for real life. Are there plans to close that gap and move to a somewhat more recent kernel?
Seriously, a job of maintaining a kernel for thousands of clients big and small is a challenge, and it is a lot of work (kernel engineers investigating bug reports, porting patches etc., QA engineers testing all this stuff). It's a lot of work. For a piece of software the size of the Linux kernel, and user base such as OpenVZ + Virtuozzo, it is a job for hundreds of people.
On top of that job, we have our own OpenVZ stuff to care about -- bugs, new features, optimizations, porting. We have tens of people working on that. We don't have hundreds to work on what is described in previous paragraph, so we "outsource" most of this work to Red Hat engineers.
Okay, so in the end what is the recommended way to run OpenVZ on a modern linux distro? Or do I get it right that there isn't, so the Right Way™ is to take RHEL/CentOS and run modern distro inside OpenVZ and basically abandon the host machine for anything else?
Having said that, the recommended way of course is to use what we recommend -- and for RHEL6-based OpenVZ kernel it is RHEL6 or CentOS 6 or Scientific Linux 6. You are quite right that you can run any other distros inside containers -- more to say, you should NOT run anything sensible on the host, since host is privileged, i.e. it has access to all containers.
The naming convention you are adopting is identical to that used by Zenoss, and from working there I know that it ends up confusing Open Source users and customers. It's best to avoid using an existing commercial brand for Open Source and then adding a "Core" to designate it as the Open Source edition.
Learn from past mistakes to avoid repeating them :) Keep it OpenVZ. For commercial efforts, also call it OpenVZ. Create a unified, not segmented ecosystem from the beginning -- it will save you headaches down the road. That is what you are trying to do with code and it's what you should be doing with your brand.
Best Regards,
Daniel Robbins
How will this affect development for upstream kernels? I'd rather keep the Amazon kernel for AWS and would love to see OpenVZ / Virtuozzo Core work on top of this..
Thanks :)
Thank you for all the great work,
any news about git for 3.10 kernel ?
We are looking to add it in promox 4.0
when can we expect the opened up repository??
any updates on C7 kernel?
Thanks!
Binaries: http://openvz.livejournal.com/50178.html
And yes, VZ7 kernel is based on RHEL7 kernel which is based on 3.10 kernel. Note though that even RHEL6 kernel is able to run Docker, as it's NOT 2.6.32 but based on 2.6.32 with many new stuff added by Red Hat.
Technology is running fast, Proxmox VE, the Common interface for OpenVZ containers management is stop supporting OpenVZ since it's not up-to date with the OS / kernel releases
they move to LXC :(
Having said that, I had a conversation with Proxmox, and asked if they are going to support OpenVZ. Their reply was they do support OpenVZ. They have two versions -- Proxmox 3.x (with OpenVZ) and Proxmox 4.0 (without OpenVZ). It's up to you, the user, to choose what you want to run.