<?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/30ffcea8e005110d82795f3ba48d05c37de6c588fd42dba79fd4ecf57179a31b/P2WlxyVijxKvimFu881fWEMdsf-ah7h00F6HSaRJwd_B9FfdmMCiDVlpAQh2GwJepkdbjynfYAgIDkcBkBEvskoAjHiBK_-Gr0c:QbU7eB_pGPA2Fc4nbeoBRQ" 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/1b63bf5fcfa3191d8caf7017f941ad5aee3a3b98e55a5f96e15b9fcbfc74b00c/P2WlxyVijxKvimFu881fWEMdsf-ah7h0zFqDU7tQwd_D9hbCj4-qGk1pDE04H0N1pEdMoy7TYg9JU1gcmlom:T5Y4qhx9oOnPfoaOLQcBaw" 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;
