I'm pleased to announce the release of OpenVZ 7.0. The new release focuses on merging OpenVZ and Virtuozzo source codebase, replacing our own hypervisor with KVM.
Key changes in comparison to the last stable OpenVZ release:
OpenVZ 7.0 becomes a complete Linux distribution based on our own VzLinux.
The main difference between the Virtuozzo (commercial) and OpenVZ (free) versions are the EULA, packages with paid features, and Anaconda installer.
EZ templates can be used instead of tarballs with template caches.
Additional features (see below)
This OpenVZ 7.0 release provides the following major improvements:
RHEL7 (3.10+) kernel.
KVM/QEMU hypervisor.
Guest tools for virtual machines that currently allow the following: to execute commands in VMs from the host, to set user passwords, to set and obtain network settings, to change SIDs, to enter VMs.
Unified management of containers and KVM virtual machines with the prlctl tool and SDK. You get a single universal toolset for all your CT/VM management needs.
UUIDs are used to identify both virtual machines and containers. With containers, prlctl treats the former VEID parameter as name.
Virtual machine HDD images are stored in the QCOW2 format.
Ability to manage containers and VMs with libvirt and virt-manager or virsh via a single driver for containers and virtual machines. Libvirt is an open-source API, daemon, and management tool for managing virtualization platforms. The API is widely used in the orchestration layer of hypervisors for cloud-based solutions. OpenVZ considers libvirt as the standard API for managing both virtual machines and containers. Libvirt provides storage management on the physical host through storage pools and volumes which can be used in OpenVZ containers.
Memory guarantees. A memory guarantee is a percentage of container's or virtual machine's RAM that said container or VM is guaranteed to have.
Memory hotplugging for containers and VMs that allows both increasing and reducing CT/VM memory size on the fly, without the need to reboot.
Kernel same-page merging. To optimize memory usage by virtual machines, OpenVZ uses a Linux feature called Kernel Same-Page Merging (KSM). The KSM daemon ksmd periodically scans memory for pages with identical content and merges those into a single page.
VCMMD, the fourth-generation unified memory manager, and vcmmd, a single daemon for managing memory of both virtual machines and containers. OpenVZ 7 uses memcg. Balancing and configuring memcg limits enables getting the exact OpenVZ parameters like overcommit, shadow gangs, swap, page cache overuse.
Container live migration via CRIU and P.Haul. In the previous versions of OpenVZ, most operations performed during migration were done in the kernel space. As a result, the migration process imposed a lot of restrictions. To improve upon migration, Virtuozzo launched the CRIU project aiming to move most of the migration code to the user space, make the migration process reliable, and remove excessive restrictions.
Containers use cgroups and namespaces that limit, account for, and isolate resource usage as isolated namespaces of a collection of processes. The beancounters interface remains in place for backward compatibility and, at the same time, acts as a proxy for actual cgroups and namespaces implementation.
SimFS remains in OpenVZ 7.0, however, the support is limited and we don't have plans to improve it in future.
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.
Here's another video... this one from FLOSS Weekly where they talk about CRIU (Checkpoint & Restore In Userspace) which is closely related to OpenVZ and will be used in the EL7-based OpenVZ kernel branch. Enjoy!
In a light of CRIU 1.1 release that happened last week, we will be doing a hangout on air to tell more about CRIU past and the future, and will be answering your questions. Event page is here, it is going to happen as soon as this Friday, Feb 7th, at 6:00am PST / 9:00am EST / 15:00 CET / 18:00 MSK. Feel free to ask your questions now (go to event page and click on "Play").
OpenVZ project is 7 years old as of last month. It's hard to believe the number, but looking back, we've done a lot of things together with you, our users.
One of the main project goals was (and still is) to include the containers support upstream, i.e. to vanilla Linux kernel. In practice, OpenVZ kernel is a fork of the Linux kernel, and we don't like it that way, for a number of reasons. The main ones are:
We want everyone to benefit from containers, not just ones using OpenVZ kernel. Yes to world domination!
We'd like to concentrate on new features, improvements and bug fixes, rather than forward porting our changes to the next kernel.
So, we were (and still are) working hard to bring in-kernel containers support upstream, and many key pieces are already there in the kernel -- for example, PID and network namespaces, cgroups and memory controller. This is the functionality that lxc tool and libvirt library are using. We also use the features we merged into upstream, so with every new kernel branch we have to port less, and the size of our patch set decreases.
CRIU
One of such features for upstream is checkpoint/restore, an ability to save running container state and then restore it. The main use of this feature is live migration, but there are other usage scenarios as well. While the feature is present in OpenVZ kernel since April 2006, it was never accepted to upstream Linux kernel (nor was the other implementation proposed by Oren Laadan).
For the last year we are working on CRIU project, which aims to reimplement most of the checkpoint/restore functionality in userspace, with bits of kernel support where required. As of now, most of the additional kernel patches needed for CRIU are already there in kernel 3.6, and a few more patches are on its way to 3.7 or 3.8. Speaking of CRIU tools, they are currently at version 0.2, released 20th of September, which already have limited support for checkpointing and restoring an upstream container. Check criu.org for more details, and give it a try. Note that this project is not only for containers -- you can checkpoint any process trees -- it's just the container is better because it is clearly separated from the rest of the system.
One of the most important things about CRIU is we are NOT developing it behind the closed doors. As usual, we have wiki and git, but most important thing is every patch is going through the public mailing list, so everyone can join the fun.
vzctl for upstream kernel
We have also released vzctl 4.0 recently (25th of September). As you can see by the number, it is a major release, and the main feature is support for non-OpenVZ kernels. Yes it's true -- now you can have a feeling of OpenVZ without installing OpenVZ kernel. Any recent 3.x kernel should work.
As with OpenVZ kernel, you can use ready container images we have for OpenVZ (so called "OS templates") or employ your own. You can create, start, stop, and delete containers, set various resource parameters such as RAM and CPU limits. Networking (aside from routed-based) is also supported -- you can either move a network interface from host system to inside container (--netdev_add), or use bridged setup (--netif_add). I personally run this stuff on my Fedora 17 desktop using stock F17 kernel -- it just works!
Having said all that, surely OpenVZ kernel is in much better shape now as it comes for containers support -- it has more features (such as live container shapshots and live migration), better resource management capabilities, and overall is more stable and secure. But the fact that the kernel is now optional makes the whole thing more appealing (or so I hope).
You can find information on how to setup and start using vzctl at vzctl for upstream kernel wiki page. The page also lists known limitations are pointers to other resources. I definitely recommend you to give it a try and share your experience! As usual, any bugs found are to be reported to OpenVZ bugzilla.
Checkpoint/restore, or CPT for short, is a nice feature of OpenVZ, and probably the most amazing one. In a nutshell, it's a way to freeze a container and dump its complete state (processes, memory, network connections etc) to a file on disk, and then restore from that dump, resuming processes execution as if nothing happened. This opens a way to do nifty things such as live container migration, fast reboots, high availability setups etc.
It is our ultimate goal to merge all bits and pieces of OpenVZ to the mainstream Linux kernel. It's not a big secret that we failed miserably trying to merge the checkpoint/restore functionality (and yes, we have tried more than once). The fact that everyone else failed as well soothes the pain a bit, but is not really helpful. The reason is simple: CPT code is big, complex, and touches way too many places in the kernel.
So we* came up with an idea to implement most of CPT stuff in user space, i.e. as a separate program not as a part of the Linux kernel. In practice this is impossible because some kernel trickery is still required here and there, but the whole point was to limit kernel intervention to the bare minimum.
Guess what? It worked even better that we expected. As of today, after about a year of development, up to 90% of the stuff that is needed to be in the kernel is already there, and the rest is ready and seems to be relatively easy to merge (see this table to get an idea what's in and what's not).
As for the user space stuff, we are happy to announce the release of CRtools version 0.1. Now, let me step aside and quote Pavel's announcement:
The tool can already be used for checkpointing and restoring various individual applications. And the greatest thing about this so far is that most of the below functionality has the required kernel support in the recently released v3.5!
So, we support now
* x86_64 architecture * process' linkage * process groups and sessions (without ttys though :\ ) * memory mappings of any kind (shared, file, etc.) * threads * open files (shared between tasks and partially opened-and-unlinked) * pipes and fifos with data * unix sockets with packet queues contents * TCP and UDP sockets (TCP connections support exists, but needs polishing) * inotifies, eventpoll and eventfd * tasks' sigactions setup, credentials and itimers * IPC, mount and PID namespaces
Though namespaces support is in there, we do not yet support an LXC container c/r, but we're close to it :)
I'd like to thank everyone who took part in new kernel APIs discussions, the feedback was great! Special thanks goes to Linus for letting the kernel parts in early, instead of making them sit out of tree till becoming stable enough.
There are still things for which we don't have the kernel support merged (SysVIPC and various anon file descriptors, i.e. inotify, eventpoll, eventfd) yet. We have the kernel branch with the stuff applied available at
What's next? We will be rebasing OpenVZ to Linux Kernel 3.5 (most probably) and will try to re-use CRIU for checkpoint and restore of OpenVZ containers, effectively killing a huge chunk of out-of-tree kernel code that we have in OpenVZ kernel.
* - In fact it was Pavel Emelyanov, our chief kernel architect, but it feels oh so nice to say we that we can't refrain).
I tried it and was able to migrate a CentOS 7 container... but the Fedora 22 one seems to be stuck in the "started" phase. It creates a /vz/private/{ctid} dir on the destination host (with the same…
The fall semester is just around the corner... so it is impossible for me to break away for a trip to Seattle. I hope one or more of you guys can blog so I can attend vicariously.
Comments
Do you still stand by your opinions above now in 2016?…