<?xml version="1.0" encoding="utf-8"?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. https://www.livejournal.com/bots/ -->
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:lj="https://www.livejournal.com">
  <id>urn:lj:livejournal.com:atom1:openvz</id>
  <title>OpenVZ</title>
  <subtitle>OpenVZ</subtitle>
  <author>
    <name>OpenVZ</name>
  </author>
  <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/"/>
  <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom"/>
  <updated>2018-08-27T18:52:37Z</updated>
  <lj:journal userid="9392309" username="openvz" type="community"/>
  <link rel="service.feed" type="application/x.atom+xml" href="https://openvz.livejournal.com/data/atom" title="OpenVZ"/>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:53870</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/53870.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=53870"/>
    <title>OpenVZ 7.0 released</title>
    <published>2016-07-26T07:22:21Z</published>
    <updated>2016-07-26T07:29:42Z</updated>
    <category term="openvz"/>
    <category term="release"/>
    <category term="criu"/>
    <content type="html">I&amp;#39;m pleased to announce the release of OpenVZ 7.0. The new release focuses on merging OpenVZ and &lt;a href="https://src.openvz.org/projects/OVZ" target="_blank" rel="nofollow"&gt;Virtuozzo source codebase&lt;/a&gt;, replacing our own hypervisor with KVM.&lt;br /&gt;&lt;br /&gt;Key changes in comparison to the last stable OpenVZ release:&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;OpenVZ 7.0 becomes a complete Linux distribution based on our own &lt;a href="https://virtuozzo.com/products/virtuozzo-linux/" target="_blank" rel="nofollow"&gt;VzLinux&lt;/a&gt;.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;The main difference between the Virtuozzo (commercial) and OpenVZ (free) versions are the EULA, packages with paid features, and Anaconda installer.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;The user documentation is &lt;a href="https://docs.openvz.org/" target="_blank" rel="nofollow"&gt;publicly available&lt;/a&gt;.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://docs.openvz.org/virtuozzo_7_users_guide.webhelp/_managing_templates.html" target="_blank" rel="nofollow"&gt;EZ templates&lt;/a&gt; can be used instead of tarballs with template caches.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Additional features (see below)&lt;/li&gt;&lt;br /&gt;&lt;/ul&gt;&lt;br /&gt;This OpenVZ 7.0 release provides the following major improvements:&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;RHEL7 (3.10+) kernel.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;KVM/QEMU hypervisor.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;UUIDs are used to identify both virtual machines and containers. With containers, prlctl treats the former VEID parameter as name.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Virtual machine HDD images are stored in the QCOW2 format.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Ability to manage containers and VMs with libvirt and &lt;a href="https://kb.virtuozzo.com/en/129047" target="_blank" rel="nofollow"&gt;virt-manager&lt;/a&gt; or virsh via a &lt;a href="http://libvirt.org/drvvirtuozzo.html" target="_blank" rel="nofollow"&gt;single driver&lt;/a&gt; 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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://docs.openvz.org/virtuozzo_7_users_guide.webhelp/_managing_resources.html" target="_blank" rel="nofollow"&gt;Memory guarantees&lt;/a&gt;. A memory guarantee is a percentage of container&amp;#39;s or virtual machine&amp;#39;s RAM that said container or VM is guaranteed to have.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Memory hotplugging for containers and VMs that allows both increasing and reducing CT/VM memory size on the fly, without the need to reboot.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://openvz.org/Memory_management_in_VZ7" target="_blank" rel="nofollow"&gt;VCMMD&lt;/a&gt;, 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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Container live migration via &lt;a href="https://criu.org/Main_Page" target="_blank" rel="nofollow"&gt;CRIU&lt;/a&gt; and &lt;a href="https://criu.org/P.Haul" target="_blank" rel="nofollow"&gt;P.Haul&lt;/a&gt;. 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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;SimFS remains in OpenVZ 7.0, however, the support is limited and we don&amp;#39;t have plans to improve it in future.&lt;/li&gt;&lt;br /&gt;&lt;/ul&gt;&lt;h3&gt;Download&lt;/h3&gt;All binary components as well as &lt;a href="https://download.openvz.org/virtuozzo/releases/7.0/x86_64/iso/" target="_blank" rel="nofollow"&gt;installation ISO image&lt;/a&gt; are freely available at the &lt;a href="https://download.openvz.org/virtuozzo/" target="_blank" rel="nofollow"&gt;OpenVZ download server&lt;/a&gt; and &lt;a href="https://mirrors.openvz.org/" target="_blank" rel="nofollow"&gt;mirrors&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;&lt;a href="https://lists.openvz.org/pipermail/announce/2016-July/000664.html" target="_blank" rel="nofollow"&gt;Original announce&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:53609</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/53609.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=53609"/>
    <title>Meet OpenVZ at FOSDEM 2016</title>
    <published>2016-01-18T14:18:02Z</published>
    <updated>2016-01-18T14:18:02Z</updated>
    <category term="openvz"/>
    <category term="booth"/>
    <category term="conference"/>
    <category term="fosdem"/>
    <content type="html">&lt;p&gt;&lt;img alt="" src="https://ic.pics.livejournal.com/estetus/12957684/594/594_900.jpg" style="color: rgb(34, 34, 34); font-family: Arial, sans-serif; font-size: 14px; line-height: 1.4;" title="" fetchpriority="high" /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="color: rgb(34, 34, 34); font-family: Arial, sans-serif; font-size: 14px; line-height: 1.4;"&gt;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 (&lt;a href="https://www.fosdem.org/2016/schedule/track/containers_and_process_isolation/" target="_blank" rel="nofollow"&gt;schedule&lt;/a&gt;) and &lt;a href="https://fosdem.org/2016/stands/" target="_blank" rel="nofollow"&gt;OpenVZ booth&lt;/a&gt; to talk about Virtuozzo, CRIU, Live migration many other things related to containers.&lt;/span&gt;&lt;/p&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:53331</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/53331.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=53331"/>
    <title>Join Our Team at OpenStack Summit 2015 Tokyo</title>
    <published>2015-09-16T08:47:23Z</published>
    <updated>2015-09-16T08:47:45Z</updated>
    <category term="openstack"/>
    <category term="openvz"/>
    <category term="summit"/>
    <category term="booth"/>
    <content type="html">&lt;img src="https://imgprx.livejournal.net/ac8f90fe188aca5bcc33cd39e1dc47f6c1dc76cf/pppAbCl-MXRZS8GXU_zKHl3aozikP7pqcWIPKizp8oNdlmtiXB6syeS3mGQ1CHdS9JL-arQiv9JPezGZW11RO3oLvBqcFY-Luxc2nrQ3RQY" alt="" align="left" width="200" fetchpriority="high" /&gt; We're very excited that this year OpenVZ will have exhibit space at &lt;a href="https://www.openstack.org/summit/tokyo-2015/" target="_blank" rel="nofollow"&gt;OpenStack Summit&lt;/a&gt; in Tokyo Japan, October 27-30. We will be showing and demoing OpenVZ server virtualization, answering questions and so on. &lt;br /&gt;&lt;br /&gt;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 (sergeyb@openvz.org) your details and we'll discuss arrangements.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:52998</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/52998.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=52998"/>
    <title>An interview with OpenVZ kernel developer, from 2006</title>
    <published>2015-08-11T20:46:29Z</published>
    <updated>2015-08-11T23:35:32Z</updated>
    <category term="kernel"/>
    <category term="history"/>
    <category term="interview"/>
    <content type="html">&lt;p&gt;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 &lt;a href="http://www.nes.ru/en/people/catalog/s/andrei-savochkin" target="_blank" rel="nofollow"&gt;got a PhD in Economics and is now an Assistant Professor&lt;/a&gt;, while OpenVZ is still here. Read on for this great piece of memorabilia.&lt;/p&gt;
&lt;hr /&gt;
  &lt;div class=""&gt;&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Andrey is now working to get OpenVZ merged into the mainline Linux kernel explaining, "&lt;i&gt;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.&lt;/i&gt;"  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.&lt;/p&gt;

&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: Please share a little about yourself and your background...&lt;/p&gt;
&lt;p&gt;&lt;a href="http://static.openvz.org/lj/andrey.jpg" target="_blank" target="_blank" rel="nofollow"&gt;&lt;img src="https://imgprx.livejournal.net/fc5cb3a79a52171af6c85decc063cf43552bc0c9/pppAbCl-MXRZS8GXU_zKHn75X5TCI6gKZM97Rn0qD4t6DTwXpOTYEPwFDbhXqQcSI74n8DBJjdByTOxmqk4Igw" align="left" border="0" fetchpriority="high" /&gt;&lt;/a&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: I live in Moscow, Russia, and work for &lt;a href="http://www.swsoft.com/" target="_blank" target="_blank" rel="nofollow"&gt;SWsoft&lt;/a&gt;.  My two major interests in life are mathematics and computers, and I was unable to decide for a long time which one I preferred.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  What is your involvement with the OpenVZ project?&lt;/p&gt;

&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: The OpenVZ project has kernel and userspace parts. For the kernel part, we have been using the a development model close to the model of the mainstream Linux kernel, and for a long time I accumulated and reviewed OpenVZ kernel patches and prepared "releases". Certainly, I've been contributing a lot of code to OpenVZ.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  What do you mean when you say that your development model is close to the kernel development model?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: Linux kernel development model implies that the developers can't directly add their changes to the main code branch, but publish their changes. Other developers can review and provide comments, and, more importantly, there is a dedicated person who reviews all the changes, asks for corrections or clarifications, and finally incorporates the changes into the main code branch.  This model is extremely rare in producing commercial software, and in the open source software world only some projects use it. Linux kernel has been using this model from the beginning quite effectively.&lt;/p&gt;
&lt;p&gt;In my opinion, this model is very valuable for software that has high reliability requirements and, at the same time, is complex and difficult to debug by traditional means (such as debuggers, full state dump on failure, and so on).&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  OpenVZ is described as an "Operating System-level server virtualization solution".  What does this mean?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:  First, it is a virtualization solution, that is, it enables multiple environments (compartments) on a single physical server, and each environment looks like and provides the same functionality as a dedicated server.  We call these environments Virtual Private Servers (VPSs), or Virtual Environments (VEs). VPSs on a single physical server are isolated from each other, and also they are isolated from the physical hardware. Isolation from the hardware allows to implement on top of OpenVZ an automated migration of VPSs between servers that does not require any reconfiguration for running the VPSs on a very different hardware. A fair and efficient resource management mechanism is also included, as one of the most important components for a virtualization solution.&lt;/p&gt;
&lt;p&gt;Second, OpenVZ is an operating system-level solution, virtualizing access to the operating system, not to the hardware. There are many well-known hardware-level virtualization solutions, but operating system-level virtualization architecture gives many advantages over them. OpenVZ has better performance in some areas, considerably better scalability and VPS density, and provides unique management options in comparison with hardware-level virtualization solutions.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  How many VPSs can you have on one piece of hardware?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: That depends on the hardware and the "size" of VPSs and applications in them. For experimental purposes OpenVZ can run hundreds of small VPSs at the same time; in production environment -- tens of VPSs. Virtuozzo has higher density and can run hundreds production VPSs.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  When you talk about the migration of VPSs between servers, do you mean that a VPS can be running on one server and then migrate to another server where it will continue running, somewhat like a cluster?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: OpenVZ VPS will be stopped and started again, so there will be some downtime.  But this migration doesn't require any reconfiguration or other manual intervention related to IP addresses, drivers, partitions, device names or anything else. That means in the first place that taking hardware offline for maintenance or upgrade, replacement of hardware and similar things become much more painless, and this is a certain advantage of virtualization. Then, since OpenVZ allows to fully automate manipulations with VPS as a whole, it makes implementation of load balancing (as well as fail-over and other features of clustering) more easy.&lt;/p&gt;
&lt;p&gt;Virtuozzo has additional functionality called Zero-Downtime Migration.  It provides the ability to migrate a VPS from one server to another without downtime, without restart of processes and preserving network connections.  This functionality will be released as part of OpenVZ in April.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: Can you explain how the resource management mechanism works?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: In virtualization solutions resource management has two main requirements. First, it should cover enough resources to provide good isolation and security (and the isolation and security properties of resource management are one of the main differentiators between OpenVZ and VServer). Next, resource management should be flexible enough to allow high utilization of hardware when the resource demands of VPSs or virtual machines change.&lt;/p&gt;
&lt;p&gt;OpenVZ resource management operates the following resource groups:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;CPU
&lt;/li&gt;&lt;li&gt;memory
&lt;/li&gt;&lt;li&gt;pools of various OS objects
&lt;/li&gt;&lt;li&gt;disk quota
&lt;/li&gt;&lt;/ol&gt;

&lt;p&gt;Each group may have multiple resources, like low memory and high memory, or disk blocks and disk inodes. Resource configuration can be specified in terms of upper limits (which may be soft or hard limits, and impose an upper boundary on the consumption of the corresponding resource), in terms of shares (or weights) for resource distribution, or in terms of guarantees (the amount of resources guaranteed no matter what other VPSs are doing).&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  What are some common uses of server virtualization?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: Just examples are:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;Server consolidation -- moving the content of multiple servers into VPSs on a single server to reduce management (and hardware) costs.&lt;/p&gt;
&lt;/li&gt;&lt;li&gt;
&lt;p&gt;Disaster Recovery -- providing redundant environments for replication and fast data and application recovery.&lt;/p&gt;
&lt;/li&gt;&lt;li&gt;
&lt;p&gt;Improving server security -- by creating multiple VPSs and moving different services (HTTP, FTP, mail) into different VPSs.&lt;/p&gt;
&lt;/li&gt;&lt;li&gt;
&lt;p&gt;Creation of multiple environments and replication of environments for software testing and development.&lt;/p&gt;
&lt;/li&gt;&lt;li&gt;
&lt;p&gt;Hosting -- hosting service providers use Virtuozzo/OpenVZ to bridge the gap between and exceed shared and dedicated services.  Typical Virtuozzo/OpenVZ based hosting services include VPSs and Dynamic Servers which provide isolation, root access and guaranteed and burstable resources to customers.
&lt;/p&gt;&lt;/li&gt;&lt;/ol&gt;

