Again, please, don't judge kernel by its version number. The kernel that RHEL6 comes with has version of 2.6.32, but it's as far from "vanilla" 2.6.32 as Chicago from Seattle. It has tons of patches (with OpenVZ patchet being only about 10% of it). There's a somewhat old comparison about RHEL5 patch set that you can see here: http://openvz.livejournal.com/27592.html
> I believe it still relies on Kernel 2.6, I think
> they forked the kernel then never kept it up to date
Sad to see you spreading FUD without knowing much. Let me describe how it's really working.
OpenVZ kernels are based on RHEL (Red Hat Enterprise Linux) kernels. Yesterday we have released OpenVZ 7 which is based on RHEL7 kernel, which is loosely based on 3.10 (I hear you say "old kernel!" -- more on that below).
OpenVZ kernel developers are doing two things:
1. merge our patches upstream;
2. port our patches to a newer RHEL kernels.
As for merging our patches upstream, it's usually happens by rewriting pieces from scratch, and therefore the process is slower than we'd like. So far we have succeeded in having PID and network namespaces, some cgroup controllers, and CRIU (checkpoint/restore, a prereq to live migration -- it's mostly in userspace but there are about 170 kernel patches). I estimate this makes us (Virtuozzo/OpenVZ team) the biggest contributor to the containers in the Linux kernel. This contribution of ours enables technologies such as Docker, LXC etc. In other words, we made Docker and LXC possible.
As for porting our kernels, yes, we use RHEL kernels as a base for ours, as we believe that Red Hat is doing great work keeping their kernels stable and secure. What they do is fork a kernel (2.6.9 for RHEL4, 2.6.18 for RHEL5, 2.6.32 for RHEL6, 3.10 for RHEL7) about a year or so before a RHEL x.0 release, and then they maintain that fork, fixing bugs and improving stability, and sometimes porting new features, but [almost] not introducing new bugs. We value this work, and we use it as a base. So, yes, the latest and greatest RHEL7, and the latest and greatest OpenVZ 7 are based on somewhat rusty 3.10 kernel. Having said that, 3.10 is just a version number of the kernel that was used, a few years back, as a base for the RHEL kernel. It's been heavily patched since that time, but still bears this 3.10 number.
Hope that makes it more clear. Please spread the truth.
> modern, stable, well maintained options
See, we do OpenVZ kernel releases on an almost weekly basis. But since it's 2.6.32, or 3.10, it makes us unmodern, unstable, and not well maintained, right? Wrong.
[Disclaimer: I am the guy who was running OpenVZ since the very beginning, and if you hate OpenVZ name/logo, I am the one to blame. Also, take everything I say with a grain of salt -- although I know, use, like and develop for Docker, my expertise is mostly within OpenVZ domain, and my point of view is skewed towards OpenVZ]
Technologically, both OpenVZ and Docker are similar, i.e. they are containers -- isolated userspace instances, relying on Linux Kernel features such as namespaces. [Shameless plug: most of namespaces functionality is there because of OpenVZ engineers work on upstreaming]. Both Docker and OpenVZ has tools to set up and run containers. This is there the similarities end.
The differences are:
1 system containers vs application containers
OpenVZ containers are very much like VMs, except for the fact they are not VMs but containers, i.e. all containers on a host are running on top of one single kernel. Each OpenVZ container has everything (init, sshd, syslogd etc.) except the kernel (which is shared).
Docker containers are application containers, meaning Docker only runs a single app inside (i.e. a web server, a SQL server etc).
2 Custom kernel vs vanilla kernel
OpenVZ currently comes with its own kernel. 10 years ago there were very few container features in the upstream kernel, so OpenVZ has to provide their own kernel, patched for containers support. That support includes namespaces, resource management mechanisms (CPU scheduler, I/O scheduler, User Beancounters, two-level disk quota etc), virtualization of /proc and /sys, and live migration. Over ten years of work of OpenVZ kernel devs and other interesting parties (such as Google and IBM) a lot of this functionality is now available in the upstream Linux kernel. That opened a way for other container orchestration tools to exist -- including Docker, LXC, LXD, CoreOS etc. While there are many small things missing, the last big thing -- checkpointing and live migration -- was also recently implemented in upstream, see CRIU project (a subproject of OpenVZ, so another shameless plug -- it is OpenVZ who brought live migration to Docker). Still, OpenVZ comes with its own custom kernel, partly due to retain backward compatibility, partly due to some features still missing from the upstream kernel. Nowadays that kernel is optional but still highly recommended.
Docker, on the other side, runs on top of a recent upstream kernel, i.e. it does not need a custom kernel.
3 Scope
Docker has a broader scope than that of OpenVZ. OpenVZ just provides you with a way to run secure, isolated containers, manage those, tinker with resources, live migrate, snapshot, etc. But most of OpenVZ stuff is in the kernel.
Docker has some other things in store, such as Docker Hub -- a global repository of Docker images, Docker Swarm -- a clustering mechanism to work with a pool of Docker servers, etc.
4 Commercial stuff
OpenVZ is a base for commercial solution called Virtuozzo, which is not available for free but adds some more features, such as cluster filesystem for containers, rebootless kernel upgrades, more/better tools, better containers density etc. With Docker there's no such thing. I am not saying it's good or bad, just stating the difference.
This is probably it. Now, it's not that OpenVZ and Docker are opposed to each other, in fact we work together on a few things:
1. OpenVZ developers are authors of CRIU, P.Haul, and CRIU integration code in Docker's libcontainer. This is the software that enables checkpoint/restore support for Docker.
3. OpenVZ devs are authors of libct, a C library to manage containers, a proposed replacement or addition to Docker's libcontainer. When using libct, you can use enhanced OpenVZ kernel for Docker containers.
