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.
- The user documentation is publicly available.
- 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.
DownloadAll binary components as well as installation ISO image are freely available at the OpenVZ download server and mirrors.
The most important gathering of free software and open source enthusiasts in Europe is coming on Jan 30-31, in Brussels and OpenVZ will have a table booth there, plus several talks. Come to Containers and Process Isolation devroom (schedule) and OpenVZ booth to talk about Virtuozzo, CRIU, Live migration many other things related to containers.
We would like the community to participate with us in the event. If you live in Tokyo (or can come to this OpenStack Summit), are an OpenVZ user and would like to be a part of our team at the OpenVZ exhibit -- you are very welcome to join us! Please email me (firstname.lastname@example.org) your details and we'll discuss arrangements.
It was almost 10 years ago that I organized a kerneltrap.org interview with our at-that-time kernel team leader Andrey Savochkin, which was published on April 18, 2006. As years go by, kerneltrap.org is no more, Andrey moved on to got a PhD in Economics and is now an Assistant Professor, while OpenVZ is still here. Read on for this great piece of memorabilia.
Andrey Savochkin leads the development of the kernel portion of OpenVZ, an operating system-level server virtualization solution. In this interview, Andrey offers a thorough explanation of what virtualization is and how it works. He also discusses the differences between hardware-level and operating system-level virtualization, going on to compare OpenVZ to VServer, Xen and User Mode Linux.
Andrey is now working to get OpenVZ merged into the mainline Linux kernel explaining, "virtualization makes the next step in the direction of better utilization of hardware and better management, the step that is comparable with the step between single-user and multi-user systems." The complete OpenVZ patchset weighs in at around 70,000 lines, approximately 2MB, but has been broken into smaller logical pieces to aid in discussion and to help with merging.
Jeremy Andrews: Please share a little about yourself and your background...
Andrey Savochkin: I live in Moscow, Russia, and work for SWsoft. My two major interests in life are mathematics and computers, and I was unable to decide for a long time which one I preferred.
I studied in Moscow State University which has a quite strong mathematical school, and got M.Sc. degree in 1995 and Ph.D. degree in 1999. The final decision between mathematics and computers came at the time of my postgraduate study, and my Ph.D. thesis was completely in the computer science area, exploring some security aspects of operating systems and software intended to be used on computers with Internet access.
Jeremy Andrews: What is your involvement with the OpenVZ project?( Read more...Collapse )
After using Bugzilla for a decade, we now decided to switch to Atlassian Jira as our main bug tracker. It will be more convenient for OpenVZ users and allow the development team to share more information with the OpenVZ community.
Atlassian Stash, used as Web frontend to OpenVZ Git, shares the database of registered users with Atlassian Jira. So if you already have an account in Stash you will not need to create another in the new bug tracker, as all Bugzilla users have been imported to Jira. You will, however, need to reset your password.
Kir Kolyshkin (ex-community manager of OpenVZ project)
Alexey Kuznetsov (one of the authors of TCP/IP stack at Linux, iproute2), maintainer of network subsystem at Linux in 2000-2003
Pavel Emelyanov (maintainer of CRIU project)
We would like the community to participate with us in the event. If you live in Seattle (or can come to this ContainerCon), are an OpenVZ user and would like to be a part of our team at the OpenVZ exhibit -- you are very welcome to join us! Please email me (email@example.com) your details and we'll discuss arrangements.
Every now and then our team is asked question "How do I move a container created on OpenVZ to Virtuozzo"? This is one of the issues which will be finally resolved in version 7 that we are now working on (first technical preview is just out). In this version the compatibility will be on binary and transfer protocol levels. So the regular mechanisms (like container migration) will work out of the box.
In prior version this task, although not technically difficult, is not very straightforward, the data images cannot be simply moved - depending on configuration used in OpenVZ, they may be incompatible.Besides, an OpenVZ based container will have configuration that needs to be updated to fit the new platform.
To facilitate such migrations, we created a script which automates all these operations: data transfer, migrating container configuration, and tuning configuration to ensure container will work on the new platform.
The script is available at https://src.openvz.org/projects/OVZL/rep
$ ./ovztransfer.sh TARGET_HOST SOURCE_VEID0:[TARGET_VEID0] ...
./ovztransfer.sh 10.1.1.3 101 102 103
The script has been designed to migrate containers from older OpenVZ versions to v.7; however it should also work migrating data to existing Virtuozzo versions (like 6.0).
There is one restriction: containers based on obsolete templates that do not exist on the destination servers will be transferred as "not template based" - which means tools for template management (like adding an application via vzpkg) won't work for them.
This is a first version of this script; we will have an opportunity to improve it before the final release. That's why your feedback (or even code contributions) is important here.
If you tried it and want to share your thoughts, email to OpenVZ user group at firstname.lastname@example.org.
It has been more than a decade since we released Virtuozzo containers. Back then Linux kernel lacked isolation technologies and we had to implement those as a custom kernel patch. Since then we have worked closely with the community to bring these technologies to upstream. Today they are a part of most modern Linux kernels and this release is the first that will benefit significantly from our joint efforts and the strong upstream foundation.
This is an early technology preview of Virtuozzo 7. We have made some good progress, but this is just the beginning. Much more still needs to be done. At this point we replaced the containers engine and made our tools work with the new kernel technologies. We consider this beta a major milestone on the road to the official Virtuozzo 7 release and want to share the progress with our customers.
This Virtuozzo 7.0 Technical Preview offers the following significant improvements:
- Virtuozzo 7 is based on RHEL7 and Kernel 3.10+
- Containers are using kernel features 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. At the same time it acts as a proxy for actual cgroups and namespaces implementation.
- UUID instead of VEID for container identification. You can now identify containers by their UUIDs or names. By default vzctl will treat the former VEID parameter as name.
- VCMM 4th generation of memory manager. We switched to memcg. By balancing and configuring memcg limits we will get the exact overcommit, shadow gangs, swap, page cache overuse Virtuozzo parameters. This will be done by a userspace daemon.
Read more details in official announce.