&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  What prevents multiple operating systems running on the same server using OpenVZ from affecting each other?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:&lt;br /&gt;
Isolation between multiple VPSs consists of&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;separation of entities such as processes, users, files and so on, and
&lt;/li&gt;&lt;li&gt;resource control.
&lt;/li&gt;&lt;/ul&gt;

&lt;p&gt;Let's first speak about separation of processes and similar objects. There are two possible approaches to this separation: access control and separation of namespace. The former means that when someone tries to access an object, the kernel checks whether he has access rights;  the latter means that objects live in completely different spaces (for example, per-VPS lists), do not have pointers to objects in spaces other than their own and, thus, nobody can get access to objects to which he isn't supposed to get the access.&lt;/p&gt;
&lt;p&gt;OpenVZ uses both of these two approaches, choosing the approaches so that they do not reduce performance and efficiency and do not degrade isolation.&lt;/p&gt;
&lt;p&gt;In the theory of security, there are strong arguments in favor of both of these approaches.  For a long period of time different military and national security agencies in their publications and solutions preferred the first approach, accompanying it with logging. Many authors on different occasions advocate for the second approach. In our specific task, virtualization of the Linux kernel, I believe that the most important step is to identify the objects that need to be separated, and this step is absolutely same for both approaches. However, depending on the object type and data structures these two approaches differ in performance and resource consumption. For search in long lists, for example, namespace separation is better, but for large hash tables access control is better. So, the way the isolation is implemented in OpenVZ provides both safety and efficiency.&lt;/p&gt;
&lt;p&gt;Resource control is the other very important part of VPS isolation.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: When relying on namespace separation, what prevents a process in one VPS from writing to a random memory address that just happens to be used by another VPS?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: Processes can't access physical memory at random addresses. They only have their virtual address space and, additionally, can get access to some named objects: processes identified by a numeric ID, files identified by their path and so on. The idea of namespace separation is to make sure that a process can identify only those objects that it is authorized to access.  For other objects, the process won't get "permission denied" error, it will be unable to see them instead.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: Can you explain a little about how resource control provides virtual private server isolation?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: Resource control is very related to resource management.  It ensures that one VPS can't harm others through excessive use of some resources.  If one VPS had been able to easily take down the whole server by exhausting some system resource, we couldn't say that VPSs are really isolated from each other.  Implementing resource control, we in OpenVZ tried to prevent not only situations when one VPS can bring down the whole server, but also possibilities to cause significant performance drop for other VPSs.&lt;/p&gt;
&lt;p&gt;One of part of resource control is accounting and management of CPU, memory, disk quota, and other resources used by each VPS.  The other part is virtualization of system-wide limits.  For instance, Linux provides a system-wide limit on the number of IPC shared memory segments.  For complete isolation, this limit should apply to each VPS separately - otherwise, one VPS can use all IPC segments and other VPS will get nothing.  But certainly, most difficult part of resource control is accounting and management of resources like CPU and system memory.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  How does OpenVZ improve upon other virtualization projects, such as VServer?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: First of all, OpenVZ is a completely different project than VServer and has different code base.&lt;/p&gt;
&lt;p&gt;OpenVZ has bigger feature set (including, for example, netfilter support inside VPSs) and significantly better isolation, Denial-of-Service protection and general reliability. Better isolation and DoS protection comes from OpenVZ resource management system, which includes hierarchical CPU scheduler and User Beancounter patch to control the usage of memory and internal kernel objects. Also, we've invested a lot of efforts in the creation of the system of quality assurance, and now we have people who manually test OpenVZ as well as a large automated testing system.&lt;/p&gt;
&lt;p&gt;Virtuozzo, a virtualization solution built on the same core as OpenVZ, provides much more features, has better performance characteristics and includes many additional management capabilities and tools.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  What are some examples of hardware-level virtualization solutions?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: VMware, Xen, User Mode Linux.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  How does OpenVZ compare to Xen?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: OpenVZ has certain advantages over Xen.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;OpenVZ allows to utilize system resources such as memory and disk space much more efficiently, and because of that has better performance on memory-critical workloads.  OpenVZ does not run separate kernel in each VPS and saves memory on kernel internal data. However, even bigger efficiency of OpenVZ comes from dynamic resource allocation.  Using Xen, you need to specify in advance the amount of memory for each virtual machine and create disk device and filesystem for it, and your abilities to change settings later on the fly are very limited.  When running multiple VPSs, at each moment some VPSs are handling load burst and are busy, some are less busy and some are idle, hence the dynamic assignment of resources in OpenVZ can significantly improve the utilization of resources.  With Xen, you have to slice the server for the worst-case scenario and maximal resource usage by each VPS;  with OpenVZ you usually can slice basing on average usages.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;OpenVZ provides more management capabilities and management tools. To start, OpenVZ has from out of the box ability to immediately create VPSs based on various Linux distributions, without preparation of disk images, installing hundreds of packages and so on. But most importantly, OpenVZ has the ability to access files and start from the host system programs inside VPS. It means that a damaged VPS (having lost network access or unbootable) can be easily repaired from the host system, and that a lot of operations related to management, configuring or software upgrade inside VPSs can be easily scripted and executed from the host system. In short, managing Xen virtual machines is like managing separate servers, but managing a group of VPSs on one computer is more like managing a single multi-user server.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Operating system inside Xen virtual machine is not necessarily able to use all capabilities of the hardware;  for instance, support of SMP and more that 4GB of RAM inside virtual machines will appear only in Xen 3.0. OpenVZ is as scalable as Linux when hardware capabilities increase. SMP and more than 4GB have been supported in OpenVZ from the very beginning.  Recently we've built OpenVZ for x86_64 platform, and it was a straightforward job not requiring going into architecture details.  So, OpenVZ is far more hardware independent than Xen, and hence is able to start to use new hardware capabilities much faster.
&lt;/p&gt;&lt;/li&gt;&lt;/ol&gt;
&lt;p&gt;There is one point where Xen will have certain advantage over OpenVZ.  In version 3.0, Xen is going to allow to run Windows virtual machines on Linux host system (but it isn't possible in the stable branch of Xen).&lt;/p&gt;
&lt;p&gt;Again, I need to note that the above describes my opinion about the main differences between OpenVZ and Xen. Virtuozzo has many additions to OpenVZ, and, for instance, there is Virtuozzo for Windows solution.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  How does OpenVZ compare to User Mode Linux?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:&lt;br /&gt;
What I've said before about advantages of OpenVZ over Xen also apply when OpenVZ is compared with User Mode Linux.&lt;/p&gt;
&lt;p&gt;The unique feature of User Mode Linux is that you can run it under standard debuggers for studying Linux kernel in depth.  In other aspects, User Mode Linux does not have as many features as Xen, and Xen is superior in performance and stability.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  Is OpenVZ portable?  That is, can we expect to see the technology ported to other kernels?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: Well, OpenVZ is portable between different Linux kernels (but the amount of efforts to port between 2 kernels certainly depends on how different the kernels are).  On our FTP there are OpenVZ ports to SLES 10, Fedora Core 5 kernels. The ideas of OpenVZ are broadly portable, and we even had them implemented on FreeBSD kernel (but by now this FreeBSD port has been dropped).&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:&lt;br /&gt;
Why was the FreeBSD port dropped?&lt;br /&gt;
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:&lt;br /&gt;
We decided to focus on Linux version to implement new ideas as fast as possible.
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: How widely used is OpenVZ?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: OpenVZ in its current form has just been released to the public, but we've already got considerable number of downloads (and questions). Virtuozzo, a superset of OpenVZ, already has a large number of installations. I'd estimate that currently 8,000+ servers with 400,000 VPSs on them run Virtuozzo/OpenVZ code.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  Is there any plan to try and get OpenVZ merged into the mainline Linux kernel?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: Yes, we'd like to get it merged into the mainstream Linux and are working in that direction.  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. Virtualization will become more demanded with the growth of hardware capabilities, such as multi-core systems that are currently in the Intel roadmap.  So, I believe that when OpenVZ is merged into the mainstream, Linux will instantly become more attractive and more convenient in many usage scenarios.  That's why I think OpenVZ project is so interesting project, and that's why I've invested so much of my time into it.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  How large are the changes required in the Linux kernel to support OpenVZ?  Can they be broken into small logical pieces?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: The current size of the OpenVZ kernel patch is about 2MB (70,000 lines). This size is not small, but it is less than 10% of the average size of the changes between minor versions in 2.6 kernel branch (e.g., 2.6.12 to 2.6.13).  OpenVZ patch split into major parts is presented here [ed: dead link].  OpenVZ code can also be viewed and downloaded from GIT repository at &lt;a href="http://git.openvz.org/" target="_blank" rel="nofollow"&gt;http://git.openvz.org/&lt;/a&gt;. One of the large parts (about 25%) is various stability fixes, which we are submitting to the mainstream.  Then comes virtualization itself, general management of resources, CPU scheduler, and so on.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:&lt;br /&gt;
What efforts have been made so far to try and get OpenVZ merged into the kernel?&lt;br /&gt;
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:&lt;br /&gt;
OpenVZ patch was split into smaller pieces, easier for us to explain and for the community to accept.  Then, in the last couple of months, some virtualization pieces have been send to the linux-kernel mailing list and actively discussed there.&lt;/p&gt;
&lt;p&gt;The biggest argument was whether we want "partial" virtualization, when VPSs can have, for example, isolated network but common filesystem space.  In my personal opinion, in some perfect world such partial virtualization would be ok.  But in real life, subsystems of Linux kernel have a lot of dependencies on each other: every subsystem interacts with proc filesystem, for example.  Virtualization is cheap, so its easier to to have complete isolation, both from the implementation point of view and then for use and management of VPSs by users.&lt;/p&gt;
&lt;p&gt;The process of submitting OpenVZ patches into the mainstream keeps going. Also, we are working with SuSE, RedHat (RHEL and Fedora Core), Xandros, and Mandriva to include OpenVZ in their distributions and make it available and well supported for maximum number of users.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:&lt;br /&gt;
What do you think is the biggest obstacle that could keep OpenVZ from being merged into the mainline Linux kernel?&lt;br /&gt;
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:&lt;br /&gt;
I don't see any serious obstacles. OpenVZ code is available, its functionality has been proven to be very useful - I think it is now running on 8,000+ servers. So, it is just a matter of continuing the discussion to make everyone involved agree what exactly we want to have in Linux and how technically we want to organize these new capabilities.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: You've referred to OpenVZ as a subset of Virtuozzo.  What is Virtuozzo, and what does it add over OpenVZ?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: OpenVZ is SWsoft's contribution to the community. Virtuozzo is a commercial product, built on the same core backend, with many additional features and management tools.&lt;/p&gt;
&lt;p&gt;Virtuozzo provides much more efficient resource sharing through VZFS filesystem, and better scalability and higher VPS per node density because of that;  new generation resource and service level management;  different system of OS and application templates;  tools for VPS migration between nodes and for conversion of a dedicated server into a VPS;  monitoring, statistics and traffic accounting tools;  additional management APIs and various GUI and Web-based tools, including self-management and recovery tools for VPS users and owners.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:&lt;br /&gt;
Are there plans to eventually release any of this additional functionality under the GPL?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: SWsoft, the company that I work for, is very positive about Open Source movement, and has been contributing a lot of code to the Open Source. OpenVZ is a big piece of code contributed to the community, and people working for our company have submitted many fixes to the mainstream Linux kernel not related to OpenVZ.  I believe it is very likely that many parts of our additional code working on top of OpenVZ will eventually be also released under GPL.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:&lt;br /&gt;
Why was a subset of Virtuozzo, OpenVZ, released as open source?&lt;br /&gt;
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:&lt;br /&gt;
The company believes that this code should belong to the community. The strength of Linux is that innovations spread fast and become available to everyone, and we should be in line with it. Moreover, we believe that virtualization must and will become a part of the OS, and we want to speed up this process.&lt;/p&gt;
&lt;p&gt;When it comes to the kernel parts of the code, GPL license just requires them to be released under GPL.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: How many people from SWsoft are working on OpenVZ?&lt;br /&gt;
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:&lt;br /&gt;
I don't think anyone at SWsoft works on OpenVZ 100% of his time. But, I guess, 15 to 20 people from SWsoft have made significant contributions to OpenVZ.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:&lt;br /&gt;
Do all improvements to Virtuozzo that could also benefit OpenVZ get merged into OpenVZ?&lt;br /&gt;
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;:&lt;br /&gt;
If some improvements were made in a course of Virtuozzo development but belong to the OpenVZ part, they would certainly be released. Everything that is related to core functionality, to virtualization, isolation and protection between VPSs is immediately pushed from Virtuozzo to OpenVZ.
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:  What other kernel projects have you contributed to?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: Well, I've been contributing to the Linux kernel here and there from 1996. Historically, the area where I contributed most code was networking, including TCP, routing and other parts.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;:&lt;br /&gt;
What are some examples of the networking code that you've contributed?&lt;br /&gt;
&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: Many pieces here and there. I maintained eepro100 driver for some time, I wrote inetpeer cache, contributed some pieces to window management algorithm and MTU discovery in TCP, to routing code, and so on.&lt;/p&gt;
&lt;p&gt;Well, OpenVZ and especially its resource management part will be another my major contribution.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: How do you enjoy spending your free time when you're not working on OpenVZ?&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Andrey Savochkin&lt;/i&gt;: I like reading and read a lot. In music, I'm very fond of the Baroque period and try to attend every such concert in Moscow. When I have time for a longer vacation, I enjoy diving.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Jeremy Andrews&lt;/i&gt;: Thanks for all your time in answering my questions!&lt;/p&gt;
&lt;/div&gt;
&lt;a name='cutid1-end'&gt;&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:52855</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/52855.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=52855"/>
    <title>New OpenVZ bug tracker</title>
    <published>2015-08-11T12:54:36Z</published>
    <updated>2015-08-11T12:54:36Z</updated>
    <category term="bug tracker"/>
    <category term="bugs"/>
    <content type="html">We are pleased to announce the &lt;a href="https://bugs.openvz.org/" target="_blank" rel="nofollow"&gt;new OpenVZ bug tracker&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;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 &lt;a href="https://src.openvz.org/passwordreset" target="_blank" rel="nofollow"&gt;reset your password&lt;/a&gt;.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:52710</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/52710.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=52710"/>
    <title>OpenVZ developers workplaces</title>
    <published>2015-08-09T18:12:33Z</published>
    <updated>2015-08-09T20:44:34Z</updated>
    <category term="team"/>
    <category term="photos"/>
    <category term="workplace"/>
    <content type="html">When we &lt;a href="https://twitter.com/_openvz_/status/629443602096107520" target="_blank" rel="nofollow"&gt;asked&lt;/a&gt; in Twitter about desired themes someone &lt;a href="https://twitter.com/vjanzen/status/629521336096956416" target="_blank" rel="nofollow"&gt;asked&lt;/a&gt; about photos of OpenVZ Team's workplace. So here we go.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Kir Kolyshkin (ex-community manager of OpenVZ project)&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="https://plus.google.com/+KirillKolyshkin/photos/photo/6048035462091711378?pid=6048035462091711378&amp;amp;oid=114658067490332530482" target="_blank" rel="nofollow"&gt;&lt;img src="https://lh4.googleusercontent.com/-rlWVO6AcYgs/U-7wNXrxI5I/AAAAAAABPuA/Zxa-2JggH_Q/w873-h655-no/14%2B-%2B1" alt="" width="900" fetchpriority="high" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Alexey Kuznetsov (one of the authors of TCP/IP stack at Linux, &lt;a href="https://en.wikipedia.org/wiki/Iproute2" target="_blank" rel="nofollow"&gt;iproute2&lt;/a&gt;), maintainer of network subsystem at Linux in 2000-2003 &lt;/b&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.opennet.ru/opennews/art.shtml?num=38016" target="_blank" rel="nofollow"&gt;&lt;img src="https://imgprx.livejournal.net/a7f4c747b4a100b20f6323b2ed777acfaa6b10f8/pppAbCl-MXRZS8GXU_zKHnIma7cidgLKe7t_cysw9ljF9qjC3XL3catWRpfrhvMTQ27ElvUzoPDj3MCXFzyaku5tCkhHUX4_yKAOUZgaZ7zrRzG9F7NleR45PJCztbeT" alt="" width="900" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Pavel Emelyanov (maintainer of &lt;a href="http://criu.org/Main_Page" target="_blank" rel="nofollow"&gt;CRIU project&lt;/a&gt;)&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;&lt;img src="https://xakep.ru/wp-content/uploads/2015/06/emelyanov.jpg" alt="" width="900" loading="lazy" /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:52465</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/52465.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=52465"/>
    <title>Join Our Team at ContainerCon 2015 Seattle</title>
    <published>2015-08-06T16:43:18Z</published>
    <updated>2015-08-06T16:43:18Z</updated>
    <category term="seattle"/>
    <category term="booth"/>
    <category term="containercon"/>
    <content type="html">We're very excited that this year OpenVZ will have exhibit space at &lt;a href="http://events.linuxfoundation.org/events/containercon" target="_blank" rel="nofollow"&gt;ContainerCon&lt;/a&gt; in Seattle, August 17-19. We will be showing and demoing OpenVZ server virtualization, answering questions and so on. &lt;br /&gt;&lt;br /&gt;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 (sergeyb@openvz.org) your details and we'll discuss arrangements.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:52010</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/52010.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=52010"/>
    <title>OpenVZ upgrade and migration script</title>
    <published>2015-08-06T15:40:33Z</published>
    <updated>2015-08-06T15:41:27Z</updated>
    <category term="openvz"/>
    <category term="upgrade"/>
    <content type="html">&lt;i&gt;Author:&lt;/i&gt; Andre Moruga&lt;br /&gt;&lt;br /&gt;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  (&lt;a href="https://openvz.org/Virtuozzo_7_Technical_Preview_-_Containers" target="_blank" rel="nofollow"&gt;first technical preview&lt;/a&gt; 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.&lt;br /&gt;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.&lt;br /&gt;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.&lt;br /&gt;The script is available at &lt;a href="https://src.openvz.org/projects/OVZL/repos/ovztransfer/browse/ovztransfer.sh" target="_blank" rel="nofollow"&gt;https://src.openvz.org/projects/OVZL/repos/ovztransfer/browse/ovztransfer.sh&lt;/a&gt;. Its usage is simple: run it in the source (old) node, and specify destination host IP and list of containers to be migrated:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
 $ ./ovztransfer.sh TARGET_HOST SOURCE_VEID0:[TARGET_VEID0] ...
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;For example:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
 ./ovztransfer.sh 10.1.1.3 101 102 103
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;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).&lt;br /&gt;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.&lt;br /&gt;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.&lt;br /&gt;If you tried it and want to share your thoughts, email to OpenVZ user group at &lt;a href="mailto:users@openvz.org" target="_blank" rel="nofollow"&gt;users@openvz.org&lt;/a&gt;.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:51718</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/51718.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=51718"/>
    <title>OpenVZ survey results (May - July 2015)</title>
    <published>2015-07-31T17:50:01Z</published>
    <updated>2015-07-31T21:30:26Z</updated>
    <category term="openvz"/>
    <category term="survey"/>
    <content type="html">Now we are ready to publish results of survey which was in May-July 2015.&lt;br /&gt;There are 91 people participated. votes gathered from 19 May till 1 July 2015.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;How long do you use OpenVZ?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/YqaIwSD" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/YqaIwSD.png" title="source: imgur.com" fetchpriority="high" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;What are the reasons for choosing OpenVZ among other container-based solutions?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/UZ802TG" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/UZ802TG.png" title="source: imgur.com" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;What do you use OpenVZ for&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/2XtjH6i" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/2XtjH6i.png" title="source: imgur.com" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;How big is your team supporting OpenVZ deployment&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/qPd8Bdr" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/qPd8Bdr.png" title="source: imgur.com" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;Further plans with OpenVZ&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/H5FHbvZ" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/H5FHbvZ.png" title="source: imgur.com" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;How many hardware servers do you use with OpenVZ?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;table&gt;
  &lt;tr&gt;
    &lt;td&gt;Voices&lt;/td&gt;
    &lt;td&gt;Amount of servers&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;10&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;3&lt;/td&gt;
&lt;td&gt;20-30&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;15&lt;/td&gt;
&lt;td&gt;&amp;lt;10&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;5&lt;/td&gt;
&lt;td&gt;10-20&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;100+&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;10+&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;~100&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;80&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;1600&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;160+&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;60&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;45&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;50&lt;/td&gt;
  &lt;/tr&gt;
  &lt;tr&gt;
    &lt;td&gt;1&lt;/td&gt;
&lt;td&gt;None now (using upstream kernels)&lt;/td&gt;
  &lt;/tr&gt;
&lt;/table&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;What features are absent in OpenVZ from your point of view?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;Note: Answers with more than 1 voice&lt;br /&gt;&lt;br /&gt;&lt;table&gt;
&lt;tr&gt;&lt;td&gt;Voices&lt;/td&gt;&lt;td&gt;Answer&lt;/td&gt;&lt;td&gt;Description&lt;/td&gt;&lt;td&gt;Current decision&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;7&lt;/td&gt;&lt;td&gt;Modern kernel support (at least RHEL7 kernel)&lt;/td&gt;&lt;td&gt;Reasons: There are a two main problems with stable 2.6.32 patches: modern hardware requires 3.x kernels, and latest user-space utilities (i.e. systemd) doesn't work with 2.6.x kernels.&lt;br /&gt;It's great, I just really hate being stuck with such an old kernel. I know it gets updated regularly but it's still technically almost 6 years old.&lt;/td&gt;&lt;td&gt;&lt;a href="https://openvz.org/Virtuozzo_7_Technical_Preview_-_Containers" target="_blank" rel="nofollow"&gt;In progress&lt;/a&gt;&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;5&lt;/td&gt;&lt;td&gt;Good web interface (cluster management: adding nodes, quorum management, logs, etc )&lt;/td&gt;&lt;td&gt;An entry-level web panel. OpenVZ Web Panel seems somewhat popular but I've always been turned off by its reliance on Ruby...  and unsure of its security-related testing. The recent Packt Publishing boot, "Essential OpenVZ" spends half of the book covering  OpenVZ Web Panel. It would be nice if OWP was adopted in some way or replaced with something similar to offer an entry level  web-based management system like VMware does with ESXi. If considered, I'd strongly recommend that there is a clear  differentiation between the features in the entry-level web-panel and those commercially offered. I know a few companies are  selling OpenVZ compatible web-interfaces... like SolusVM, Proxmox VE, etc.&lt;/td&gt;&lt;td&gt;There is no final decision about WebUI in Vz7. But we will have &lt;a href="https://openvz.org/LibVirt" target="_blank" rel="nofollow"&gt;libvirt in base of Vz7&lt;/a&gt;. It allows to use oVirt and virt-manager at least.&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;4&lt;/td&gt;&lt;td&gt;ZFS support&lt;/td&gt;&lt;td&gt;* native ZFS support for container files instead of ploop&lt;br /&gt;* ZFS integration (ZFS-aware tools for creation/cloning containers/creating snapshots)&lt;br /&gt;* ZFS integration (e.g. quota support)&lt;/td&gt;&lt;td&gt;There is no final decision regarding ZFS in VZ7.&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;4&lt;/td&gt;&lt;td&gt;Upstream kernel support and availability in Linux distributives&lt;/td&gt;&lt;td&gt;Better integration with LXC in the mainline kernel. I think LXC and Docker could be a stepping stone to OpenVZ / Virtuozzo... if the  OpenVZ tools worked reasonably well with LXC in the mainline kernel... and it was clear to the user what features they could gain  if they moved up to OpenVZ and/or Virtuozzo.&lt;/td&gt;&lt;td&gt;There is no final decision about it.&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;2&lt;/td&gt;&lt;td&gt;Better integration with OpenStack (especially networking)&lt;/td&gt;&lt;td&gt;&lt;/td&gt;&lt;td&gt;&lt;a href="https://openvz.org/Setup_OpenStack_with_Virtuozzo_7" target="_blank" rel="nofollow"&gt;In progress&lt;/a&gt;&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;2&lt;/td&gt;&lt;td&gt;Support of Debian 8.0 Jessie&lt;/td&gt;&lt;td&gt;&lt;/td&gt;&lt;td&gt;There is no final decision yet.&lt;/td&gt;&lt;/tr&gt;
&lt;/table&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;What 3rd party technologies/products do you use with OpenVZ?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Note:&lt;/b&gt; Answers with more than 1 voice.&lt;br /&gt;&lt;br /&gt;&lt;table&gt;
&lt;tr&gt;&lt;td&gt;Votes&lt;/td&gt;&lt;td&gt;Product&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;9&lt;/td&gt;&lt;td&gt;Proxmox with KVM and OpenVZ&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;4&lt;/td&gt;&lt;td&gt;KVM&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;3&lt;/td&gt;&lt;td&gt;Docker&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;3&lt;/td&gt;&lt;td&gt;Pacemaker (HA management)&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;2&lt;/td&gt;&lt;td&gt;Ansible&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;2&lt;/td&gt;&lt;td&gt;cPanel&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;2&lt;/td&gt;&lt;td&gt;SolusVM&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;2&lt;/td&gt;&lt;td&gt;ZFSonLinux&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;2&lt;/td&gt;&lt;td&gt;Zabbix&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td&gt;2&lt;/td&gt;&lt;td&gt;Asterisk&lt;/td&gt;&lt;/tr&gt;
&lt;/table&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;Do you have plans to buy a commercial version of Virtuozzo (Parallels Server Bare Metal/Parallels Cloud Server)?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/xMaBATk" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/xMaBATk.png" title="source: imgur.com" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;What are the reasons preventing to buy a commercial version?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Note:&lt;/b&gt; Answers with more than 1 voice.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Satisfied by OpenVZ or other opensource solutions (19 asnwers)&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;I wasn't actually aware there was a commercial version so I don't know what the difference is. The free version has been working well for us though.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;We use it in small internal IT primarily so no need in Virtuozzo services - all things we can do by using standart OVZ tools.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;We are happy with the open source version.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;OpenVZ is very simple and good work for me.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Not needed, anything works fine without any problem.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;OpenVZ does all I need&lt;/li&gt;&lt;br /&gt;&lt;li&gt;OpenVZ is good enough for us&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Not needed at the time.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Can't see why we need it.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;We have all needed features in openvz.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;enough openvz&lt;/li&gt;&lt;br /&gt;&lt;li&gt;no reasons to buy, lot's of free solutions.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Why?&lt;/li&gt;&lt;br /&gt;&lt;li&gt;We have one and we don't feel that we need to buy another.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;What is the reason to buy?&lt;/li&gt;&lt;br /&gt;&lt;li&gt;I tried to use comersial version and stay on openvz free version.&lt;/li&gt;&lt;br /&gt;&lt;li&gt; The available opensource products are sufficient&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Not needed&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Our current needs are satisfied with docker, openstack + kvm and openvz for certain deployments where docker is not enough and kvm is too much.&lt;/li&gt;&lt;br /&gt;&lt;/ul&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Very high price of commercial version (10 answers)&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;Strange prices, strange sales, enterprise orientation&lt;li&gt;&lt;br /&gt;&lt;li&gt;Cost, scale.&lt;li&gt;&lt;br /&gt;&lt;li&gt;Huge cost.&lt;li&gt;&lt;br /&gt;&lt;li&gt;budget&lt;li&gt;&lt;br /&gt;&lt;li&gt;no project funding and no use case&lt;li&gt;&lt;br /&gt;&lt;li&gt;No money&lt;li&gt;&lt;br /&gt;&lt;li&gt;Limited budget&lt;li&gt;&lt;br /&gt;&lt;/ul&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;Do you ever contribute to OpenVZ project?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/IYUb6Pw" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/IYUb6Pw.png" title="source: imgur.com" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;What commercial products do you use in parallel with OpenVZ (Containers for Windows, Virtuozzo, Plesk etc).&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/xztjRBJ" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/xztjRBJ.png" title="source: imgur.com" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;Is there anything that could motivate you to switch to a supported/commercial version (Virtuozzo)?&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://imgur.com/9PsnK4O" target="_blank" rel="nofollow"&gt;&lt;img src="https://i.imgur.com/9PsnK4O.png" title="source: imgur.com" loading="lazy" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;&lt;a name='cutid1-end'&gt;&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:51526</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/51526.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=51526"/>
    <title>Publishing of Virtuozzo 7 Technical Preview - Containers</title>
    <published>2015-07-27T20:12:02Z</published>
    <updated>2015-07-27T20:12:02Z</updated>
    <category term="openvz"/>
    <category term="virtuozzo"/>
    <content type="html">We are pleased to announce the official release of Virtuozzo 7.0 Technical Preview - Containers.&lt;br /&gt;&lt;br /&gt;It has been &lt;a href="http://openvz.org/History" target="_blank" rel="nofollow"&gt;more than a decade&lt;/a&gt; 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.&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;This Virtuozzo 7.0 Technical Preview offers the following significant improvements:&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;Virtuozzo 7 is based on &lt;a href="https://openvz.org/Download/kernel/rhel7-testing" target="_blank" rel="nofollow"&gt;RHEL7 and Kernel 3.10+&lt;/a&gt;&lt;/li&gt;&lt;br /&gt;&lt;li&gt;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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;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.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://openvz.org/VCMMD" target="_blank" rel="nofollow"&gt;VCMM 4th generation of memory manager&lt;/a&gt;. 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.&lt;/li&gt;&lt;br /&gt;&lt;/ul&gt;&lt;br /&gt;&lt;br /&gt;Read more details in &lt;a href="http://lists.openvz.org/pipermail/announce/2015-July/000617.html" target="_blank" rel="nofollow"&gt;official announce&lt;/a&gt;.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:51375</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/51375.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=51375"/>
    <title>[Security] Important information about latest kernel	updates</title>
    <published>2015-07-23T13:40:11Z</published>
    <updated>2015-07-24T10:13:01Z</updated>
    <category term="kernel"/>
    <category term="security"/>
    <content type="html">Last time we released a few kernel updates with security fixes:&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;br /&gt;&lt;li&gt;Critical security issue was fixed in &lt;a href="https://openvz.org/Download/kernel/rhel6/042stab108.7" target="_blank" rel="nofollow"&gt;OpenVZ kernel 2.6.32-042stab108.7&lt;/a&gt;&lt;/li&gt;&lt;br /&gt;&lt;br /&gt;OpenVZ kernel team discovered security issue that allows privileged user inside&lt;br /&gt;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&lt;br /&gt;&lt;br /&gt;Note: RHEL5-based kernels 2.6.18, Red Hat and mainline kernels are not affected.&lt;br /&gt;&lt;br /&gt;&lt;li&gt;8 security issues fixed in &lt;a href="https://openvz.org/Download/kernel/rhel6/042stab108.8" target="_blank" rel="nofollow"&gt;OpenVZ kernel 2.6.32-042stab108.8&lt;/a&gt;&lt;/li&gt;&lt;br /&gt;&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://www.redhat.com/security/data/cve/CVE-2014-3184.html" target="_blank" rel="nofollow"&gt;CVE-2014-3184&lt;/a&gt; HID: off by one error in various _report_fixup routines&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://www.redhat.com/security/data/cve/CVE-2014-3940.html" target="_blank" rel="nofollow"&gt;CVE-2014-3940&lt;/a&gt; missing check during hugepage migration&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://www.redhat.com/security/data/cve/CVE-2014-4652.html" target="_blank" rel="nofollow"&gt;CVE-2014-4652&lt;/a&gt; ALSA: control: protect user controls against races &amp; memory disclosure&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://www.redhat.com/security/data/cve/CVE-2014-8133.html" target="_blank" rel="nofollow"&gt;CVE-2014-8133&lt;/a&gt; x86: espfix(64) bypass via set_thread_area and CLONE_SETTLS&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://www.redhat.com/security/data/cve/CVE-2014-8709.html" target="_blank" rel="nofollow"&gt;CVE-2014-8709&lt;/a&gt; net: mac80211: plain text information leak&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://www.redhat.com/security/data/cve/CVE-2014-9683.html" target="_blank" rel="nofollow"&gt;CVE-2014-9683&lt;/a&gt; buffer overflow in eCryptfs&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://www.redhat.com/security/data/cve/CVE-2015-0239.html" target="_blank" rel="nofollow"&gt;CVE-2015-0239&lt;/a&gt; kvm: insufficient sysenter emulation when invoked from 16-bit code&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href="https://www.redhat.com/security/data/cve/CVE-2015-3339.html" target="_blank" rel="nofollow"&gt;CVE-2015-3339&lt;/a&gt; kernel: race condition between chown() and execve()&lt;/li&gt;&lt;br /&gt;&lt;/ul&gt;&lt;br /&gt;&lt;br /&gt;Note: RHEL5-based kernels 2.6.18 are not affected.&lt;br /&gt;&lt;br /&gt;It is quite critical to install latest OpenVZ kernel to protect your systems.&lt;br /&gt;Please reboot your nodes into fixed kernels or install live patches from &lt;a href="http://kernelcare.com/" target="_blank" rel="nofollow"&gt;Kernel Care&lt;/a&gt;.&lt;br /&gt;&lt;/ul&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:51003</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/51003.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=51003"/>
    <title>Parallels and Docker: Not Just Competition</title>
    <published>2015-07-03T17:03:29Z</published>
    <updated>2015-07-23T13:41:50Z</updated>
    <category term="p.haul"/>
    <category term="openvz"/>
    <category term="docker"/>
    <category term="libcontainer"/>
    <category term="criu"/>
    <content type="html">&lt;img alt="" height="600" src="https://ic.pics.livejournal.com/estetus/12957684/357/357_900.jpg" title="Pavel Emelyanov, CRIU project mantainer" width="900" fetchpriority="high" /&gt;&amp;lt;/p&amp;gt;&lt;p class=""&gt;&lt;br /&gt;&lt;span class=""&gt;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.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style="line-height: 1.4;"&gt;One good example is the &lt;a href="https://github.com/docker/libcontainer" target="_blank" rel="nofollow"&gt;libcontainer&lt;/a&gt; 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 &lt;a href="https://openvz.org/" target="_blank" rel="nofollow"&gt;OpenVZ&lt;/a&gt; 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 &lt;a href="https://github.com/docker/libcontainer" target="_blank" rel="nofollow"&gt;libcontainer&lt;/a&gt;.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;span class=""&gt;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 &amp;quot;standardize&amp;quot; containers&amp;#39; 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&amp;#39;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&amp;#39;d like to participate to be able to control both the development and results. Secondly, we&amp;#39;ll be able to achieve the dream of many users to run Docker containers on our stable kernel.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;span style="line-height: 1.4;"&gt;Recently, we announced jointly with Docker that &lt;a href="https://openvz.org/Virtuozzo" target="_blank" rel="nofollow"&gt;Virtuozzo&lt;/a&gt; (the successor of OpenVZ and Parallels Cloud Server) supports Docker containers and allows creating &amp;quot;containers within containers&amp;quot;, i.e. use Docker inside &lt;a href="https://openvz.org/Virtuozzo" target="_blank" rel="nofollow"&gt;Virtuozzo&lt;/a&gt;.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;span class=""&gt;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 &amp;quot;freeze&amp;quot; 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&amp;#39;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.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;span class=""&gt;The live migration itself is performed by the &lt;a href="http://criu.org/P.Haul" target="_blank" rel="nofollow"&gt;P.Haul subproject&lt;/a&gt; that uses &lt;a href="http://criu.org/" target="_blank" rel="nofollow"&gt;CRIU&lt;/a&gt; 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.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;span class=""&gt;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.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;span class=""&gt;Migration can also include such actions as transferring container&amp;#39;s IP address, reregistering it with the management system (e.g., docker-daemon in Docker), handling container&amp;#39;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.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;span class=""&gt;Today &lt;a href="http://criu.org/" target="_blank" rel="nofollow"&gt;CRIU&lt;/a&gt; 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.&lt;/span&gt;&lt;/p&gt;&lt;p class=""&gt;&lt;span class=""&gt;The &lt;a href="http://criu.org/" target="_blank" rel="nofollow"&gt;CRIU&lt;/a&gt; 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.&lt;br /&gt;&lt;br /&gt;&lt;a href="https://xakep.ru/2015/06/22/parallels-i-docker/" target="_blank" rel="nofollow"&gt;via&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;a name='cutid1-end'&gt;&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:50776</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/50776.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=50776"/>
    <title>Analyzing OpenVZ Components with PVS-Studio</title>
    <published>2015-07-03T07:41:45Z</published>
    <updated>2015-07-16T11:20:34Z</updated>
    <category term="openvz"/>
    <category term="static analysis"/>
    <content type="html">&lt;b&gt;Author:&lt;/b&gt; Svyatoslav Razmyslov&lt;br /&gt;&lt;br /&gt;In order to demonstrate our analyzer's diagnostic capabilities, we analyze open-source projects and write articles to discuss any interesting bugs we happen to find. We always encourage our users to suggest interesting open-source projects for analysis, and note down all the suggestions we receive via e-mail. Sometimes they come from people closely related to the project we are asked to check. In this article, we will tell you about a check of the components of the OpenVZ project we have been asked to analyze by the project manager Sergey Bronnikov.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;h3&gt;About PVS-Studio and OpenVZ&lt;/h3&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/pvs-studio/" target="_blank" rel="nofollow"&gt;PVS-Studio&lt;/a&gt; is a static analyzer designed to detect errors in source code of C/C++ applications. It can be downloaded from the official website but is available for operating systems of the Windows family only. Therefore, to be able to analyze OpenVZ components in Linux, we had to use a PVS-Studio beta-version we once &lt;a href="http://www.viva64.com/en/b/0299/" target="_blank" rel="nofollow"&gt;used to check the Linux Kernel&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;&lt;a href="https://openvz.org/" target="_blank" rel="nofollow"&gt;OpenVZ&lt;/a&gt; is an operating system-level virtualization technology based on the Linux kernel and operating system. OpenVZ allows a physical server to run multiple isolated operating system instances, called containers, virtual private servers (VPSs), or virtual environments (VEs).&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Analysis results&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;OpenVZ components are small-sized projects, so there were relatively few warnings yet they were very characteristic of software written in C++.&lt;br /&gt;&lt;br /&gt;Troubles with pointers&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0205/" target="_blank" rel="nofollow"&gt;V595&lt;/a&gt; The 'plog' pointer was utilized before it was verified against nullptr. Check lines: 530, 531. CPackedProblemReport.cpp 530&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
void
CPackedProblemReport::appendSystemLog( CRepSystemLog * plog )
{
QString strPathInTemp = m_strTempDirPath + QString("/") +
QFileInfo( plog-&amp;gt;getName() ).fileName();
if( !plog )
{
QFile::remove( strPathInTemp );
return;
}
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;It's a genuine pointer handling bug. The 'plog' pointer is dereferenced right after entering the function and only then is checked for being valid.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0205/" target="_blank" rel="nofollow"&gt;V595&lt;/a&gt; The 'd' pointer was utilized before it was verified against nullptr. Check lines: 1039, 1041. disk.c 1039&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
int vzctl2_add_disk(....)
{
....
if (created)
destroydir(d-&amp;gt;path);
if (d)
free_disk(d);
return ret;
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;In this case, when the 'created' flag is set, the 'd' variable will be dereferenced, though the next code line suggests that the pointer may be null. This code fragment can be rewritten in the following way:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
int vzctl2_add_disk(....)
{
....
if (d)
{
if (created)
  destroydir(d-&amp;gt;path);
free_disk(d);
}
return ret;
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0205/" target="_blank" rel="nofollow"&gt;V595&lt;/a&gt; The 'param' pointer was utilized before it was verified against nullptr. Check lines: 1874, 1876. env.c 1874&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
int
vzctl2_env_set_veth_param(....,
                      struct vzctl_veth_dev_param *param,
                      int size)
{
int ret;
struct vzctl_ip_param *ip = NULL;
struct vzctl_veth_dev_param tmp = {};
memcpy(&amp;tmp, param, size);
if (param == NULL || tmp.dev_name_ve == NULL)
return VZCTL_E_INVAL;
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;The 'memcpy' function copies the contents of one memory area into another. The second function parameter is a pointer to the source address. The function contains a check of the 'param' pointer for null, but before that the pointer is used by the 'memcpy' function, which may cause a null-pointer dereferencing operation.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0205/" target="_blank" rel="nofollow"&gt;V595&lt;/a&gt; The 'units' pointer was utilized before it was verified against nullptr. Check lines: 607, 610. wrap.c 607&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
int vzctl_set_cpu_param(....)
{
....
if (weight != NULL &amp;&amp;
  (ret = vzctl2_env_set_cpuunits(param, *units * 500000)))
goto err;
if (units != NULL &amp;&amp;
  (ret = vzctl2_env_set_cpuunits(param, *units)))
goto err;
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;The analyzer's warning about the 'units' pointer being checked for null before being used may hint at a typo in this code. In the first condition, the 'weight' pointer being checked is not used. It should have probably looked like this:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
if (weight != NULL &amp;&amp;
(ret = vzctl2_env_set_cpuunits(param, *weight * 500000)))
goto err;
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;V668 There is no sense in testing the 'pRule' pointer against null, as the memory was allocated using the 'new' operator. The exception will be generated in the case of memory allocation error. PrlHandleFirewallRule.cpp 59&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
PRL_RESULT PrlHandleFirewallRule::Create(PRL_HANDLE_PTR phRule)
{
PrlHandleFirewallRule* pRule = new PrlHandleFirewallRule;
if ( ! pRule )
return PRL_ERR_OUT_OF_MEMORY;
*phRule = pRule-&amp;gt;GetHandle();
return PRL_ERR_SUCCESS;
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;The analyzer has detected an issue when a pointer value returned by the 'new' operator is compared to zero. If the 'new' operator fails to allocate a required amount of memory, the C++ standard forces the program to throw an std::bad_alloc() exception. Therefore, checking the pointer for null doesn't make sense. The developers need to check which kind of the 'new' operator is used in their code. If it is really set to throw an exception in case of memory shortage, then there are 40 more fragments where the program may crash.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Troubles with classes&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0247/" target="_blank" rel="nofollow"&gt;V630&lt;/a&gt; The 'malloc' function is used to allocate memory for an array of objects which are classes containing constructors and destructors. IOProtocol.cpp 527&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
/**
* Class describes IO package.
*/
class IOPackage {
public:
/** Common package type */
typedef quint32 Type;
....
};
IOPackage* IOPackage::allocatePackage ( quint32 buffNum )
{
return reinterpret_cast&lt;iopackage&gt;(
::malloc(IOPACKAGESIZE(buffNum))
);
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;The analyzer has detected a potential error related to dynamic memory allocation. Using malloc/calloc/realloc functions to allocate memory for C++ objects leads to a failure when calling the class constructor. The class fields are therefore left uninitialized, and probably some other important actions can't be accomplished as well. Accordingly, in some other place, the destructor can't be called when memory is freed through the free() function, which may cause resource leaks or other troubles.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0300/" target="_blank" rel="nofollow"&gt;V670&lt;/a&gt; The uninitialized class member 'm_stat' is used to initialize the 'm_writeThread' member. Remember that members are initialized in the order of their declarations inside a class. SocketClient_p.cpp 145&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
class SocketClientPrivate:protected QThread,
                      protected SocketWriteListenerInterface
{
....
SocketWriteThread m_writeThread;  //&amp;lt;==line 204
....
IOSender::Statistics m_stat;      //&amp;lt;==line 246
....
}
SocketClientPrivate::SocketClientPrivate (....) :
....
m_writeThread(jobManager, senderType, ctx, m_stat, this),
....
{
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;The analyzer has detected a potential bug in the class constructor's initialization list. Under the C++ standard, class members are initialized in the constructor in the same order they were declared in the class. In this case, the m_writeThread variable will be the first to be initialized instead of m_stat.&lt;br /&gt;&lt;br /&gt;So it may be unsafe to construct 'm_writeThread' using the 'm_stat' field as one of the arguments.&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0326/" target="_blank" rel="nofollow"&gt;V690&lt;/a&gt; The 'CSystemStatistics' class implements a copy constructor, but lacks the '=' operator. It is dangerous to use such a class. CSystemStatistics.h 632&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
class CSystemStatistics: public CPrlDataSerializer
{
public:
....
/** Copy constructor */
CSystemStatistics(const CSystemStatistics &amp;_obj);
/** Initializing constructor */
CSystemStatistics(const QString &amp;source_string);
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;There is a copy constructor for this class but its assignment operator has not been redefined.&lt;br /&gt;&lt;br /&gt;The &lt;a href="https://en.wikipedia.org/wiki/Rule_of_three_(C%252B%252B_programming)" target="_blank" rel="nofollow"&gt;"Rule of three"&lt;/a&gt; (also known as the "Law of the Big Three" or "The Big Three") is violated here. This rule claims that if a class defines one (or more) of the following it should probably explicitly define all three:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
destructor;
copy constructor;
copy assignment operator.
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;These three functions are special member functions automatically implemented by the compiler when they are not explicitly defined by the programmer. The Rule of Three claims that if one of these had to be defined by the programmer, it means that the compiler-generated version does not fit the needs of the class in one case and it will probably not fit in the other cases either and lead to runtime errors.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Other warnings&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0302/" target="_blank" rel="nofollow"&gt;V672&lt;/a&gt; There is probably no need in creating the new 'res' variable here. One of the function's arguments possesses the same name and this argument is a reference. Check lines: 367, 393. IORoutingTable.cpp 393&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
bool IOJobManager::initActiveJob (
SmartPtr&lt;jobpool&gt;&amp; jobPool,
const IOPackage::PODHeader&amp; pkgHeader,
const SmartPtr&lt;iopackage&gt;&amp; package,
Job*&amp; job,                               //&amp;lt;==
bool urgent )
{
....
while ( it != jobPool-&amp;gt;jobList.end() ) {
    Job* job = *it;                      //&amp;lt;==
    if ( isJobFree(job) ) {
        ++freeJobsNum;
        // Save first job
        if ( freeJobsNum == 0 ) {
            freeJob = job;
            firstFreeJobIter = it;
        }
    }
    ++it;
}
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;It is strongly recommended not to declare variables bearing the same names as function arguments. You should generally avoid having identical names for local and global variables. Otherwise, it may cause a variety of errors due to careless use of such variables. Besides incorrect program execution logic, you may face an issue when, for instance, a global pointer points to a local object which will be destroyed in the future, and since it takes some time before a memory area is cleared, this error will take an irregular character.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Other issues of this kind:&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0302/" target="_blank" rel="nofollow"&gt;V672&lt;/a&gt; There is probably no need in creating the new 'job' variable here. One of the function's arguments possesses the same name and this argument is a reference. Check lines: 337, 391. IOSendJob.cpp 391&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0302/" target="_blank" rel="nofollow"&gt;V672&lt;/a&gt; There is probably no need in creating the new 'res' variable here. One of the function's arguments possesses the same name and this argument is a reference. Check lines: 367, 393. IORoutingTable.cpp 393&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0225/" target="_blank" rel="nofollow"&gt;V610&lt;/a&gt; Undefined behavior. Check the shift operator '&amp;lt;&amp;lt;'. The left operand '~0' is negative. util.c 1046&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
int parse_ip(const char *str, struct vzctl_ip_param **ip)
{
....
if (family == AF_INET)
    mask = htonl(~0 &amp;lt;&amp;lt; (32 - mask));
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;The analyzer has detected a shift operation leading to undefined behavior. The reason behind it is that in the '~0' operation, the number will be inverted into signed int and therefore there will be a negative number shift, which, under the C++ standard, leads to undefined behavior. The unsigned type should be defined explicitly.&lt;br /&gt;&lt;br /&gt;Correct code:&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
int parse_ip(const char *str, struct vzctl_ip_param **ip)
{
....
if (family == AF_INET)
    mask = htonl(~0u &amp;lt;&amp;lt; (32 - mask));
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;Two more warnings of this kind:&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0225/" target="_blank" rel="nofollow"&gt;V610&lt;/a&gt; Undefined behavior. Check the shift operator '&amp;lt;&amp;lt;'. The left operand '~0' is negative. util.c 98&lt;br /&gt;&lt;br /&gt;V610 Undefined behavior. Check the shift operator '&amp;lt;&amp;lt;'. The left operand '~0' is negative. vztactl.c 187&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0137/" target="_blank" rel="nofollow"&gt;V547&lt;/a&gt; Expression 'limit &amp;lt; 0' is always false. Unsigned type value is never &amp;lt; 0. io.c 80&lt;br /&gt;&lt;br /&gt;&lt;pre&gt;
int
vz_set_iolimit(struct vzctl_env_handle *h, unsigned int limit)
{
int ret;
struct iolimit_state io;
unsigned veid = eid2veid(h);
if (limit &amp;lt; 0)
return VZCTL_E_SET_IO;
....
}
&lt;/pre&gt;&lt;br /&gt;&lt;br /&gt;The analyzer has detected an invalid conditional expression in this function. An unsigned variable can never be less than zero. This condition is probably just an excessive one, but it is also possible that identification of an incorrect state was meant to be implemented in some other way.&lt;br /&gt;&lt;br /&gt;Another similar fragment:&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.viva64.com/en/d/0137/" target="_blank" rel="nofollow"&gt;V547&lt;/a&gt; Expression 'limit &amp;lt; 0' is always false. Unsigned type value is never &amp;lt; 0. io.c 131&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Conclusion&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;At first, the developers suggested checking an already existing beta-version to be released soon - the version ".... where we will at least rewrite all the planned product parts and fix the bugs found during the testing stage". But that would hugely contradict the static analysis ideology! Static analysis is most efficient and beneficial when used at the earlier development stages and on a regular basis. A single-time check of your project may help improve the code at some point but the overall quality will remain at the same low level. Delaying code analysis till the testing stage is the greatest mistake however you look at it - either as a manager or a developer. It is cheapest to fix a bug at the coding stage!&lt;br /&gt;&lt;br /&gt;This idea is discussed in more detail by my colleague Andrey Karpov in the article &lt;a href="http://www.viva64.com/en/b/0336/" target="_blank" rel="nofollow"&gt;"How Do Programs Run with All Those Bugs At All?"&lt;/a&gt; I especially recommend reading the sections "No need to use PVS-Studio then?" and "PVS-Studio is needed!" And may your code stay bugless!&lt;br /&gt;&lt;br /&gt;P.S. Full logs from PVS Studio is &lt;a href="http://bronevichok.ru/trash/PVS-StudioLogsForOpenVZ.7z" target="_blank" rel="nofollow"&gt;here&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;&lt;a name='cutid1-end'&gt;&lt;/a&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:50678</id>
    <author>
      <name>dowdle</name>
    </author>
    <lj:poster user="dowdle" userid="9725912"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/50678.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=50678"/>
    <title>OpenVZ / Virtuozzo 7 First Impressions</title>
    <published>2015-07-01T21:35:00Z</published>
    <updated>2015-07-01T21:35:00Z</updated>
    <category term="openvz"/>
    <category term="virtuozzo"/>
    <content type="html">Odin and the OpenVZ Project announced the beta release of a new version of Virtuozzo today. This is also the next version of OpenVZ as the two are merging closer together.&lt;br /&gt;&lt;br /&gt;There will eventually be two distinct versions... a free version and a commercial version. So far as I can tell they currently call it Virtuozzo 7 but in a comparison wiki page they use the column names Virtuozzo 7 OpenVZ (V7O) and Virtuozzo 7 Commercial (V7C). The original OpenVZ, which is still considered the stable OpenVZ release at this time based on the EL6-based OpenVZ kernel, appears to be called OpenVZ Legacy.&lt;br /&gt;&lt;br /&gt;Odin had previously released the source code to a number of the Virtuozzo tools and followed that up with the release of spec-like source files used by Virtuozzo's vztt OS Template build system. The plan is to migrate away from the OpenVZ specific tools (like vzctl, vzlist, vzquota, and vzmigrate) to the Virtuozzo specific tools although there will probably be some overlap for a while.&lt;br /&gt;&lt;br /&gt;The release includes source code, binary packages and a bare-metal distro installer DVD iso.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Bare Metal Installer&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;I got a chance to check out the bare-metal installer today inside of a KVM virtual machine. I must admit that I'm not very familiar with previous Virtuozzo releases but I am a semi-expert when it comes to OpenVZ. Getting used to the new system is taking some effort but will all be for the better.&lt;br /&gt;&lt;br /&gt;I didn't make any screenshots yet of the installer... I may do that later... but it is very similar to that of RHEL7 (and clones) because it is built by and based on CloudLinux... which is based on EL7.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;CloudLinux Confusion&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;What is CloudLinux? CloudLinux is a company that makes a commercial multi-tenant hosting product... that appears to provide container (or container-like) isolation as well as Apache and PHP enhancements specifically for multi-tenant hosting needs. CloudLinux also offers KernelCare-based reboot-less kernel updates. CloudLinux's is definitely independent from Odin and the CloudLinux products are in no way related to Virtuozzo. Odin and CloudLinux are partners however.&lt;br /&gt;&lt;br /&gt;Why is the distro based on CloudLinux and does one need a CloudLinux subscription to use it? Well it turns out that Odin really didn't want to put forth all of the effort and time required to produce a completely new EL7-clone. CloudLinux is already an expert at that... so Odin partnered with CloudLinux to produce a EL7-based distro for Virtuozzo 7. While CloudLinux built it and (I think) there are a few underlying CloudLinux packages, everything included is FOSS (Free and Open Source Software). It DOES NOT and WILL NOT require a CloudLinux subscription to use... because it is not related to CloudLinux's product line nor does it contain any of the CloudLinux product features.&lt;br /&gt;&lt;br /&gt;The confusion was increased when I did a yum update post-install and if failed with a yum repo error asking me to register with CloudLinux. Turns out that is a bug in this initial release and registration is NOT needed. There is a manual fix of editing a repo file in /etc/yum.repos.ed/) and replacing the incorrect base and updates URLs with a working ones. This and and other bugs that are sure to crop up will be addressed in future iso builds which are currently slated for weekly release... as well as daily package builds and updates available via yum.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;More Questions, Some Answers&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;So this is the first effort to merge Virtuozzo and OpenVZ together... and again... me being very Virtuozzo ignorant... there is a lot to learn. How does the new system differ from OpenVZ? What are the new features coming from Virtuozzo? I don't know if I can answer every conceivable question but I was able to publicly chat with Odin's sergeyb in the &lt;a href='https://www.livejournal.com/rsearch/?tags=%23openvz'&gt;#openvz&lt;/a&gt; IRC channel on the Freenode IRC network. I also emailed the CloudLinux folks and got a reply back. Here's what I've been able to figure out so far.&lt;br /&gt;&lt;br /&gt;Why CloudLinux? - I mentioned that already above, but Odin didn't want to engineer their own EL7 clone so they got CloudLinux to do it for them and it was built specifically for Virtuozzo and not related to any of the CloudLinux products... and you do not need a subscription from Odin nor CloudLinux to use it.&lt;br /&gt;&lt;br /&gt;What virtualization does it support? - Previous Virtuozzo products supported not only containers but a proprietary virtual machine hypervisor made by Odin/Parallels. In Virtuozzo 7 (both OpenVZ and Commercial so far as I can tell) the proprietary hypervisor has been replaced with the Linux kernel built-in one... KVM. See: &lt;a target='_blank' href='https://openvz.org/QEMU' rel='nofollow'&gt;https://openvz.org/QEMU&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;How about libvirt support? - Anyone familiar with EL7's default libvirtd setup for KVM will be happy to know that it is maintained. libvirtd is running by default and the network interfaces you'd expect to be there, are. virsh and virt-manager should work as expected for KVM.&lt;br /&gt;&lt;br /&gt;Odin has been doing some libvirt development and supposedly both virsh and virt-manager should work with VZ7 containers. They are working with upstream. libvirt has supposedly supported OpenVZ for some time but there weren't any client applications that supported OpenVZ. That is changing. See: &lt;a target='_blank' href='https://openvz.org/LibVirt' rel='nofollow'&gt;https://openvz.org/LibVirt&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;Command line tools? - OpenVZ's vzctl is there as is Virtuozzo's prlctl.&lt;br /&gt;&lt;br /&gt;How about GUIs or web-based management tools? - That seems to be unclear at this time. I believe V7C will offer web-based management but I'm not sure about V7O. As mentioned in the previous question, virt-manager... which is a GUI management tool... should be usable for both containers and KVM VMs. virsh / virt-manager VZ7 container support remains to be seen but it is definitely on the roadmap.&lt;br /&gt;&lt;br /&gt;Any other new features? - Supposedly VZ7 has a fourth-generation resource management system that I don't know much about yet. Other than the most obvious stuff (EL7-based kernel, KVM, libvirt support, Virtuozzo tools, etc), I haven't had time to absorb much yet so unfortunately I can't speak to many of the new features. I'm sure there are tons.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;About OS Templates&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;I created a CentOS 6 container on the new system... and rather than downloading a pre-created OS Template that is a big .tar.gz file (as with OpenVZ Legacy) it downloaded individual rpm packages. It appears to build OS Templates on demand from current packages on-demand BUT it uses a caching system whereby it will hold on to previously downloaded packages in a cache directory somewhere under /vz/template/. If the desired OS Template doesn't exist already in /vz/template/cache/ the required packages are downloaded, a temporary ploop image made, the packages installed, and then the ploop disk image is compressed and added to /vz/template/cache as a pre-created OS Template. So the end result for my CentOS 6 container created /vz/template/cache/centos-6-x86_64.plain.ploopv2.tar.lz4. I manually downloaded an OpenVZ Legacy OS Template and placed it in /vz/template/cache but it was ignored so at this time, I do not think they are compatible / usable.&lt;br /&gt;&lt;br /&gt;The only OS Template available at time of writing was CentOS 6 but I assume they'll eventually have all of the various Linux distros available as in the past... both rpm and deb based ones. We'll just have to wait and see.&lt;br /&gt;&lt;br /&gt;As previously mentioned, Odin has already released the source code to vztt (Virtuozzo's OS Template build system) as well as some source files for CentOS, Debian and Ubuntu template creation. They have also admitted that coming from closed source, vztt is a bit over-complicated and not easy-to-use. They plan on changing that ASAP but help from the community would definitely be appreciated.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;How about KVM VMs?&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;I'm currently on vacation and only have access to a laptop running Fedora 22... that I'm typing this from... and didn't want to nuke it... so I installed the bare-metal distro inside of a KVM virtual machine. I didn't really want to try nested KVM. That would definitely not have been a legitimate test of the new system... but I expect libvirtd, virsh, and virt-manager to work and behave as expected.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Conclusion&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;Despite the lack of perfection in this initial release Virtuozzo 7 shows a lot of promise. While it is a bit jarring coming from OpenVZ Legacy... with all of the changes... the new features... especially KVM... really show promise and I'll be watching all of the updates as they happen. There certainly is a lot of work left to do but this is definitely a good start.&lt;br /&gt;&lt;br /&gt;I'd love to hear from other users to find out what experiences they have.  If I've made any mistakes in my analysis, please correct me immediately.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Congrats Odin and OpenVZ!&lt;/b&gt; I only wish I had a glass of champagne and could offer up a respectable toast... and that there were others around me to clank glasses with. :)</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:50178</id>
    <author>
      <name>Сергей Бронников</name>
    </author>
    <lj:poster user="estetus" userid="12957684"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/50178.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=50178"/>
    <title>Publishing of Virtuozzo builds</title>
    <published>2015-07-01T17:02:51Z</published>
    <updated>2015-07-01T17:02:51Z</updated>
    <category term="openvz"/>
    <category term="beta"/>
    <category term="virtuozzo core"/>
    <lj:music>Avril Lavigne - What the Hell | Powered by Last.fm</lj:music>
    <content type="html">&lt;pre style="white-space: pre-wrap; color: rgb(0, 0, 0); line-height: normal;"&gt;


We are ready to announce &lt;a href="https://download.openvz.org/virtuozzo/releases/7.0-beta1/x86_64/" target="_blank" rel="nofollow"&gt;publishing of binaries&lt;/a&gt; compiled from &lt;a href="https://src.openvz.org/projects/OVZ" target="_blank" rel="nofollow"&gt;open components&lt;/a&gt;:
&lt;/pre&gt;&lt;br /&gt;&lt;ul&gt;&lt;br /&gt;&lt;li&gt;Virtuozzo installation ISO image&lt;/li&gt;&lt;br /&gt;&lt;li&gt;RPM packages (kernel and userspace)&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Source RPM packages (kernel and userspace)&lt;/li&gt;&lt;br /&gt;&lt;li&gt;Debug RPM packages (kernel and userspace)&lt;/li&gt;&lt;br /&gt;&lt;li&gt;EZ templates (CentOS 7 x86_64, CentOS 6 x86_64 etc)&lt;/li&gt;&lt;br /&gt;&lt;/ul&gt;All installation paths &lt;a href="https://openvz.org/Quick_installation" target="_blank" rel="nofollow"&gt;described in OpenVZ wiki&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-size:1.4em;"&gt;FAQ (Frequently Asked Questions)&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: Can we use binaries or Virtuozzo distribution in production?&lt;/b&gt;&lt;br /&gt;A: No. Virtuozzo 7 is in pre-Beta stage and we strongly recommend to avoid any production use. We continue to develop new features and Virtuozzo 7 may contain serious bugs.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: Would it be possible to upgrade from Beta 1 to Beta 2?&lt;/b&gt;&lt;br /&gt;A: Upgrade will be supported only for OpenVZ installed on Cloud Linux (i.e. using Virtuozzo installation image of OpenVZ installed using yum on Cloud Linux).&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: How often you will update Virtuozzo 7 files?&lt;/b&gt;&lt;br /&gt;A: RPM package (and yum repository) - nightly, ISO image - weekly.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: I don&amp;#39;t want to use your custom kernel or distribution. How to use OpenVZ on my own Linux distribution? &lt;/b&gt; A: We plan to make available OpenVZ for vanilla kernels and we are working on it. If you want it - please help us with testing and contribute patches [2]. Pay attention that using OpenVZ with vanilla kernel will have some limitations because some required kernel changes are not in upstream yet.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:50063</id>
    <author>
      <name>dowdle</name>
    </author>
    <lj:poster user="dowdle" userid="9725912"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/50063.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=50063"/>
    <title>Building a Fedora 22 MATE Desktop Container</title>
    <published>2015-05-26T23:17:51Z</published>
    <updated>2015-05-26T23:17:51Z</updated>
    <category term="openvz"/>
    <content type="html">Fedora 22 was released today.  Congrats Fedora Project!&lt;br /&gt;&lt;br /&gt;I updated the Fedora 22 OS Template I contributed so it was current with the release today... and for the fun of it I recorded a screencast showing how to make a Fedora 22 MATE Desktop GUI container... and how to connect to it via X2GO.&lt;br /&gt;&lt;br /&gt;Enjoy!&lt;br /&gt;&lt;br /&gt;&lt;lj-embed id="9" /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:49912</id>
    <author>
      <name>dowdle</name>
    </author>
    <lj:poster user="dowdle" userid="9725912"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/49912.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=49912"/>
    <title>CRIU on FLOSS Weekly</title>
    <published>2015-05-01T16:23:41Z</published>
    <updated>2015-05-01T17:30:42Z</updated>
    <category term="criu"/>
    <content type="html">Here's another video... this one from FLOSS Weekly where they talk about CRIU (Checkpoint &amp; Restore In Userspace) which is closely related to OpenVZ and will be used in the EL7-based OpenVZ kernel branch.  Enjoy!&lt;br /&gt;&lt;br /&gt;&lt;lj-embed id="7" /&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Must get moose and squirrel!&lt;/b&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:49501</id>
    <author>
      <name>dowdle</name>
    </author>
    <lj:poster user="dowdle" userid="9725912"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/49501.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=49501"/>
    <title>Kir's presentation from LFNW 2015</title>
    <published>2015-05-01T15:59:00Z</published>
    <updated>2015-05-01T16:01:46Z</updated>
    <category term="openvz"/>
    <category term="virtuozzo"/>
    <content type="html">OpenVZ Project Leader Kir Kolyshkin gave a presentation on Saturday, April 25th, 2015 at LinuxFest Northwest entitled, "OpenVZ, Virtuozzo, and Docker".  I recorded it but I think my sdcard was having issues because there are a few bad spots in the recording... but it is totally watchable.  Enjoy!&lt;br /&gt;&lt;br /&gt;&lt;lj-embed id="6" /&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:49158</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/49158.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=49158"/>
    <title>OpenVZ past and future</title>
    <published>2014-12-26T23:57:50Z</published>
    <updated>2014-12-26T23:57:50Z</updated>
    <category term="kernel"/>
    <category term="openvz"/>
    <category term="vzcore"/>
    <category term="virtuozzo core"/>
    <category term="git"/>
    <category term="jira"/>
    <content type="html">Looking forward to 2015, we have very exciting news to share on the future on OpenVZ. But first, let's take a quick look into OpenVZ history.&lt;br /&gt;&lt;br /&gt;Linux Containers is an ancient technology, going back to last century. Indeed it was 1999 when our engineers started adding bits and pieces of containers technology to Linux kernel 2.2. Well, not exactly "containers", but rather "virtual environments" at that time -- as it often happens with new technologies, the terminology was different (the term "container" was coined by Sun only five years later, in 2004).&lt;br /&gt;&lt;br /&gt;Anyway, in 2000 we ported our experimental code to kernel 2.4.0test1, and in January 2002 we already had Virtuozzo 2.0 version released. From there it went on and on, with more releases, newer kernels, improved feature set (like adding live migration capability) and so on.&lt;br /&gt;&lt;br /&gt;It was 2005 when we finally realized we made a mistake of not employing the open source development model for the whole project from the very beginning. This is when OpenVZ was born as a separate entity, to complement commercial Virtuozzo (which was later renamed to Parallels Cloud Server, or PCS for short).&lt;br /&gt;&lt;br /&gt;Now it's time to admit -- over the course of years OpenVZ became just a little bit too separate, essentially becoming a fork (perhaps even a stepchild) of Parallels Cloud Server. While the kernel is the same between two of them, userspace tools (notably vzctl) differ. This results in slight incompatiblities between the configuration files, command line options etc. More to say, userspace development efforts need to be doubled.&lt;br /&gt;&lt;br /&gt;Better late than never; we are going to fix it now! &lt;b&gt;We are going to merge OpenVZ and Parallels Cloud Server into a single common open source code base.&lt;/b&gt; The obvious benefit for OpenVZ users is, of course, more features and better tested code. There will be other much anticipated changes, rolled out in a few stages.&lt;br /&gt;&lt;br /&gt;As a first step, &lt;b&gt;we will open the git repository of RHEL7-based Virtuozzo kernel&lt;/b&gt; early next year (2015, that is). This has become possible as we changed the internal development process to be more git-friendly (before that we relied on lists of patches a la quilt but with home grown set of scripts). We have worked on this kernel for quite some time already, initially porting our patchset to kernel 3.6, then rebasing it to RHEL7 beta, then final RHEL7. While it is still in development, we will publish it so anyone can follow the development process.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Our kernel development mailing list will also be made public.&lt;/b&gt; The big advantage of this change for those who want to participate in the development process is that you'll see our proposed changes discussed on this mailing list before the maintainer adds them to the repository, not just months later when the the code is published and we'll consider any patch sent to the mailing list.  This should allow the community to become full participants in development rather than mere bystanders as they were previously.&lt;br /&gt;&lt;br /&gt;Bug tracking systems have also diverged over time. Internally, we use JIRA (this is where all those PCLIN-xxxx and PSBM-xxxx codes come from), while OpenVZ relies on Bugzilla. &lt;b&gt;For the new unified product, we are going to open up JIRA&lt;/b&gt; which we find to me more usable than Bugzilla. Similar to what Red Hat and other major Linux vendors do, we will limit access to security-sensitive issues in order to not compromise our user base.&lt;br /&gt;&lt;br /&gt;Last but not least, the name. We had a lot of discussions about naming, had a few good candidates, and finally unanimously agreed on this one:&lt;br /&gt;&lt;br /&gt;&lt;big&gt;&lt;b&gt;&lt;center&gt;Virtuozzo Core&lt;/center&gt;&lt;/b&gt;&lt;/big&gt;&lt;br /&gt;&lt;br /&gt;Please stay tuned for more news (including more formal press release from Parallels). Feel free to ask any questions as we don't even have a FAQ yet.&lt;br /&gt;&lt;br /&gt;Merry Christmas and a Happy New Year!</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:49112</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/49112.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=49112"/>
    <title>On kernel branching</title>
    <published>2014-11-26T22:36:08Z</published>
    <updated>2014-11-27T02:58:11Z</updated>
    <category term="kernel"/>
    <category term="openvz"/>
    <category term="rhel6"/>
    <content type="html">This is a topic I always wanted to write about but was afraid my explanation would end up very cumbersome. This is no longer the case as we now have a picture that worth a thousand words!&lt;br /&gt;&lt;br /&gt;The picture describes how we develop kernel releases. It's bit more complicated than the linearity of version 1 -&amp;gt; version 2 -&amp;gt; version 3. The reason behind it is we are balancing between adding new features, fixing bugs, and rebasing to newer kernels, while trying to maintain stability for our users. This is our convoluted way of achieving all this:&lt;br /&gt;&lt;br /&gt;&lt;a target="_blank" href="http://ic.pics.livejournal.com/k001/990679/928/928_original.png" target="_blank"&gt;&lt;img src="https://ic.pics.livejournal.com/k001/990679/928/928_1000.png" alt="kernel_tree-2.6.32-x" title="kernel_tree-2.6.32-x" fetchpriority="high"&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;As you can see, we create a new branch when rebasing to a newer upstream (i.e. RHEL6) kernel, as regressions are quite common during a rebase. At the same time, we keep maintaining the older branch in which we add stability and security fixes. Sometimes we create a new branch to add some bold feature that takes a longer time to stabilize. Stability patches are then forward-ported to the new branch, which is either eventually becoming stable or obsoleted by yet another new one.&lt;br /&gt;&lt;br /&gt;Of course there is a lot of work behind these curtains, including rigorous internal testing of new releases. In addition to that, we usually provide those kernels to our users (in &lt;a href="http://openvz.org/Download/kernel/rhel6-testing" target="_blank" rel="nofollow"&gt;rhel6-testing&lt;/a&gt; repo) so they could test new stuff before it hits production servers, and we can fix more bugs earlier (&lt;a href="http://openvz.livejournal.com/45010.html" target="_blank"&gt;more on that here&lt;/a&gt;). If you are not taking part in this testing, well, it's never late to start!</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:48757</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/48757.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=48757"/>
    <title>Donation: a way to help or just say thanks</title>
    <published>2014-07-09T20:05:13Z</published>
    <updated>2014-07-09T20:54:32Z</updated>
    <category term="paypal"/>
    <category term="openvz"/>
    <category term="donate"/>
    <content type="html">&lt;p&gt;For many years, when people asked us how can they help the project, our typical answer was something like "just use it, file bugs, spread the word". Some people were asking specifically about how to donate money, and we had to say "currently we don't have a way to accept", so it was basically "no, we don't need your money". It was not a good answer. Even if &lt;a href="http://www.parallels.com/" target="_blank" rel="nofollow"&gt;our big sponsor&lt;/a&gt; is generously helping us with everything we need, that doesn't mean your money would be useless.&lt;/p&gt;

&lt;p&gt;Today we have opened a PayPal account to accept donations. Here:&lt;/p&gt;

&lt;p&gt;&lt;form action="https://www.paypal.com/cgi-bin/webscr" method="post" target="_top"&gt;
&lt;input type="hidden" name="cmd" value="_s-xclick"&gt;
&lt;input type="hidden" name="hosted_button_id" value="5MN5P6K74HUWE"&gt;
&lt;input type="image" src="https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!" style="border-style: none; background-color: transparent;"&gt;
&lt;img alt="" border="0" src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif" width="1" height="1"&gt;
&lt;/form&gt;&lt;/p&gt;

&lt;p&gt;How are we going to spend your money? In general:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Hardware for development and testing&lt;/li&gt;
&lt;li&gt;Travel budget for conferences, events etc.&lt;/li&gt;
&lt;li&gt;Accolades for active contributors&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In particular, right now we need:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;About $200 to cover shipping expenses for donated hardware&lt;/li&gt;
&lt;li&gt;About $300 for network equipment&lt;/li&gt;
&lt;li&gt;About $2000 for hard drives&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;a href="http://wiki.openvz.org/Donations" target="_blank" rel="nofollow"&gt;Donations page&lt;/a&gt; is created on our wiki to track donations and spending. We hope that it will see some good progress in the coming days, with a little help from you!&lt;/p&gt;

&lt;p&gt;NOTE that if you feel like spending $500 or more, there is yet another way to spend it -- &lt;a href="http://www.parallels.com/support/virtualization-suite/openvz/" target="_blank" rel="nofollow"&gt;a support contract from Parallels&lt;/a&gt;, with access to their excellent support team and 10 free support tickets.&lt;/p&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:48634</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/48634.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=48634"/>
    <title>Yet more live migration goodness</title>
    <published>2014-06-12T23:35:15Z</published>
    <updated>2014-07-09T20:16:15Z</updated>
    <category term="hardware"/>
    <category term="ploop"/>
    <category term="openvz"/>
    <category term="ebay"/>
    <category term="help"/>
    <category term="vzmigrate"/>
    <content type="html">&lt;p&gt;It's been two months since we have released vzctl 4.7 and ploop 1.11 with
&lt;a href="http://openvz.livejournal.com/47780.html" target="_blank"&gt;some vital improvements
to live migration&lt;/a&gt; that made it about 25% faster. Believe it or not,
this is another "make it faster" post, making it, well, faster.
That's right, we have more surprises in store for you! Read on and be delighted.&lt;/p&gt;

&lt;h2&gt;Asynchronous ploop send&lt;/h2&gt;

&lt;p&gt;This is something that should have been implemented at the very beginning,
but the initial implementation looked like this (in C):&lt;/p&gt;

&lt;p&gt;&lt;pre&gt;
/* _XXX_ We should use AIO. ploopcopy cannot use cached reads and
 * has to use O_DIRECT, which introduces large read latencies.
 * AIO is necessary to transfer with maximal speed.
 */
&lt;/pre&gt;&lt;/p&gt;

&lt;p&gt;Why there are no cached reads (and, in general, why ploop library is
using O_DIRECT, and the kernel also uses direct I/O, bypassing the cache)?
Note that ploop images are files that are used as block
devices containing a filesystem. That ploop block device and filesystem
access is going through cache as usual, so if we'd do the same for ploop
image itself, it would result in double caching and waste of RAM. Therefore,
we do direct I/O on lower level (when working with ploop images), and allow
usual Linux cache to be used on the upper level (when container is accessing
files inside the ploop, which is the most common operation).&lt;/p&gt;

&lt;p&gt;So, ploop image itself is not (usually) cached in memory, and other tricks
like read-ahead are also not used by the kernel, and reading each block from
the image takes time as it is read directly from disk. In our test lab
(OpenVZ running inside KVM with a networked disk) it takes about 10
milliseconds to read each 1 MB block. Then, sending each block to the
destination system over network also takes time, it's about 15 milliseconds
in our setup. So, it takes 25 milliseconds to read and send a block of data,
if we do it one after another. Oh wait, this is exactly how we do it!&lt;/p&gt;

&lt;p&gt;Solution -- let's do reading and sending at the same time! In other words,
while sending the first block of data we can already read the second one,
and so on, bringing the time required to transfer one block down to
MAX(Tread, Tsend) instead of Tread + Tsend.&lt;/p&gt;

&lt;p&gt;Implementation uses POSIX threads. Main ploop send process spawns a separate
sending thread and two buffers -- one for reading and one for sending, then
they change place. This works surprisingly well for something that uses
threads, maybe because it is as simple as it could ever be (one thread, one
mutex, one conditional). If you happen to know something about pthreads
programming, please review the appropriate
&lt;a href="http://git.openvz.org/?p=ploop;a=commitdiff;h=a55e26e9606" target="_blank" rel="nofollow"&gt;commit 55e26e9606&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;The new async send is used by default, you just need to have a newer ploop
(1.12, not yet released). Clone and compile ploop from git if you are curious.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;As for how much time we save using this, it happen to be 15 microseconds
instead of 25 per block of data, or 40% faster! Now, the real savings depend
on the number of blocks needs to be migrated after container is frozen,
it can be 5 or 100, so overall savings can be from 0.05 to 1 second.&lt;/b&gt;&lt;/p&gt;

&lt;h2&gt;ploop copy with feedback&lt;/h2&gt;

&lt;p&gt;&lt;a href="http://openvz.livejournal.com/47780.html" target="_blank"&gt;The previous post on live migration improvements&lt;/a&gt;
described an optimization of doing fdatasync() on the receiving
ploop side before suspending the container on the sending side. It also noted
that implementation is sub-par:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;
The other problem is that sending side should wait for fsync to finish,
in order to proceed with CT suspend. Unfortunately, there is no way to solve
this one with a one-way pipe, so the sending side just waits for a few
seconds. Ugly as it is, this is the best way possible (let us know if
you can think of something better).
&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;So, the problem is trivial -- there's a need for a bi-directional
channel between ploop copy sender and receiver, so the receiver can say
"All right, I have synced the freaking delta back to sender". In addition,
we want to do it in a simple way, not much more complicated as it is now.&lt;/p&gt;

&lt;p&gt;After some playing around with different approaches, it seemed
that &lt;a href="http://lmgtfy.com/?q=openssh+port+forwarding" target="_blank" rel="nofollow"&gt;OpenSSH
port forwarding&lt;/a&gt;, combined with tools like netcat, socat, or bash
/dev/tcp feature, can do the trick of establishing a two-way pipe
between ploop copy sides.&lt;/p&gt;

&lt;p&gt;The netcat (or nc) is available in various varieties, which might or might
not be available and/or compatible. socat is a bit better, but one problem
with it is it ignores its child exit code, so there is no (simple) way
to figure out an error. A problem with /dev/tcp feature is it is
bash-specific, but bash itself might not be universally available
(Debian and Ubunty users are well aware of that fact).&lt;/p&gt;

&lt;p&gt;So, all this was replaced with a tiny home-grown vznnc ("nano-netcat) tool.
It is indeed nano, as there is only
&lt;a href="http://git.openvz.org/?p=vzctl;a=blob;f=src/vznnc.c" target="_blank" rel="nofollow"&gt;only 200
lines of code&lt;/a&gt; in it. It can either listen or connect to a specified
port at localhost (note that ssh is doing real networking for us), and
run a program with its stdin/stdout (or a specified file descriptor)
already connected to that TCP socket. Again, similar to netcat, but
small, to the point, and hopefully bug-free.&lt;/p&gt;

&lt;p&gt;Finally, with this in place, we can make sending side of ploop copy to
wait for feedback from the receiving side, so it can suspend the container
as soon as remote side finished syncing. This makes the whole migration
a bit faster (by eliminating the previously hard-coded 5 seconds
wait-for-sync delay), but it also helps to slash the frozen time
as we suspend the container as soon as we should, so it won't be given
any extra time to write some more data we'll be needing to copy while
it's frozen.&lt;/p&gt;

&lt;p&gt;&lt;b&gt;It's hard to measure the practical impact of the feature, but in our
tests it saves about 3.5 seconds of total migration time, and from 0
to a few seconds of frozen time, depending on container's disk I/O
activity.&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;For the feature to work, you need the latest versions of vzctl (4.8)
and ploop (1.12) on both nodes (if one node doesn't have newer tools,
vzmigrate falls back to old non-feedback way of copying). Note that
those new version are not yet released at the time of writing this,
but you can get ones from git and compile yourself.&lt;/p&gt;

&lt;h2&gt;Using ssh connection multiplexing&lt;/h2&gt;

&lt;p&gt;It takes about 0.15 seconds to establish an ssh connection in our test lab.
Your mileage may wary, but it can't be zero. Well, unless an OpenSSH feature
of reusing an existing ssh connection is put to work! It's call connection
miltiplexing, and when used, once a connection is established, you can have
subsequent ones in practically no time. As vzmigrate is a shell script and
runs a number of commands at remote (destination) side, using it might save
us some time.&lt;/p&gt;

&lt;p&gt;Unfortunately, it's a relatively new OpenSSH feature and is implemented
quite ugly in a version available in CentOS 6 -- you need to keep one open
ssh session running. They fixed it in a later version by adding a special
daemon-like mode enabled with ControlPersist option, but alas not
in CentOS 6. Therefore, we have to maintain a special "master" ssh
connection for the duration of vzmigrate. For implementation details,
see commits
&lt;a href="http://git.openvz.org/?p=vzctl;a=commitdiff;h=06212ea3d" target="_blank" rel="nofollow"&gt;06212ea3d&lt;/a&gt;
and
&lt;a href="http://git.openvz.org/?p=vzctl;a=commitdiff;h=00b9ce043" target="_blank" rel="nofollow"&gt;00b9ce043&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;This is still experimental, so you need to specify &lt;code&gt;--ssh-mux&lt;/code&gt;
flag to vzmigrate
to use it. &lt;b&gt;You won't believe it (so, go test it yourself!), but this alone
slashes container frozen time by about 25% (which is great, as we fight for
every microsecond here), and improves the total time taken by vzmigrate
by up to 1 second (which is probably not that important but still nice).&lt;/b&gt;&lt;/p&gt;

&lt;h2&gt;What's next?&lt;/h2&gt;

&lt;p&gt;Current setup used for development and testing is two OpenVZ instances
running in KVM guests on a
&lt;a href="http://shop.lenovo.com/us/en/desktops/thinkcentre/m-series-tiny/m93-m93p/" target="_blank" rel="nofollow"&gt;ThinkCentre
box&lt;/a&gt;. While it's convenient and oh so very space-saving, is is probably
not the best approximation of a real world OpenVZ usage. &lt;s&gt;So, we need
some better hardware:&lt;/p&gt;

&lt;blockquote class="twitter-tweet" lang="en"&gt;&lt;p&gt;Buy us a server to support openvz devel today: $500 &lt;a href="http://t.co/jZVil7OBOY" target="_blank" rel="nofollow"&gt;http://t.co/jZVil7OBOY&lt;/a&gt; or $2000 &lt;a href="http://t.co/GX9oJUv0oX" target="_blank" rel="nofollow"&gt;http://t.co/GX9oJUv0oX&lt;/a&gt;&lt;/p&gt;&amp;mdash; OpenVZ Containers (@_openvz_) &lt;a href="https://twitter.com/_openvz_/statuses/474652872521842689" target="_blank" rel="nofollow"&gt;June 5, 2014&lt;/a&gt;&lt;/blockquote&gt;

&lt;p&gt;&lt;b&gt;If you are able to spend $500 to $2000 on ebay, please
let us know by email to donate at openvz dot org so we can arrange it&lt;/b&gt;.
Now, quite a few people offered hosted servers with a similar configuration.
While we are very thankful to all such offers, this time we are looking
for physical, not hosted, hardware.&lt;/s&gt;&lt;/p&gt;

&lt;b&gt;Update:&lt;/b&gt; Thanks to FastVPS, we got the Supermicro 4 node server. If you want to donate, see &lt;a href="https://openvz.org/Donations" target="_blank" rel="nofollow"&gt;wiki: Donations&lt;/a&gt;.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:48272</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/48272.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=48272"/>
    <title>please support OpenVZ development</title>
    <published>2014-06-05T20:46:44Z</published>
    <updated>2014-06-05T20:46:44Z</updated>
    <content type="html">&lt;blockquote class="twitter-tweet" data-partner="tweetdeck"&gt;&lt;p&gt;Buy us a server to support openvz devel today: $500 &lt;a href="http://t.co/jZVil7OBOY" target="_blank" rel="nofollow"&gt;http://t.co/jZVil7OBOY&lt;/a&gt; or $2000 &lt;a href="http://t.co/GX9oJUv0oX" target="_blank" rel="nofollow"&gt;http://t.co/GX9oJUv0oX&lt;/a&gt;&lt;/p&gt;&amp;mdash; OpenVZ Containers (@_openvz_) &lt;a href="https://twitter.com/_openvz_/statuses/474652872521842689" target="_blank" rel="nofollow"&gt;June 5, 2014&lt;/a&gt;&lt;/blockquote&gt;</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:48014</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/48014.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=48014"/>
    <title>An interview with ANK</title>
    <published>2014-04-15T03:13:00Z</published>
    <updated>2018-08-27T18:52:37Z</updated>
    <category term="kernel"/>
    <category term="interview"/>
    <category term="ank"/>
    <category term="linux"/>
    <content type="html">This is a rare interview with the legendary Alexey Kuznetsov (a.k.a. ANK), who happen to work for Parallels. Alan Cox once said he had thought for a long time that "Kuznetsov" is a collective name for a secret group of Russian programmers -- because no single man can write so much code at once.&lt;br /&gt;&lt;br /&gt;An interview is taken by &lt;a href="http://lifehacker.ru/2013/08/01/ank/" target="_blank" rel="nofollow"&gt;lifehacker.ru&lt;/a&gt; and is part of "work places" series. I tried to do my best to translate it to English, but it's far from perfect. I guess this is still a very interesting reading.&lt;hr&gt;&lt;br /&gt;&lt;br /&gt;&lt;img src="https://ic.pics.livejournal.com/k001/990679/1047/1047_1000.jpg" alt="" title="" fetchpriority="high"&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: Who are you and what you do?&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;Since mid-90s I was one of Linux maintainers. Back then all the communication was done via conferences and Linux mailing lists. Pretty often I was aggressively arguing with someone there, don't remember for which reasons. Now it's fun to recall. Being a maintainer, I wasn't just making something on my own, but had to control others. Kicking out those who were making rubbish (from my point of view), and supporting those who were making something non-rubbish. All these conflicts, they were exhausting me. Since some moment I started noticing I am becoming "bronzed" [Alexey is referring to superiority complex -- Kir]. You said or did some crap, and then learn that this is becoming the right way now, since ANK said so.&lt;br /&gt;&lt;br /&gt;I started to doubt, maybe I am just using my authority to maintain status quo. Every single morning started with a fight with myself, then with the world. In 2003 I got fed by it, so I went away from public, and later switched to a different field of knowledge. At that time I started my first project in Parallels. The task was to implement live migration of containers, and it was very complicated.&lt;br /&gt;&lt;br /&gt;Now in Parallels we work on Parallels Cloud Storage project, developing cluster file systems for storing virtual machine images. The technology itself is a few years old already, we did a release recently, and are now working on improving it.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: How does your workplace look like?&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;My workplace is a bunch of computers. But I only work on a notebook, currently it's Lenovo T530. Other computers here are used for various purposes. This display, standing here, I never use it, nor this keyboard. Well, only if something breaks. Here we have different computers, including a Power Mac, an Intel and an AMD. I was using those in different years for different experiments. Once I needed to create a cluster of 3 machines right here at my workplace. One machine here is really old, and its sole purpose is to manage a power switch, so I can reboot all the others when working remotely from home. Here I have two Mac Minis and a Power Mac. They are always on, but I use them rarely, only when I need to see something in Parallels Desktop.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: What software do you use?&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;I don't use anything except for Google Chrome. Well, an editor and a compiler, if they qualify for software. I also store some personal data and notes in Evernote.&lt;br /&gt;&lt;br /&gt;I only use a text console. For everything. In fact, on a newer notebooks, when the screen is getting better, the console mode is working worse and worse. So I am working in a graphical environment now, running a few full-screen terminals on top of it. It looks like a good old Unix console. So this is how I live, read email, work.&lt;br /&gt;&lt;br /&gt;I do have a GMail account, I use it to read email from my phone. Sometimes it is needed. Or, when I see someone sent me a PDF, I have nothing else to do than to forward this email to where I can open that PDF. Same for PPT. But this is purely theoretical, in practice I never work with PPT.&lt;br /&gt;&lt;br /&gt;I use Linux. Currently it is Fedora 13 -- not a newest one, to say at least. I am always using a version that was a base for a corresponding RHEL release. Every few years a new Red Hat [Enterprise Linux] is released, so I install a new system. When I do not change anything for a few years. Say, 5 years. I can't think of any new feature of an OS that would force me to update. I am just using the system as an editor, same as I have used it 20 years ago.&lt;br /&gt;&lt;br /&gt;I have a phone, Motorola RAZR Maxx, running Android. I don't like iOS. You can't change anything in there. Not that I like customizations, I like a possibility to customize. I got a Motorola because I hate Samsung. This hatred is absolutely irrational. I had no happiness with any Samsung product, they either did't work for me or they break. I need a phone to make calls and check emails, that is all I need. Everything else is disabled -- to save the battery.&lt;br /&gt;&lt;br /&gt;I am also reading news over RSS every day, like a morning paper. Now Feedly, before it was Google Reader, until they closed it. I have a list of bloggers I read, I won't mention their names. I am also reading Russian and foreign media. Lenta.ru, for example. There's that nice english-language service, News 360. It fits for what I like and gives me the relevant news. I am not able to say if it works or not, but the fact is, what it shows to me is really interesting to me. It was showing a lot of sports news at first, but then they disappeared.&lt;br /&gt;&lt;br /&gt;I don't use instant messengers like Skype or ICQ, it's just meaningless. If you need something, write an email. If you need it urgently, call. Email and phone covers everything.&lt;br /&gt;&lt;br /&gt;Speaking of social networks, I do have a Facebook account with two friends -- my wife and my sister. I view this account only when they post a picture, I don't wander there for no reason.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: Is there a use for paper in your work?&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;It's a mess. I don't have a pen, so when I would need it I could not find it. If I am close to the notebook and I need to write something -- I write to a file. If I don't have a notebook around, I write to my phone. For these situations I recently started to use Google Keep, a service to store small notes. It is convenient so far. Otherwise I use Evernote. Well, I don't have a system for that. But I do have a database of everything on my notebook: perpetual emails, all the files and notes. All this stuff is indexed. Total size is about 10 gigabytes, since I don't have any graphics. Well, if we throw away all the junk from there, almost nothing will remain.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Q: Is there a dream configuration?&lt;/b&gt;&lt;br /&gt;&lt;br /&gt;What I have here is more than enough for me. This last notebook is probably the best notebook I ever had.&lt;br /&gt;&lt;br /&gt;I was getting used to it for a long time, swore a lot. I only use Thinkpads for a long time. They are similar from version to version, but each next one is getting bigger and heavier, physically. This is annoying. This model, they changed the keyboard. I had to get used to it, but now I realize this is the best keyboard I ever had. In general, I am pretty satisfied with ThinkPads. Well, if it would had a Retina screen and be just 1 kilogram less weight -- that would be ideal.</content>
  </entry>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:47780</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/47780.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=47780"/>
    <title>ploop and live migration: 2 years later</title>
    <published>2014-04-04T02:45:52Z</published>
    <updated>2014-04-04T05:59:23Z</updated>
    <category term="ploop"/>
    <category term="optimization"/>
    <category term="openvz"/>
    <category term="vzctl"/>
    <category term="live migration"/>
    <content type="html">It has been almost two years since we wrote about &lt;a href="http://openvz.livejournal.com/41835.html" target="_blank"&gt;effective live migration with ploop write tracker&lt;/a&gt;. It's time to write some more about it, since we have managed to make ploop live migration yet more effective, by means of pretty simple optimizations. But let's not jump to resolution yet, it's a long and interesting story to tell.

&lt;p&gt;As you know, live migration is not quite live, although it looks that way to a user. There is a short time period, usually a few seconds, during which the container being migrated is frozen. This time (shown if &lt;code&gt;-t&lt;/code&gt; or &lt;code&gt;-v&lt;/code&gt; option to &lt;code&gt;vzmigrate --live&lt;/code&gt; is used) is what needs to be optimized, making it as short as possible. In order to do that, one needs to dig into details on what's happening when a container is frozen.&lt;/p&gt;

&lt;p&gt;Typical timings obtained via &lt;code&gt;vzmigrate -t --live&lt;/code&gt; look like this. We ran a few iterations migrating a container back and forth between two OpenVZ instances (running inside Parallels VMs on the same physical machine), so there are a few columns at the right side.&lt;/p&gt;

&lt;pre&gt;
(Software: vzctl 4.6.1, ploop-1.10)

              Iteration     1     2     3     4     5     6    AVG

        Suspend + Dump:   0.58  0.71  0.64  0.64  0.91  0.74  0.703
   Pcopy after suspend:   1.06  0.71  0.50  0.68  1.07  1.29  0.885
        Copy dump file:   0.64  0.67  0.44  0.51  0.43  0.50  0.532
       Undump + Resume:   2.04  2.06  1.94  3.16  2.26  2.32  2.297
                        ------  ----  ----  ----  ----  ----  -----
  Total suspended time:   4.33  4.16  3.54  5.01  4.68  4.85  4.428
&lt;/pre&gt;

&lt;p&gt;Apparently, the first suspect to look at is that "undump + resume". Basically, it shows timing of vzctl restore command. Why it is so slow? Apparently, ploop mount takes some noticeable time. Let's dig deeper into that process. &lt;/p&gt;

&lt;p&gt;First, &lt;a href="http://git.openvz.org/?p=ploop;a=commit;h=c17b5ab8f" target="_blank" rel="nofollow"&gt;implement timestamps in ploop messages&lt;/a&gt;, raise the log level and see what is going on here. Apparently, adding deltas is not instant, takes any time from 0.1 second to almost a second. After some more experiments and thinking it becomes obvious that since ploop kernel driver works with data in delta files directly, bypassing the page cache, it needs to force those files to be written to the disk, and this costly operation happens while container is frozen. Is it possible to do it earlier? Sure, we just need to force write the deltas we just copied before suspending a container. Easy, just call fsync(), or yet better fdatasync(), since we don't really care about metadata being written.&lt;/p&gt;

&lt;p&gt;Unfortunately, there is no command line tool to do fsync or fdatasync, so we had to &lt;a href="http://git.openvz.org/?p=vzctl;a=commitdiff;h=842ae637" target="_blank" rel="nofollow"&gt;write one&lt;/a&gt; and call it from vzmigrate. Is it any better now? Yes indeed, delta adding times went down to from tenths to hundredths of a second.&lt;/p&gt;

&lt;p&gt;Except for the top delta, of course, which we migrate using ploop copy. Surely, we can't fsync it before suspending container, because we keep copying it after. Oh wait... actually we can! By adding an fsync before CT suspend, we force the data be written on disk, so the second fsync (which happens after everything is copied) will take less time. This time is shown as "Pcopy after suspend".&lt;/p&gt;

&lt;p&gt;The problem is that ploop copy consists of two sides -- the sending one and the receiving one -- which communicate over a pipe (with ssh as a transport). It's the sending side which runs the command to freeze the container, and it's the receiving side which should do fsync, so we need to pass some sort of "do the fsync" command. Yet better, do it without breaking the existing protocol, so nothing bad will happen in case there is an older version of ploop on the receiving side.&lt;/p&gt;

&lt;p&gt;The "do the fsync" command ended up being a data block of 4 bytes, you can &lt;a href="http://git.openvz.org/?p=ploop;a=commitdiff;h=d56654a2a8" target="_blank" rel="nofollow"&gt;see the patch here&lt;/a&gt;. Older version will write these 4 bytes to disk, which is unnecessary but OK do to, and newer version will recognize it as a need to do fsync.&lt;/p&gt;

&lt;p&gt;The other problem is that sending side should wait for fsync to finish, in order to proceed with CT suspend. Unfortunately, there is no way to solve this one with a one-way pipe, so the sending side just waits for a few seconds. Ugly as it is, this is the best way possible (let us know if you can think of something better).&lt;/p&gt;

&lt;p&gt;To summarize, what we have added is a couple of fsyncs (it's actually fdatasync() since it is faster), and here are the results:&lt;/p&gt;
&lt;pre&gt;
(Software: vzctl 4.7, ploop-1.11)

              Iteration     1     2     3     4     5     6    AVG

        Suspend + Dump:   0.60  0.60  0.57  0.74  0.59  0.80  0.650
   Pcopy after suspend:   0.41  0.45  0.45  0.49  0.40  0.42  0.437 (-0.4)
        Copy dump file:   0.46  0.44  0.43  0.48  0.47  0.52  0.467
       Undump + Resume:   1.86  1.75  1.67  1.91  1.87  1.84  1.817 (-0.5)
                        ------  ----  ----  ----  ----  ----  -----
  Total suspended time:   3.33  3.24  3.12  3.63  3.35  3.59  3.377 (-1.1)
&lt;/pre&gt;

&lt;p&gt;As you see, both "pcopy after suspend" and "undump + resume" times decreased, shaving off about a second of time, which gives us about 25% improvement. Now, take into account that tests were done on an otherwise idle nodes with mostly idle containers, we suspect that the benefit will be more apparent with I/O load. Let checking if this statement is true will be your homework for today!&lt;/p&gt;

</content>
  </entry>
</feed>
