<?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/  -->
<rss version='2.0'  xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:media='http://search.yahoo.com/mrss/' xmlns:atom10='http://www.w3.org/2005/Atom'>
<channel>
  <title>OpenVZ</title>
  <link>https://openvz.livejournal.com/</link>
  <description>OpenVZ - LiveJournal.com</description>
  <lastBuildDate>Tue, 26 Jul 2016 07:22:21 GMT</lastBuildDate>
  <generator>LiveJournal / LiveJournal.com</generator>
  <lj:journal>openvz</lj:journal>
  <lj:journalid>9392309</lj:journalid>
  <lj:journaltype>community</lj:journaltype>
  <image>
    <url>https://l-userpic.livejournal.com/128680075/9392309</url>
    <title>OpenVZ</title>
    <link>https://openvz.livejournal.com/</link>
    <width>100</width>
    <height>100</height>
  </image>

  <item>
  <guid isPermaLink='true'>https://openvz.livejournal.com/53870.html</guid>
  <pubDate>Tue, 26 Jul 2016 07:22:21 GMT</pubDate>
  <title>OpenVZ 7.0 released</title>
  <author>estetus</author>
  <link>https://openvz.livejournal.com/53870.html</link>
  <description>I&amp;#39;m pleased to announce the release of OpenVZ 7.0. The new release focuses on merging OpenVZ and &lt;a href=&quot;https://src.openvz.org/projects/OVZ&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://virtuozzo.com/products/virtuozzo-linux/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://docs.openvz.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;publicly available&lt;/a&gt;.&lt;/li&gt;&lt;br /&gt;&lt;li&gt;&lt;a href=&quot;https://docs.openvz.org/virtuozzo_7_users_guide.webhelp/_managing_templates.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://kb.virtuozzo.com/en/129047&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;virt-manager&lt;/a&gt; or virsh via a &lt;a href=&quot;http://libvirt.org/drvvirtuozzo.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://docs.openvz.org/virtuozzo_7_users_guide.webhelp/_managing_resources.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://openvz.org/Memory_management_in_VZ7&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://criu.org/Main_Page&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;CRIU&lt;/a&gt; and &lt;a href=&quot;https://criu.org/P.Haul&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://download.openvz.org/virtuozzo/releases/7.0/x86_64/iso/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;installation ISO image&lt;/a&gt; are freely available at the &lt;a href=&quot;https://download.openvz.org/virtuozzo/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;OpenVZ download server&lt;/a&gt; and &lt;a href=&quot;https://mirrors.openvz.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;mirrors&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;&lt;a href=&quot;https://lists.openvz.org/pipermail/announce/2016-July/000664.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Original announce&lt;/a&gt;</description>
  <comments>https://openvz.livejournal.com/53870.html?view=comments#comments</comments>
  <category>openvz</category>
  <category>release</category>
  <category>criu</category>
  <lj:security>public</lj:security>
  <lj:poster>estetus</lj:poster>
  <lj:posterid>12957684</lj:posterid>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://openvz.livejournal.com/51003.html</guid>
  <pubDate>Fri, 03 Jul 2015 17:03:29 GMT</pubDate>
  <title>Parallels and Docker: Not Just Competition</title>
  <author>estetus</author>
  <link>https://openvz.livejournal.com/51003.html</link>
  <description>&lt;img alt=&quot;&quot; height=&quot;600&quot; src=&quot;https://ic.pics.livejournal.com/estetus/12957684/357/357_900.jpg&quot; title=&quot;Pavel Emelyanov, CRIU project mantainer&quot; width=&quot;900&quot; fetchpriority=&quot;high&quot; /&gt;&amp;lt;/p&amp;gt;&lt;p class=&quot;&quot;&gt;&lt;br /&gt;&lt;span class=&quot;&quot;&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=&quot;&quot;&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;span style=&quot;line-height: 1.4;&quot;&gt;One good example is the &lt;a href=&quot;https://github.com/docker/libcontainer&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://openvz.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://github.com/docker/libcontainer&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;libcontainer&lt;/a&gt;.&lt;/span&gt;&lt;/p&gt;&lt;p class=&quot;&quot;&gt;&lt;span class=&quot;&quot;&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=&quot;&quot;&gt;&lt;span style=&quot;line-height: 1.4;&quot;&gt;Recently, we announced jointly with Docker that &lt;a href=&quot;https://openvz.org/Virtuozzo&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://openvz.org/Virtuozzo&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Virtuozzo&lt;/a&gt;.&lt;/span&gt;&lt;/p&gt;&lt;p class=&quot;&quot;&gt;&lt;span class=&quot;&quot;&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=&quot;&quot;&gt;&lt;span class=&quot;&quot;&gt;The live migration itself is performed by the &lt;a href=&quot;http://criu.org/P.Haul&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;P.Haul subproject&lt;/a&gt; that uses &lt;a href=&quot;http://criu.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;&quot;&gt;&lt;span class=&quot;&quot;&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=&quot;&quot;&gt;&lt;span class=&quot;&quot;&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=&quot;&quot;&gt;&lt;span class=&quot;&quot;&gt;Today &lt;a href=&quot;http://criu.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;&quot;&gt;&lt;span class=&quot;&quot;&gt;The &lt;a href=&quot;http://criu.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;https://xakep.ru/2015/06/22/parallels-i-docker/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;via&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;&lt;br /&gt;&lt;br /&gt;&lt;a name=&apos;cutid1-end&apos;&gt;&lt;/a&gt;</description>
  <comments>https://openvz.livejournal.com/51003.html?view=comments#comments</comments>
  <category>p.haul</category>
  <category>openvz</category>
  <category>docker</category>
  <category>libcontainer</category>
  <category>criu</category>
  <lj:security>public</lj:security>
  <lj:poster>estetus</lj:poster>
  <lj:posterid>12957684</lj:posterid>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://openvz.livejournal.com/49912.html</guid>
  <pubDate>Fri, 01 May 2015 16:23:41 GMT</pubDate>
  <title>CRIU on FLOSS Weekly</title>
  <author>dowdle</author>
  <link>https://openvz.livejournal.com/49912.html</link>
  <description>Here&apos;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=&quot;7&quot; /&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Must get moose and squirrel!&lt;/b&gt;</description>
  <comments>https://openvz.livejournal.com/49912.html?view=comments#comments</comments>
  <category>criu</category>
  <lj:security>public</lj:security>
  <lj:poster>dowdle</lj:poster>
  <lj:posterid>9725912</lj:posterid>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://openvz.livejournal.com/47071.html</guid>
  <pubDate>Wed, 05 Feb 2014 18:11:43 GMT</pubDate>
  <title>CRIU hangout on air</title>
  <author>k001</author>
  <link>https://openvz.livejournal.com/47071.html</link>
  <description>In a light of CRIU 1.1 release that happened last week, we will be doing a hangout on air to tell more about CRIU past and the future, and will be answering your questions. &lt;a href=&quot;https://plus.google.com/events/cfj8rg61m1uj6ns3pf6dd8f8me0&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Event page is here&lt;/a&gt;, it is going to happen as soon as this Friday, Feb 7th, at 6:00am PST / 9:00am EST / 15:00 CET / 18:00 MSK. Feel free to ask your questions now (go to &lt;a href=&quot;https://plus.google.com/events/cfj8rg61m1uj6ns3pf6dd8f8me0&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;event page&lt;/a&gt; and click on &quot;Play&quot;).</description>
  <comments>https://openvz.livejournal.com/47071.html?view=comments#comments</comments>
  <category>openvz</category>
  <category>hangout on air</category>
  <category>criu</category>
  <lj:security>public</lj:security>
  <lj:poster>k001</lj:poster>
  <lj:posterid>990679</lj:posterid>
  <lj:reply-count>0</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://openvz.livejournal.com/42793.html</guid>
  <pubDate>Sat, 06 Oct 2012 09:31:53 GMT</pubDate>
  <title>OpenVZ turns 7, gifts are available!</title>
  <author>k001</author>
  <link>https://openvz.livejournal.com/42793.html</link>
  <description>&lt;p&gt;&lt;b&gt;OpenVZ project is 7 years old&lt;/b&gt; as of last month. It&apos;s hard to believe the number, but looking back, we&apos;ve done a lot of things together with you, our users.&lt;/p&gt;

