James Bottomley, CTO, Server Virtualization for Parallels gave a presentation entitled, "Containers and The Cloud: Do you need another virtual environment?" on Oct 23. The Linux Foundation recently posted it to YouTube.
There is a lot of good information in the video even for us OpenVZ folks. Enjoy:
Oh, such a provocative subject! Not really. Many people do believe that OpenVZ is obsoleted, and when I ask why, three most popular answers are:
1. OpenVZ kernel is old and obsoleted, because it is based on 2.6.32, while everyone in 2013 runs 3.x. 2. LXC is the future, OpenVZ is the past. 3. OpenVZ is no longer developed, it was even removed from Debian Wheezy.
Let me try to address all these misconceptions, one by one.
1. "OpenVZ kernel is old". Current OpenVZ kernels are based on kernels from Red Hat Enterprise Linux 6 (RHEL6 for short). This is the latest and greatest version of enterprise Linux distribution from Red Hat, a company who is always almost at the top of the list of top companies contributing to the Linux kernel development (see 1, 2, 3, 4 for a few random examples). While no kernel being ideal and bug free, RHEL6 one is a good real world approximation of these qualities.
What people in Red Hat do for their enterprise Linux is they take an upstream kernel and basically fork it, ironing out the bugs, cherry-picking security fixes, driver updates, and sometimes new features from upstream. They do so for about half a year or more before a release, so the released kernel is already "old and obsoleted", as it seems if one is looking at the kernel version number. Well, don't judge a book by its cover, don't judge a kernel by its number. Of course it's not old, neither obsoleted -- it's just more stable and secure. And then, after a release, it is very well maintained, with modern hardware support, regular releases, and prompt security fixes. This makes it a great base for OpenVZ kernel. In a sense, we are standing on the shoulders of a red hatted giant (and since this is open source, they are standing just a little bit on our shoulders, too).
RHEL7 is being worked on right now, and it will be based on some 3.x kernel (possibly 3.10). We will port OpenVZ kernel to RHEL7 once it will become available. In the meantime, RHEL6-based OpenVZ kernel is latest and greatest, and please don't be fooled by the fact that uname shows 2.6.32.
2. OpenVZ vs LXC. OpenVZ kernel was historically developed separately, i.e. aside from the upstream Linux kernel. This mistake was recognized in 2005, and since then we keep working on merging OpenVZ bits and pieces to the upstream kernel. It took way longer than expected, we are still in the middle of the process with some great stuff (like net namespace and CRIU, totally more than 2000 changesets) merged, while some other features are still in our TODO list. In the future (another eight years? who knows...) OpenVZ kernel functionality will probably be fully upstream, so it will just be a set of tools. We are happy to see that Parallels is not the only company interested in containers for Linux, so it might happen a bit earlier. For now, though, we still rely on our organic non-GMO home grown kernel (although it is already optional).
Now what is LXC? In fact, it is just another user-space tool (not unlike vzctl) that works on top of a recent upstream kernel (again, not unlike vzctl). As we work on merging our stuff upstream, LXC tools will start using new features and therefore benefit from this work. So far at least half of kernel functionality used by LXC was developed by our engineers, and while we don't work on LXC tools, it would not be an overestimation to say that Parallels is the biggest LXC contributor.
So, both OpenVZ and LXC are actively developed and have their future. We might even merge our tools at some point, the idea was briefly discussed during last containers mini-conf at Linux Plumbers. LXC is not a successor to OpenVZ, though, they are two different projects, although not entirely separate (since OpenVZ team contributes to the kernel a lot, and both tools use the same kernel functionality). OpenVZ is essentially LXC++, because it adds some more stuff that are not (yet) available in the upstream kernel (such as stronger isolation, better resource accounting, plus some auxiliary ones like ploop).
3. OpenVZ no longer developed, removed from Debian. Debian kernel team decided to drop OpenVZ (as well as few other) kernel flavors from Debian 7 a.k.a. Wheezy. This is completely understandable: kernel maintenance takes time and other resources, and they probably don't have enough. That doesn't mean though that OpenVZ is not developed. It's really strange to argue that, but please check our software updates page (or the announce@ mailing list archives). We made about 80 software releases this year so far. This accounts for 2 releases every week. Most of those are new kernels. So no, in no way it is abandoned.
In the last week or so I've had several questions from new OpenVZ users about container migration. They want to know how it works, what is the difference between live / online migration vs. offline... and how long it will take. I made a silent screencast a few years ago but it is rather dated... and since I can easily add sound now, I thought I'd make an updated screencast. I didn't really put a lot of production value into it but overall it meets its objective. I posted it to archive.org as a webm but they automatically convert it to flash and embed it... so enjoy whichever format you prefer.
While I am writing this, people are discussing the future of containers in the Linux Kernel at the containers mini-summit which is happening in Ottawa at the moment. You can check some rough notes from the event here. Three guys from OpenVZ team are there: Pavel Emelyanov, Denis Lunev, and Andrey Mirkin.
If you are attending Linux Symposium in Ottawa, note that this Friday, 25th, Andrey Mirkin will talk about containers checkpointing and live migration (12:00, Rockhopper room). It's going to be an interesting talk, do not miss it.
Also, this Wednesday, 23rd, Balbir Singh will lead a BoF on Memory Controller (17:45, Fiordland room). Memory controller is quite important for containers, and while some stuff are already in the mainline kernel, there's still lots to be discussed and developed in the area. You can think of this BoF as an extension to containers mini-summit.
SWsoft, sponsor of the OpenVZ project, has recently announced that it will adopt "Parallels" as a new corporate name moving into next year. So, you might ask what what does this mean for OpenVZ?
Absolutely nothing. We will keep doing what we do, providing new releases, fixing bugs, supporting our users and remain focused on integrating containers virtualization technology into the mainstream Linux.
Separate from the company name change, you'll see us slowly cease using the terms "VE" (virtual environment) and "OS-level virtualization". The terms commonly used in the industry are "containers" and "contaners-type virtualization" -- and we are already using those.
Last week I went to Cambridge, UK with my colleague Pavel Emelyanov to take part in the LinuxConf Europe and the containers mini-summit, as well as the Linux Kernel Summit session devoted to containers. Pavel, who works in the OpenVZ kernel team, is now working on integrating our technology into the mainstream Linux kernel. To his credit, the memory controller and the PID namespace patch (see my recent blog post), which were integrated into -mm recently, are mostly due to him.
The first event in Cambridge was LinuxConf Europe, where we both presented our talks on containers -- mine was a general introduction to virtualization, containers, and OpenVZ, while Pavel described some intimate details of memory controller (read "beancounters") implementation.
The next day we had to skip the LinuxConf to take part in the containers mini-summit. This was an event for all the containers shareholders to discuss what and how to present the containers topic at the Kernel Summit. Unfortunately, Eric Biederman (Linux Networx) and Paul Menage (Google) came later, and Balbir Singh (IBM) was buzy with VM mini-summit, so we did this mini-summit in two rounds. First round was with Pavel (OpenVZ), Cedric Le Goater (IBM), Oren Laadan (of Zap -- a checkpointing and live migration project), Kamezava Hiroyuki (of Fujitsu Japan, mostly interested in resource management), and Paul (who joined us over Skype). The second round was with Eric, Paul, and Balbir -- the next day in the hall. The results of this mini-summit are a few threads on containers@ mailing list, plus a few documents here.
Finally, there was 30-minute topic on the Kernel Summit devoted to the containers. Paul and Eric have summarized what we have done so far, and what are we going to do next. There was not much discussion, which I think is healthy because now everybody knows about containers and why they are needed. Slides from the talk are available here. Jonathan Corbet (of Linux Weekly News) also provided a summary of the topic (this is still subscriber-only content, but since I'm a subscriber I can share a free link with you).
It feels like we are making good progress and are on the right path to a containers implementation in the Linux kernel. You can see some people helping to make this happen in this photo. Click the image for larger version.
Back in July, me and a couple of colleagues (Pavel Emelianov and Denis Lunev, both from the OpenVZ kernel team) were in Canada for the Ottawa Linux Symposium.
OLS is a pretty big event and probably the biggest conference that I've seen. Unlike all the previous years, this time it was detached from the Linux Kernel Summit (that will be in Cambridge, U.K. next week). Being detached seemed to have little impact on the event -- it is still large and somewhat kernel-oriented. The facilities for talks and BoFs included one big and five smaller rooms , all named after different species of penguins (the big one is of course named Emperor).
We also had our talk there, presented by Pavel and covering some non-trivial aspects of our resource management solution: the beancounters, which is part of OpenVZ kernel. The paper (PDF, 156K, 9 pages) and the slides (ODP, 89K or PPT, 474K) are available. In short, this is what he was talking about:
Current Linux accounting and limiting mechanisms (setrlimit() and some global stats counters) are not enough as they do not provide any task group-based counters and limits. OpenVZ's beancounters address this issue, implementing per-group accounting and limiting for about 20 different properties, like kernel memory, user space memory, physical memory, network buffers etc. Some specific implementation details (like shared RSS accounting, kernel slab accounting etc) are described.
It's good to see the high level of interest to containers this year. As in any conference, though, a lot of networking is done away from the formal proceedings. For example, we (I mean everybody who's interested in containers) all had a breakfast in nearby Starbucks to discuss containers, resource management, network virtualization and other subtle aspects of what we do. About half of the famous Blackthorn Party for us was devoted to the same discussions (while the other half is surely about the beer).
It was a successful event, and I'm looking forward to take part in the next Blackthorn Party Linux Symposium in Ottawa.
I tried it and was able to migrate a CentOS 7 container... but the Fedora 22 one seems to be stuck in the "started" phase. It creates a /vz/private/{ctid} dir on the destination host (with the same…
The fall semester is just around the corner... so it is impossible for me to break away for a trip to Seattle. I hope one or more of you guys can blog so I can attend vicariously.
Comments
Do you still stand by your opinions above now in 2016?…