Interview: Kir Kolyshkin

Kir Kolyshkin will give a talk about "Linux Containers and OpenVZ" at FOSDEM 2012.

Could you briefly introduce yourself?

My name is Kir Kolyshkin, I am a Linux and free software enthusiast and professional. For the last 5 years I am overseeing the OpenVZ project.

What will your talk be about, exactly?

The talk is about OpenVZ -- an efficient virtualization solution for Linux. This is an introductory/overview talk, not going very deeply into details. I will describe the technology and its applications, and give some status update on the project.

What do you hope to accomplish by giving this talk? What do you expect?

I sincerely hope the audience will start migrating their virtual machines from KVM, Xen and VMware to OpenVZ right in the middle of my talk!

Seriously, I do hope people will gain more knowledge about OS virtualization in general and OpenVZ in particular, and I, in return, will have lots of smart and challenging questions to answer (and those won't be like "so when are you going to support Windows guests?").

Operating system-level virtualization is not so well-known among the general public, while it has a lot of performance benefits compared with whole-system virtualization solutions. Why isn't it much more popular?

Containers and OpenVZ are pretty popular in a specific niche, that is, service providers. Every hosting service provider knows what OS virtualization is, its good and bad sides. The challenge is to expand the knowledge beyond this niche.

One problem is that the concept of a container is a bit hard to grasp. A virtual machine (as in VMware, KVM or Xen) is like your regular PC, just virtual, and it's easy to understand. A container is not as straightforward: it's more like an isolated piece of a userspace, with all such pieces sharing one common kernel, and that is a bit tricky to explain.

What are the main differences between OpenVZ and its commercial counterpart Parallels Virtuozzo Containers?

OpenVZ is a project and a technology, while PVC is a commercial product. The biggest difference is in tools, PVC comes with control panels and such, while OpenVZ is limited to the command line (there are control panels, but those come from third parties).

Which OpenVZ features can we expect this year? And which pieces will probably be merged in the upstream Linux kernel?

Speaking of features, we are polishing our VSwap technology, which is becoming better and better now. We hope we will bring container-in-a-file technology (a.k.a. ploop), the one we have talked about at Linux Plumbers in Prague.

As of the upstream Linux kernel, our main target now is checkpoint/restore in userspace functionality (a precursor to live migration). We are also working on NFS support with respect to network namespaces, more resource management functionality (like kernel memory and network buffers controllers), and /proc virtualization. We might have some luck merging ploop as well.

In recent years LXC has become quite popular, in part because it doesn't require a patched kernel. But what are the advantages of using OpenVZ instead of LXC?

First of all, we are working on OpenVZ for more than ten years, so it is not a work in progress, but a solution that just works. Thousands of production servers run OpenVZ, hosting hundreds of thousands containers. So, stability and security is our first benefit.

In terms of features, OpenVZ is ahead, too. The OpenVZ kernel supports great things such as live migration of containers. OpenVZ has rich resource management mechanisms, including virtual swap and RSS reclamation, among other things. The user space tool (vzctl) is also much more high-level and easier to use than the LXC one.

The technologies that are already in mainline kernel and form the base of LXC (such as various namespaces and cgroup controllers) are of course used by OpenVZ. The patchset that we provide just fills in the missing pieces, so, in a sense, OpenVZ is LXC on steroids (and the price is you have to use our patched kernel).

The OpenVZ kernel is a base for a commercial product, so it is tested thoroughly, very well maintained and supported -- just because it has to be. From time to time we even find bugs in the RHEL kernel (which we use as a solid and stable base).