&lt;p&gt;One of the main project goals was (and still is) to include the containers support upstream, i.e. to vanilla Linux kernel. In practice, OpenVZ kernel is a fork of the Linux kernel, and we don&apos;t like it that way, for a number of reasons. The main ones are:&lt;/p&gt;

&lt;p&gt;&lt;ul&gt;&lt;li&gt; We want everyone to benefit from containers, not just ones using OpenVZ kernel. Yes to world domination!&lt;/li&gt;
&lt;li&gt;We&apos;d like to concentrate on new features, improvements and bug fixes, rather than forward porting our changes to the next kernel.&lt;/li&gt;&lt;/ul&gt;&lt;/p&gt;

&lt;p&gt;So, we were (and still are) working hard to bring in-kernel containers support upstream, and many key pieces are already there in the kernel -- for example, PID and network namespaces, cgroups and memory controller. This is the functionality that lxc tool and libvirt library are using. We also use the features we merged into upstream, so with every new kernel branch we have to port less, and the size of our patch set decreases.&lt;/p&gt;

&lt;h3&gt;CRIU&lt;/h3&gt;

&lt;p&gt;One of such features for upstream is checkpoint/restore, an ability to save running container state and then restore it. The main use of this feature is live migration, but there are other &lt;a href=&quot;http://criu.org/Usage_scenarios&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;usage scenarios as well&lt;/a&gt;. While the feature is present in OpenVZ kernel since April 2006, it was never accepted to upstream Linux kernel (nor was the other implementation proposed by Oren Laadan).&lt;/p&gt;

