One of the questions that people ask us is how Parallels competes with Docker and why we do nothing while Docker is busy conquering the market? Firstly, since we created containers a decade ago, we have been perfecting container virtualization and pushing it to upstream. Secondly, Parallels and Docker operate on different levels: Docker packages and runs applications while Parallels provide virtualization, a low-level technology that Docker uses. This allows us to partner in a number of projects. Moreover, all existing container-related projects in the market do more than just compete with each other. We also try to cooperate in developing shared components.
One good example is the libcontainer project that unifies two versions of a library that manages kernel components used in container creation. We are currently trying to standardize how our own OpenVZ as well as Docker and other projects interact with the Linux kernel. We also want to bind libcontainer to primary programming languages to provide more scenarios of container use in the market. Besides, we plan to integrate containers with OpenStack via libcontainer.
The libcontainer project has interesting history, by the way. Docker was initially meant to be a container template management project that used vzctl to run containers. Then its developers moved to LXC and then came up with their own libcontainer library. At the same time we decided to "standardize" containers' kernel-related part and create a low-level library. In all, there were as many as three such systems at that time: ours, LXC, and libcontainer. We reworked our version and presented it to the public. And it happened so that our announcement was very close to the initial release of Docker's library. Since the projects pursued the same goal, we decided to join forces. Libcontainer has several points of interest for us. Firstly, one willing to use containers has to choose between several projects. This is inconvenient for users and costly for developers (as they have to support multiple versions of essentially the same technology). However, the entire stack will be standardized sooner or later and we'd like to participate to be able to control both the development and results. Secondly, we'll be able to achieve the dream of many users to run Docker containers on our stable kernel.
Recently, we announced jointly with Docker that Virtuozzo (the successor of OpenVZ and Parallels Cloud Server) supports Docker containers and allows creating "containers within containers", i.e. use Docker inside Virtuozzo.
Another good example of cooperation is live migration of Docker (and LXC) containers made possible by our CRIU project (Checkpoint/Restore In Userspace [mostly]). This technology enables you to save the state of a Linux process and restore it in a different location or at a different time (or "freeze" it). Moreover, this is the first ever implementation of an application snapshot technology that works on unmodified Linux (kernel + system libraries) and supports any process state. It's available, for example, in Fedora 19 and newer. There were similar projects before, but they had drawback, e.g., required specific kernels and customized system libraries or supported only some process states.
The live migration itself is performed by the P.Haul subproject that uses CRIU to correctly migrate containers between computers. CRIU allows performing two key actions: 1) save process states to files and 2) restore processes from saved data. There are nuances, for example, CRIU can work without stopping processes and save only changes to process states if need be.
Migration is more difficult and implies at least three actions: 1) saving process state, 2) transferring it to a different computer, and 3) restoring the saved state. In actuality, it can also include transferring the file system, stopping the processes on the source computer and destroying them in the end as well as reducing freeze time by performing a series of memory transfers and saving changes in state, additional copying of memory after migration.
Migration can also include such actions as transferring container's IP address, reregistering it with the management system (e.g., docker-daemon in Docker), handling container's external links. For example, LXC often links files inside containers with files outside it. You can have CRIU relink such files on the destination computer. Development of all these features and nuances was organised into a dedicated project.
Today CRIU is a standard for implementing checkpoint/restore functionality in Linux (even though VMware claimed one should use vMotion for container migration). In this project we also cooperate with developers from Google, Canonical, and RedHat. They not only send patches but also actively discuss cgroup support in CRIU and successfully use CRIU with Docker and LXC tools.
The CRIU technology has lots of uses aside from live migration: speeding up start of large applications, rebootless kernel updates, load balancing, state backup for failure recovery. Usage scenarios include network load balancing, analysis of application behaviour on different computers, process duplication, and such.