January 17th, 2007

  • k001

UML author on OpenVZ

There is a nice interview with Jeff Dike, author and maintainer of User-Mode Linux, published recently on linux.com. There are a couple of statements devoted to OpenVZ:

Dike also noted that SWsoft and XenSource are trying to get OpenVZ and Xen technology, respectively, into the mainline kernel, but says that's unlikely. <...> He also says that OpenVZ is unlikely to be adopted in the mainline kernel tree, at least as it is. Dike says that OpenVZ has to have "code sprinkled all over the place" to work, and it violates conventions within the kernel.

I'd like to comment on this.

1. Just to clarify, our goal is not to merge OpenVZ -- we want to have OS-level virtualization (a.k.a. containers, a.k.a. namespaces) in the mainline kernel. Some parts of that will be from OpenVZ, some from Eric Biederman, some from IBM developers, something from somebody else we don't know yet -- and that is what happening now.

2. We certainly do not want to merge OpenVZ "as it is". The process is like the following: we pick up a piece of OpenVZ functionality, review it, port it to recent -mm release, and submit patches for review. We then get some comments, take them into account and release the next version of the same patch set (example: today Dmitry Mishin has just submitted the third iteration of L2 network namespace patches). Sometimes somebody else pick up what we submit, rework it and send for review. After a few iterations, code is ready to be merged.

3. It is not just ourselves SWsoft and the OpenVZ project who want to have OS-level virtualization in the mainline kernel. Different teams are working on that together -- so it is a collaborative effort. So far, we have achieved some success.

4. Indeed, OpenVZ changes affects the kernel code in multiple places, because OpenVZ adds a new and complex feature, which can be compared to, say, multitasking. Still, this code is easily broken down to several features/subsystems, so it is not like one huge non-reviewable patch.

5. While the OpenVZ patch is big, as compared with the size of changes between minor linux kernel versions, it is actually much smaller. For example, the patch from 2.6.18 to 2.6.19 is 7.7MB (in gzipped form), while the latest OpenVZ patch (028test010, against the same 2.6.18, also gzipped) is only 900KB.

Surely, it's a long way to go. Definitely, we are listening to everybody who likes to be involved. Hopefully, we'll get there.