&lt;p&gt;For the last year we are working on &lt;a href=&quot;http://criu.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;CRIU&lt;/a&gt; project, which aims to reimplement most of the checkpoint/restore functionality in userspace, with bits of kernel support where required. As of now, most of the additional kernel patches needed for CRIU are already there in kernel 3.6, and a few more patches are on its way to 3.7 or 3.8. Speaking of CRIU tools, they are currently at version 0.2, released 20th of September, which already have limited support for checkpointing and restoring an upstream container. Check &lt;a href=&quot;http://criu.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;criu.org&lt;/a&gt; for more details, and give it a try. Note that this project is not only for containers -- you can checkpoint any process trees -- it&apos;s just the container is better because it is clearly separated from the rest of the system.&lt;/p&gt;

&lt;p&gt;One of the most important things about CRIU is we are NOT developing it behind the closed doors. As usual, we have wiki and git, but most important thing is every patch is going through the &lt;a href=&quot;http://openvz.org/pipermail/criu/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;public mailing list&lt;/a&gt;, so everyone can join the fun.&lt;/p&gt;

&lt;h3&gt;vzctl for upstream kernel&lt;/h3&gt;

&lt;p&gt;We have also released vzctl 4.0 recently (25th of September). As you can see by the number, it is a major release, and the main feature is support for non-OpenVZ kernels. Yes it&apos;s true -- now you can have a feeling of OpenVZ without installing OpenVZ kernel. Any recent 3.x kernel should work.&lt;/p&gt;

&lt;p&gt;As with OpenVZ kernel, you can use ready container images we have for OpenVZ (so called &quot;OS templates&quot;) or employ your own. You can create, start, stop, and delete containers, set various resource parameters such as RAM and CPU limits. Networking (aside from routed-based) is also supported -- you can either move a network interface from host system to inside container (&lt;code&gt;--netdev_add&lt;/code&gt;), or use bridged setup (&lt;code&gt;--netif_add&lt;/code&gt;). I personally run this stuff on my Fedora 17 desktop using stock F17 kernel -- it just works!&lt;/p&gt;

&lt;p&gt;Having said all that, surely OpenVZ kernel is in much better shape now as it comes for containers support -- it has more features (such as live container shapshots and live migration), better resource management capabilities, and overall is more stable and secure. But the fact that the kernel is now optional makes the whole thing more appealing (or so I hope).&lt;/p&gt;

&lt;p&gt;You can find information on how to setup and start using vzctl at &lt;a href=&quot;http://wiki.openvz.org/Vzctl_for_upstream_kernel&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;vzctl for upstream kernel&lt;/a&gt; wiki page. The page also lists known limitations are pointers to other resources. I definitely recommend you to give it a try and share your experience! As usual, any bugs found are to be reported to &lt;a href=&quot;http://bugzilla.openvz.org/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;OpenVZ bugzilla&lt;/a&gt;.

