LWN: Comments on "Virtuozzo source code available"

Virtuozzo source code available

TimSmall — Sat, 06 Jun 2015 19:16:11 +0000

So, is it now possible to run this code on top of the OpenVZ RHEL7-based kernel tree and end up with a more or less functioning OpenVZ system?

Virtuozzo source code available

jejb — Wed, 03 Jun 2015 18:16:48 +0000

> Virtuozzo/OpenVZ has zero chances of going upstream as it is. And that makes all the difference - with Docker/LXC you don't depend on one company maintaining a huge patch set (although it got smaller over the years).

It got smaller because it's been going upstream for years. The process accelerated in 2011 following the containers meeting at the kernel summit. Virtuozzo 7 will be very close to mainstream. Most of the additional patches it still carries are for legacy stuff because we can't just dump previously supported interfaces even if they're not upstream material.

Virtuozzo source code available

snajpa — Wed, 03 Jun 2015 13:20:26 +0000

Well since most of the container related code is from the OpenVZ guys anyway, I don't see that as a problem, it is an advantage instead - they have tried some approaches wih OVZ and are constantly pushing those features reimplemented in a more flexible ways to upstream kernel. So OVZ stays ahead feature-wise, meanwhile the patch size of OVZ continues to decrease gradually, as more and more of the stuff needed is already there waiting to be used. There will be a day when OVZ patch will have zero lines and all that'll be left from OVZ project are userspace tools like vzctl, CRIU, etc.

Virtuozzo source code available

adobriyan — Wed, 03 Jun 2015 10:45:49 +0000

> Virtuozzo/OpenVZ has zero chances of going upstream as it is.

Well, it was obvious in 2006 when bits and pieces of various container projects started to get merged into mainline,
sometimes changed in quite a lot of ways.

Initially, OpenVZ net namespace code was done "indirectly", namely, you set networking context where necessary and unset/change it when done much like spinlock API looks like. Mainline explicitly passes "struct net *" pointers everywhere. OpenVZ allowed only one level of clone(CLONE_NEW...) (read: couldn't run container in container) and there was a stupid bug when someone run a program which uses mount namespace (by that time a well established feature containers or not) in a VE and it didn't work. Mainline allows hierarchical PID namespaces. OpenVZ had dentry cache (and generic) kernel memory accounting so that "while true; do mkdir x; cd x; done" couldn't OOM the box and make filesystem unusable. SLUB came and QA showed that beancounters were wrong -- SLUB doesn't keep pointers to pages exactly full of objects so it was impossible to find and account them, feature was marked as SLAB only. Those were the days...

Every time I read about this Docker stuff, I get the impression that it can resurrect dead and cure cancer while OpenVZ et al are hopeless because they "have zero chances" to get merged. But this can not be further from truth. OpenVZ was merged long ago. Not everything was accepted (beancounters) though.

Virtuozzo source code available

Cyberax — Wed, 03 Jun 2015 07:37:46 +0000

Virtuozzo/OpenVZ has zero chances of going upstream as it is. And that makes all the difference - with Docker/LXC you don't depend on one company maintaining a huge patch set (although it got smaller over the years).

Virtuozzo source code available

einstein — Wed, 03 Jun 2015 05:15:20 +0000

I hope this helps their popularity. openvz is an amazing, production quality lightweight virtualization technology. Used virtuozzo containers for infrastructure servers for years at my previous employer, and used openvz containers to run high traffic web sites for small businesses. it will most likely be years before lxc reaches the capabilities openvz had in 2008

Virtuozzo source code available

brice — Wed, 03 Jun 2015 04:47:45 +0000

if the post mentioned docker, a torrent of comments would have DDoSd LWN.net -- alas, it's about the other container tech which is actually pretty cool, mature, and worth following.

I really enjoyed proxmox + openVZ -- perhaps the project can benefit from these tools.

back to dockerizing for now.