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 (email@example.com) 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 (firstname.lastname@example.org) 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 email@example.com.
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.
- Critical security issue was fixed in OpenVZ kernel 2.6.32-042stab108.7
- 8 security issues fixed in OpenVZ kernel 2.6.32-042stab108.8
- CVE-2014-3184 HID: off by one error in various _report_fixup routines
- CVE-2014-3940 missing check during hugepage migration
- CVE-2014-4652 ALSA: control: protect user controls against races & memory disclosure
- CVE-2014-8133 x86: espfix(64) bypass via set_thread_area and CLONE_SETTLS
- CVE-2014-8709 net: mac80211: plain text information leak
- CVE-2014-9683 buffer overflow in eCryptfs
- CVE-2015-0239 kvm: insufficient sysenter emulation when invoked from 16-bit code
- CVE-2015-3339 kernel: race condition between chown() and execve()
OpenVZ kernel team discovered security issue that allows privileged user inside
container to get access to files on host. All kind of containers affected: simfs, ploop and vzfs. Affected all kernels since 2.6.32-042stab105.x
Note: RHEL5-based kernels 2.6.18, Red Hat and mainline kernels are not affected.
Note: RHEL5-based kernels 2.6.18 are not affected.
It is quite critical to install latest OpenVZ kernel to protect your systems.
Please reboot your nodes into fixed kernels or install live patches from Kernel Care.
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.