&lt;p&gt;&lt;b&gt;Update:&lt;/b&gt; comments disabled due to spam&lt;/p&gt;</description>
  <category>kernel</category>
  <category>openvz</category>
  <category>vzctl</category>
  <category>criu</category>
  <category>crtools</category>
  <lj:security>public</lj:security>
  <lj:poster>k001</lj:poster>
  <lj:posterid>990679</lj:posterid>
  <lj:reply-count>3</lj:reply-count>
  </item>
  <item>
  <guid isPermaLink='true'>https://openvz.livejournal.com/42414.html</guid>
  <pubDate>Tue, 24 Jul 2012 13:48:59 GMT</pubDate>
  <title>[CRIU] CRtools 0.1 released!</title>
  <author>k001</author>
  <link>https://openvz.livejournal.com/42414.html</link>
  <description>Checkpoint/restore, or CPT for short, is a nice feature of OpenVZ, and probably the most amazing one. In a nutshell, it&apos;s a way to freeze a container and dump its complete state (processes, memory, network connections etc) to a file on disk, and then restore from that dump, resuming processes execution as if nothing happened. This opens a way to do nifty things such as live container migration, fast reboots, high availability setups etc.&lt;br /&gt;&lt;br /&gt;It is our ultimate goal to merge all bits and pieces of OpenVZ to the mainstream Linux kernel. It&apos;s not a big secret that we failed miserably trying to merge the checkpoint/restore functionality (and yes, we have tried more than once). The fact that everyone else failed as well soothes the pain a bit, but is not really helpful. The reason is simple: CPT code is big, complex, and touches way too many places in the kernel.&lt;br /&gt;&lt;br /&gt;So we&lt;sup&gt;*&lt;/sup&gt; came up with an idea to implement most of CPT stuff in user space, i.e. as a separate program not as a part of the Linux kernel. In practice this is impossible because some kernel trickery is still required here and there, but the whole point was to limit kernel intervention to the bare minimum.&lt;br /&gt;&lt;br /&gt;Guess what? It worked even better that we expected. As of today, after about a year of development, up to 90% of the stuff that is needed to be in the kernel is already there, and the rest is ready and seems to be relatively easy to merge (see &lt;a href=&quot;http://criu.org/Commits&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;this table&lt;/a&gt; to get an idea what&apos;s in and what&apos;s not).&lt;br /&gt;&lt;br /&gt;As for the user space stuff, &lt;b&gt;we are happy to announce the release of CRtools version 0.1&lt;/b&gt;. Now, let me step aside and quote Pavel&apos;s announcement:&lt;br /&gt;&lt;br /&gt;&lt;blockquote&gt;The tool can already be used for checkpointing and restoring various individual&lt;br /&gt;applications. And the greatest thing about this so far is that most of the below&lt;br /&gt;functionality has the required kernel support in the recently released v3.5!&lt;br /&gt;&lt;br /&gt;So, we support now&lt;br /&gt;&lt;br /&gt;* x86_64 architecture&lt;br /&gt;* process&apos; linkage&lt;br /&gt;* process groups and sessions (without ttys though :\ )&lt;br /&gt;* memory mappings of any kind (shared, file, etc.)&lt;br /&gt;* threads&lt;br /&gt;* open files (shared between tasks and partially opened-and-unlinked)&lt;br /&gt;* pipes and fifos with data&lt;br /&gt;* unix sockets with packet queues contents&lt;br /&gt;* TCP and UDP sockets (TCP connections support exists, but needs polishing)&lt;br /&gt;* inotifies, eventpoll and eventfd&lt;br /&gt;* tasks&apos; sigactions setup, credentials and itimers&lt;br /&gt;* IPC, mount and PID namespaces&lt;br /&gt;&lt;br /&gt;Though namespaces support is in there, we do not yet support an LXC container c/r,&lt;br /&gt;but we&apos;re close to it :)&lt;br /&gt;&lt;br /&gt;I&apos;d like to thank everyone who took part in new kernel APIs discussions, the&lt;br /&gt;feedback was great! Special thanks goes to Linus for letting the kernel parts&lt;br /&gt;in early, instead of making them sit out of tree till becoming stable enough.&lt;br /&gt;&lt;br /&gt;Tarball with the tool sources is at&lt;br /&gt;  &lt;a target=&apos;_blank&apos; href=&apos;http://download.openvz.org/criu/crtools-0.1.tar.bz2&apos; rel=&apos;nofollow&apos;&gt;http://download.openvz.org/criu/crtools-0.1.tar.bz2&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;The git repo is at&lt;br /&gt;  &lt;a target=&apos;_blank&apos; href=&apos;http://git.criu.org/&apos; rel=&apos;nofollow&apos;&gt;http://git.criu.org/&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;And some sort of docs growing at&lt;br /&gt;  &lt;a target=&apos;_blank&apos; href=&apos;http://criu.org/&apos; rel=&apos;nofollow&apos;&gt;http://criu.org/&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;There are still things for which we don&apos;t have the kernel support merged (SysVIPC&lt;br /&gt;and various anon file descriptors, i.e. inotify, eventpoll, eventfd) yet. We have&lt;br /&gt;the kernel branch with the stuff applied available at&lt;br /&gt;&lt;br /&gt;  &lt;a target=&apos;_blank&apos; href=&apos;https://github.com/cyrillos/linux-2.6.git&apos; rel=&apos;nofollow&apos;&gt;https://github.com/cyrillos/linux-2.6.git&lt;/a&gt;&lt;br /&gt;&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;What&apos;s next? We will be rebasing OpenVZ to Linux Kernel 3.5 (most probably) and will try to re-use CRIU for checkpoint and restore of OpenVZ containers, effectively killing a huge chunk of out-of-tree kernel code that we have in OpenVZ kernel.&lt;br /&gt;&lt;br /&gt;* - In fact it was Pavel Emelyanov, our chief kernel architect, but it feels oh so nice to say &lt;i&gt;we&lt;/i&gt; that we can&apos;t refrain).&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Update:&lt;/b&gt; comments disabled due to spam.</description>
  <category>kernel</category>
  <category>openvz</category>
  <category>criu</category>
  <lj:security>public</lj:security>
  <lj:poster>k001</lj:poster>
  <lj:posterid>990679</lj:posterid>
  <lj:reply-count>2</lj:reply-count>
  </item>
</channel>
</rss>
