<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.openvz.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Dev</id>
	<title>OpenVZ Virtuozzo Containers Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.openvz.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Dev"/>
	<link rel="alternate" type="text/html" href="https://wiki.openvz.org/Special:Contributions/Dev"/>
	<updated>2026-06-03T19:57:09Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.31.1</generator>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=15289</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=15289"/>
		<updated>2014-05-14T14:17:47Z</updated>

		<summary type="html">&lt;p&gt;Dev: fixed links&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Parallels Cloud Storage''' (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery.&lt;br /&gt;
&lt;br /&gt;
Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers ([[CT]]s). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
== Features ==&lt;br /&gt;
&amp;lt;br clear=&amp;quot;both&amp;quot;&amp;gt;&lt;br /&gt;
[[File:Parallels_Cloud_Storage_is_a_software_defined_storage.png|300px|right|link=http://www.youtube.com/watch?v=6oEzW9w-1rg|Parallels Cloud Storage is a software defined storage]]&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
See a brief [http://www.youtube.com/watch?v=6oEzW9w-1rg video on YouTube].&lt;br /&gt;
&amp;lt;br clear=&amp;quot;both&amp;quot;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Pstorage for OpenVZ limitations ==&lt;br /&gt;
&lt;br /&gt;
{{Warning|&lt;br /&gt;
* Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production.&lt;br /&gt;
* To unlock for running in production, you should upgrade to a full Parallels Cloud Server product (see below).&lt;br /&gt;
* Maximum capacity limited for usage in technology preview mode is 100 GB of logical (usable by containers) disk space.&lt;br /&gt;
* After hitting this limit, writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit (it's not a bug :) ).&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
=== Components ===&lt;br /&gt;
&lt;br /&gt;
[[File:Parallels_Cloud_Storage_components.png|650px|top|Parallels Cloud Storage Components]]&lt;br /&gt;
&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
== Setup ==&lt;br /&gt;
&lt;br /&gt;
This HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf Pstorage manual] and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
=== Installing Parallels Cloud Storage software ===&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages, log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Set up pstorage yum repository:&lt;br /&gt;
&lt;br /&gt;
 cat &amp;lt;&amp;lt; EOF &amp;gt; /etc/yum.repos.d/pstorage.repo&lt;br /&gt;
 [openvz-pstorage]&lt;br /&gt;
 name=Parallels Cloud Storage for OpenVZ&lt;br /&gt;
 baseurl=http://download.openvz.org/pstorage/current&lt;br /&gt;
 enabled=1&lt;br /&gt;
 gpgcheck=0&lt;br /&gt;
 EOF&lt;br /&gt;
&lt;br /&gt;
Install needed packages:&lt;br /&gt;
&lt;br /&gt;
 yum install pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&lt;br /&gt;
=== Creating a cluster ===&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
==== Create metadata servers (MDS) ====&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the cluster and the very first MDS type:&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of ''10.30.100.101'' for communication with this server (replace ''10.30.100.101'' with IP address of your own MDS server). MDS will store its data at location specified by '''-r''' option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service ('''pstorage-mdsd''') and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-mdsd start&lt;br /&gt;
 chkconfig pstorage-mdsd on&lt;br /&gt;
&lt;br /&gt;
To create a 2nd and subsequent MDS services on other nodes, do the following:&lt;br /&gt;
&lt;br /&gt;
1. Login to the node as root.&lt;br /&gt;
&lt;br /&gt;
2. Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the '''bs.list''' file in the '''/etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt;''' directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
 echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
&lt;br /&gt;
3. Authenticate the server in the cluster and add a new MDS to the cluster using similar to the above make-mds command w/o -I and -p options:&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
 pstorage -c test_cluster make-mds -a 10.30.100.102 -r /pstorage/test_cluster-mds&lt;br /&gt;
&lt;br /&gt;
==== Create a chunk server (CS) ====&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create a CS:&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after '''-r''' option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service ('''pstorage-csd''') and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-csd start&lt;br /&gt;
 chkconfig pstorage-csd on&lt;br /&gt;
&lt;br /&gt;
==== Setting up a client ====&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to and then mount it as a conventional file system:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /pcs&lt;br /&gt;
 pstorage-mount -c test_cluster /pcs&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node reboot. Consult ''man pstorage-mount'' for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
==== Create a container running in the cluster ====&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
 modprobe ploop pfmt_ploop1 pio_kaio&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at '''/pcs''' as described above if not done yet. Create a folder on Pstorage for the containers:&lt;br /&gt;
 mkdir -p /pcs/containers&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
 vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/101&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started on '''any''' Pstorage client node (note, however, that you need to register container first if want to run on node different from creator one):&lt;br /&gt;
&lt;br /&gt;
 vzctl start 101&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
== Upgrading to Parallels Cloud Server ==&lt;br /&gt;
&lt;br /&gt;
'''[http://www.parallels.com/products/pcs/ Parallels Cloud Server]''' is a unique virtualization server platform combining both hypervisor and container-based virtualization together with innovative storage virtualization [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudServer6_DataSheet_EN_Ltr_111312.pdf].&lt;br /&gt;
&lt;br /&gt;
Please request more information on upgrading to Parallels Cloud Server at the [http://www.parallels.com/products/pcs/ product page] (look for '''Request Information''' button).&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
&lt;br /&gt;
* [http://www.parallels.com/fileadmin/media/hcap/pcs/documents/ParCloudServer6_DataSheet_EN_Ltr_111312.pdf Parallels Cloud Server product datasheet]&lt;br /&gt;
* [http://www.parallels.com/fileadmin/media/hcap/pcs/documents/ParCloudStorage_DataSheet_EN_Ltr_02262013.pdf Parallels Cloud Storage product datasheet]&lt;br /&gt;
* [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage_Administrators_Guide.pdf Parallels Cloud Storage Administrator's Guide]&lt;br /&gt;
* [http://www.parallels.com/fileadmin/media/hcap/pcs/documents/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf Pstorage performance whitepaper]&lt;br /&gt;
* [http://www.youtube.com/watch?v=6oEzW9w-1rg Pstorage introduction video]&lt;br /&gt;
&lt;br /&gt;
[[Category: Storage]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14954</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14954"/>
		<updated>2014-01-13T15:55:40Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
See a brief [http://www.youtube.com/watch?v=6oEzW9w-1rg video on YouTube].&lt;br /&gt;
&lt;br /&gt;
==OpenVZ limitations==&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#FF0000&amp;quot;&amp;gt;Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production.&amp;lt;br&amp;gt;To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below).&amp;lt;br&amp;gt;Maximum capacity limited for usage in technology preview mode is 100GB of logical (Containers usable) disk space.&amp;lt;br&amp;gt;After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit (it's not a bug :) ).&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf Pstorage manual] and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared, pstorage-metadata-server, pstorage-chunk-server and pstorage-client. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
 wget http://download.openvz.org/pstorage/*&lt;br /&gt;
 yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the cluster and the very first MDS type:&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of ''10.30.100.101'' for communication with this server (replace ''10.30.100.101'' with IP address of your own MDS server). MDS will store its data at location specified by '''-r''' option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service ('''pstorage-mdsd''') and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-mdsd start&lt;br /&gt;
 chkconfig pstorage-mdsd on&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
&lt;br /&gt;
1. Login to the node as root.&lt;br /&gt;
&lt;br /&gt;
2. Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the '''bs.list''' file in the '''/etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt;''' directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
 echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
&lt;br /&gt;
3. Authenticate the server in the cluster and add a new MDS to the cluster using similar to the above make-mds command w/o -I and -p options:&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
 pstorage -c test_cluster make-mds -a 10.30.100.102 -r /pstorage/test_cluster-mds&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
 pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after '''-r''' option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service ('''pstorage-csd''') and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-csd start&lt;br /&gt;
 chkconfig pstorage-csd on&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to and then mount it as a conventional file system:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /pcs&lt;br /&gt;
 pstorage-mount -c test_cluster /pcs&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node reboot. Consult ''man pstorage-mount'' for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
 modprobe ploop pfmt_ploop1 pio_kaio&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at '''/pcs''' as described above if not done yet. Create a folder on Pstorage for the containers:&lt;br /&gt;
 mkdir -p /pcs/containers&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
 vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started on '''any''' Pstorage client node (note, however, that you need to register container first if want to run on node different from creator one):&lt;br /&gt;
 vzctl start 101&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
What is [http://www.parallels.com/products/pcs/ Parallels Cloud Server]? Parallels Cloud Server is a unique virtualization server platform combining hypervisor &amp;amp; containers virtualization together with innovative storage virtualization [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudServer6_DataSheet_EN_Ltr_111312.pdf].&lt;br /&gt;
&lt;br /&gt;
Please request more information on upgrading to Parallels Cloud Server on a [http://www.parallels.com/products/pcs/ product page] (see '''Request Information''' button).&lt;br /&gt;
&lt;br /&gt;
==Pstorage Links &amp;amp; Documentation==&lt;br /&gt;
* Parallels Cloud Server [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudServer6_DataSheet_EN_Ltr_111312.pdf product datasheet].&lt;br /&gt;
* Parallels Cloud Storage [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudStorage_DataSheet_EN_Ltr_02262013.pdf product datascheet].&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstorage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;br /&gt;
* YouTube introduction video [http://www.youtube.com/watch?v=6oEzW9w-1rg]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14949</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14949"/>
		<updated>2014-01-13T05:30:23Z</updated>

		<summary type="html">&lt;p&gt;Dev: Dev moved page Ploop/OpenVZ container on ploop inside Parallels Cloud Storage to Parallels Cloud Storage&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
See a brief [http://www.youtube.com/watch?v=6oEzW9w-1rg video on YouTube].&lt;br /&gt;
&lt;br /&gt;
==OpenVZ limitations==&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#FF0000&amp;quot;&amp;gt;Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production.&amp;lt;br&amp;gt;To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below).&amp;lt;br&amp;gt;Maximum capacity limited for usage in technology preview mode is 100GB of logical (Containers usable) disk space.&amp;lt;br&amp;gt;After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit (it's not a bug :) ).&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf Pstorage manual] and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared and pstorage-metadata-server. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
 wget http://download.openvz.org/pstorage/*&lt;br /&gt;
 yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the cluster and the very first MDS type:&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of ''10.30.100.101'' for communication with this server (replace ''10.30.100.101'' with IP address of your own MDS server). MDS will store its data at location specified by '''-r''' option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service ('''pstorage-mdsd''') and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-mdsd start&lt;br /&gt;
 chkconfig pstorage-mdsd on&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
&lt;br /&gt;
1. Login to the node as root.&lt;br /&gt;
&lt;br /&gt;
2. Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the '''bs.list''' file in the '''/etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt;''' directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
 echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
&lt;br /&gt;
3. Authenticate the server in the cluster and add a new MDS to the cluster using similar to the above make-mds command w/o -I and -p options:&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
 pstorage -c test_cluster make-mds -a 10.30.100.102 -r /pstorage/test_cluster-mds&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
 pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after '''-r''' option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service ('''pstorage-csd''') and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-csd start&lt;br /&gt;
 chkconfig pstorage-csd on&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to and then mount it as a conventional file system:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /pcs&lt;br /&gt;
 pstorage-mount -c test_cluster /pcs&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node reboot. Consult ''man pstorage-mount'' for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
 modprobe ploop pfmt_ploop1 pio_kaio&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at '''/pcs''' as described above if not done yet. Create a folder on Pstorage for the containers:&lt;br /&gt;
 mkdir -p /pcs/containers&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
 vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started on any Pstorage client node:&lt;br /&gt;
 vzctl start 101&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
What is [http://www.parallels.com/products/pcs/ Parallels Cloud Server]? Parallels Cloud Server is a unique virtualization server platform combining hypervisor &amp;amp; containers virtualization together with innovative storage virtualization [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudServer6_DataSheet_EN_Ltr_111312.pdf].&lt;br /&gt;
&lt;br /&gt;
Please request more information on upgrading to Parallels Cloud Server on a [http://www.parallels.com/products/pcs/ product page] (see '''Request Information''' button).&lt;br /&gt;
&lt;br /&gt;
==Pstorage Links &amp;amp; Documentation==&lt;br /&gt;
* Parallels Cloud Server [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudServer6_DataSheet_EN_Ltr_111312.pdf product datasheet].&lt;br /&gt;
* Parallels Cloud Storarage [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudStorage_DataSheet_EN_Ltr_02262013.pdf product datascheet].&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstroage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;br /&gt;
* YouTube introduction video [http://www.youtube.com/watch?v=6oEzW9w-1rg]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Ploop/OpenVZ_container_on_ploop_inside_Parallels_Cloud_Storage&amp;diff=14950</id>
		<title>Ploop/OpenVZ container on ploop inside Parallels Cloud Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Ploop/OpenVZ_container_on_ploop_inside_Parallels_Cloud_Storage&amp;diff=14950"/>
		<updated>2014-01-13T05:30:23Z</updated>

		<summary type="html">&lt;p&gt;Dev: Dev moved page Ploop/OpenVZ container on ploop inside Parallels Cloud Storage to Parallels Cloud Storage&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#REDIRECT [[Parallels Cloud Storage]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14948</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14948"/>
		<updated>2014-01-13T05:28:46Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
See a brief [http://www.youtube.com/watch?v=6oEzW9w-1rg video on YouTube].&lt;br /&gt;
&lt;br /&gt;
==OpenVZ limitations==&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#FF0000&amp;quot;&amp;gt;Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production.&amp;lt;br&amp;gt;To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below).&amp;lt;br&amp;gt;Maximum capacity limited for usage in technology preview mode is 100GB of logical (Containers usable) disk space.&amp;lt;br&amp;gt;After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit (it's not a bug :) ).&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf Pstorage manual] and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared and pstorage-metadata-server. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
 wget http://download.openvz.org/pstorage/*&lt;br /&gt;
 yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the cluster and the very first MDS type:&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of ''10.30.100.101'' for communication with this server (replace ''10.30.100.101'' with IP address of your own MDS server). MDS will store its data at location specified by '''-r''' option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service ('''pstorage-mdsd''') and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-mdsd start&lt;br /&gt;
 chkconfig pstorage-mdsd on&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
&lt;br /&gt;
1. Login to the node as root.&lt;br /&gt;
&lt;br /&gt;
2. Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the '''bs.list''' file in the '''/etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt;''' directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
 echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
&lt;br /&gt;
3. Authenticate the server in the cluster and add a new MDS to the cluster using similar to the above make-mds command w/o -I and -p options:&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
 pstorage -c test_cluster make-mds -a 10.30.100.102 -r /pstorage/test_cluster-mds&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
 pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after '''-r''' option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service ('''pstorage-csd''') and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-csd start&lt;br /&gt;
 chkconfig pstorage-csd on&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to and then mount it as a conventional file system:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /pcs&lt;br /&gt;
 pstorage-mount -c test_cluster /pcs&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node reboot. Consult ''man pstorage-mount'' for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
 modprobe ploop pfmt_ploop1 pio_kaio&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at '''/pcs''' as described above if not done yet. Create a folder on Pstorage for the containers:&lt;br /&gt;
 mkdir -p /pcs/containers&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
 vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started on any Pstorage client node:&lt;br /&gt;
 vzctl start 101&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
What is [http://www.parallels.com/products/pcs/ Parallels Cloud Server]? Parallels Cloud Server is a unique virtualization server platform combining hypervisor &amp;amp; containers virtualization together with innovative storage virtualization [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudServer6_DataSheet_EN_Ltr_111312.pdf].&lt;br /&gt;
&lt;br /&gt;
Please request more information on upgrading to Parallels Cloud Server on a [http://www.parallels.com/products/pcs/ product page] (see '''Request Information''' button).&lt;br /&gt;
&lt;br /&gt;
==Pstorage Links &amp;amp; Documentation==&lt;br /&gt;
* Parallels Cloud Server [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudServer6_DataSheet_EN_Ltr_111312.pdf product datasheet].&lt;br /&gt;
* Parallels Cloud Storarage [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Datasheets/ParCloudStorage_DataSheet_EN_Ltr_02262013.pdf product datascheet].&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstroage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;br /&gt;
* YouTube introduction video [http://www.youtube.com/watch?v=6oEzW9w-1rg]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14947</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14947"/>
		<updated>2014-01-13T05:22:57Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
See a brief [http://www.youtube.com/watch?v=6oEzW9w-1rg video on YouTube].&lt;br /&gt;
&lt;br /&gt;
==OpenVZ limitations==&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#FF0000&amp;quot;&amp;gt;Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production.&amp;lt;br&amp;gt;To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below).&amp;lt;br&amp;gt;Maximum capacity limited for usage in technology preview mode is 100GB of logical (Containers usable) disk space.&amp;lt;br&amp;gt;After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit (it's not a bug :) ).&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf Pstorage manual] and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared and pstorage-metadata-server. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
 wget http://download.openvz.org/pstorage/*&lt;br /&gt;
 yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the cluster and the very first MDS type:&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of ''10.30.100.101'' for communication with this server (replace ''10.30.100.101'' with IP address of your own MDS server). MDS will store its data at location specified by '''-r''' option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service ('''pstorage-mdsd''') and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-mdsd start&lt;br /&gt;
 chkconfig pstorage-mdsd on&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
&lt;br /&gt;
1. Login to the node as root.&lt;br /&gt;
&lt;br /&gt;
2. Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the '''bs.list''' file in the '''/etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt;''' directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
 echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
&lt;br /&gt;
3. Authenticate the server in the cluster and add a new MDS to the cluster using similar to the above make-mds command w/o -I and -p options:&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
 pstorage -c test_cluster make-mds -a 10.30.100.102 -r /pstorage/test_cluster-mds&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
 pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after '''-r''' option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service ('''pstorage-csd''') and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-csd start&lt;br /&gt;
 chkconfig pstorage-csd on&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to and then mount it as a conventional file system:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /pcs&lt;br /&gt;
 pstorage-mount -c test_cluster /pcs&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node reboot. Consult ''man pstorage-mount'' for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
 modprobe ploop pfmt_ploop1 pio_kaio&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at '''/pcs''' as described above if not done yet. Create a folder on Pstorage for the containers:&lt;br /&gt;
 mkdir -p /pcs/containers&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
 vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started on any Pstorage client node:&lt;br /&gt;
 vzctl start 101&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
Please request more information on upgrading to Parallels Cloud Server on a [http://www.parallels.com/products/pcs/ product page] (see '''Request Information''' button).&lt;br /&gt;
&lt;br /&gt;
==Pstorage Links &amp;amp; Documentation==&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstroage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;br /&gt;
* YouTube introduction video [http://www.youtube.com/watch?v=6oEzW9w-1rg]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14946</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14946"/>
		<updated>2014-01-13T05:16:13Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
See a brief [http://www.youtube.com/watch?v=6oEzW9w-1rg video on YouTube].&lt;br /&gt;
&lt;br /&gt;
==OpenVZ limitations==&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#FF0000&amp;quot;&amp;gt;Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production.&amp;lt;br&amp;gt;To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below).&amp;lt;br&amp;gt;Maximum capacity limited for usage in technology preview mode is 100GB of logical (Containers usable) disk space.&amp;lt;br&amp;gt;After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit (it's not a bug :) ).&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf Pstorage manual] and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared and pstorage-metadata-server. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
 wget http://download.openvz.org/pstorage/*&lt;br /&gt;
 yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the cluster and the very first MDS type:&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of ''10.30.100.101'' for communication with this server (replace ''10.30.100.101'' with IP address of your own MDS server). MDS will store its data at location specified by '''-r''' option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service (pstorage-mdsd) and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-mdsd start&lt;br /&gt;
 chkconfig pstorage-mdsd on&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
1. Login to the node as root.&lt;br /&gt;
2. Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the '''bs.list''' file in the '''/etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt;''' directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
 echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
3. Authenticate the server in the cluster and add a new MDS to the cluster using similar to the above make-mds command w/o -I and -p options:&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
 pstorage -c test_cluster make-mds -a 10.30.100.102 -r /pstorage/test_cluster-mds&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
 pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after -r option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service (pstorage-csd) and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-csd start&lt;br /&gt;
 chkconfig pstorage-csd on&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
Note, you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to and mount Pstorage cluster as a file system:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /pcs&lt;br /&gt;
 pstorage-mount -c test_cluster /pcs&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node reboot. Consult ''man pstorage-mount'' for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at /pcs as described above if not done yet.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
 modprobe ploop pfmt_ploop1 pio_kaio&lt;br /&gt;
&lt;br /&gt;
Create a folder on Pstorage for the containers:&lt;br /&gt;
 mkdir -p /pcs/containers&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
 vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started right from the cluster shared Pstorage:&lt;br /&gt;
 vzctl start 101&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
Please contact sales FIXME&lt;br /&gt;
&lt;br /&gt;
==Pstorage Links &amp;amp; Documentation==&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstroage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;br /&gt;
* YouTube introduction video [http://www.youtube.com/watch?v=6oEzW9w-1rg]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14945</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14945"/>
		<updated>2014-01-13T05:06:29Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
See a brief [http://www.youtube.com/watch?v=6oEzW9w-1rg video on YouTube].&lt;br /&gt;
&lt;br /&gt;
==OpenVZ limitations==&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#FF0000&amp;quot;&amp;gt;Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production.&amp;lt;br&amp;gt;To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below).&amp;lt;br&amp;gt;Available free capacity for in technology preview mode is 100GB of logical (Containers usable) disk space.&amp;lt;br&amp;gt;After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit.&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf Pstorage manual] and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared and pstorage-metadata-server. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
 wget http://download.openvz.org/pstorage/*&lt;br /&gt;
 yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the cluster and the very first MDS type:&lt;br /&gt;
&lt;br /&gt;
 pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of ''10.30.100.101'' for communication with this server (replace ''10.30.100.101'' with IP address of your own MDS server). MDS will store its data at location specified by '''-r''' option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service (pstorage-mdsd) and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
 service pstorage-mdsd start&lt;br /&gt;
 chkconfig pstorage-mdsd on&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
# Login to the node as root.&lt;br /&gt;
# Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the bs.list file in the /etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt; directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
 echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
# Authenticate the server in the cluster:&lt;br /&gt;
 pstorage -c test_cluster auth-node&lt;br /&gt;
# Add new MDS to the cluster using similar to above make-mds command w/o -I and -p options.&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
NOTE: you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after -r option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service (pstorage-csd) and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# service pstorage-csd start&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# chkconfig pstorage-csd on&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
NOTE: you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# mkdir -p /pcs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster as a file system:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage-mount -c test_cluster /pcs/&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node boot. Consult man pstorage-mount for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at /pcs as described above if not done yet.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# modprobe ploop pfmt_ploop1 pio_kaio&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Create a folder on Pstorage for the containers:&lt;br /&gt;
&amp;lt;code&amp;gt;# mkdir -p /pcs/containers&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started right from the cluster shared Pstorage:&lt;br /&gt;
&amp;lt;code&amp;gt;vzctl start 101&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
Please contact sales FIXME&lt;br /&gt;
&lt;br /&gt;
==Pstorage Links &amp;amp; Documentation==&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstroage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;br /&gt;
* YouTube introduction video [http://www.youtube.com/watch?v=6oEzW9w-1rg]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14944</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14944"/>
		<updated>2014-01-13T04:58:00Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
See a brief video on YouTube [http://www.youtube.com/watch?v=6oEzW9w-1rg].&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#FF0000&amp;quot;&amp;gt;Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production. &amp;lt;br&amp;gt;To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below).&amp;lt;br&amp;gt; Available free capacity for in technology preview mode is 100GB of logical (Containers usable) disk space.&amp;lt;br&amp;gt; After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit.&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult Pstorage manual (FIXME) and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared and pstorage-metadata-server. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
# wget FIXME&lt;br /&gt;
# yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the very first MDS and your cluster type:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of 10.30.100.101 for communication with this server (replace 10.30.100.101 with IP address of your own MDS server). MDS will store its data at location specified by -r option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service (pstorage-mdsd) and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# service pstorage-mdsd start&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# chkconfig pstorage-mdsd on&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
# Login to the node as root.&lt;br /&gt;
# Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the bs.list file in the /etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt; directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
&amp;lt;code&amp;gt;# echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&amp;lt;/code&amp;gt;&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
# Authenticate the server in the cluster:&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
# Add new MDS to the cluster using similar to above make-mds command w/o -I option.&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
NOTE: you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after -r option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service (pstorage-csd) and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# service pstorage-csd start&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# chkconfig pstorage-csd on&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
NOTE: you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# mkdir -p /pcs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster as a file system:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage-mount -c test_cluster /pcs/&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node boot. Consult man pstorage-mount for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at /pcs as described above if not done yet.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# modprobe ploop pfmt_ploop1 pio_kaio&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Create a folder on Pstorage for the containers:&lt;br /&gt;
&amp;lt;code&amp;gt;# mkdir -p /pcs/containers&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started right from the cluster shared Pstorage:&lt;br /&gt;
&amp;lt;code&amp;gt;vzctl start 101&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
Please contact sales FIXME&lt;br /&gt;
&lt;br /&gt;
==Pstorage Links &amp;amp; Documentation==&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstroage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;br /&gt;
* YouTube introduction video [http://www.youtube.com/watch?v=6oEzW9w-1rg]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14943</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14943"/>
		<updated>2014-01-13T04:55:59Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
See a brief video on YouTube http://www.youtube.com/watch?v=6oEzW9w-1rg].&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN.&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;span style=&amp;quot;color:#FF0000&amp;quot;&amp;gt;Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production. To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below). Available free capacity for in technology preview mode is 100GB of logical (Containers usable) disk space. After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit.&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult Pstorage manual (FIXME) and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared and pstorage-metadata-server. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
# wget FIXME&lt;br /&gt;
# yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the very first MDS and your cluster type:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of 10.30.100.101 for communication with this server (replace 10.30.100.101 with IP address of your own MDS server). MDS will store its data at location specified by -r option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service (pstorage-mdsd) and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# service pstorage-mdsd start&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# chkconfig pstorage-mdsd on&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
# Login to the node as root.&lt;br /&gt;
# Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the bs.list file in the /etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt; directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
&amp;lt;code&amp;gt;# echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&amp;lt;/code&amp;gt;&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
# Authenticate the server in the cluster:&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
# Add new MDS to the cluster using similar to above make-mds command w/o -I option.&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
NOTE: you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after -r option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service (pstorage-csd) and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# service pstorage-csd start&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# chkconfig pstorage-csd on&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
NOTE: you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# mkdir -p /pcs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster as a file system:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage-mount -c test_cluster /pcs/&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node boot. Consult man pstorage-mount for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at /pcs as described above if not done yet.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# modprobe ploop pfmt_ploop1 pio_kaio&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Create a folder on Pstorage for the containers:&lt;br /&gt;
&amp;lt;code&amp;gt;# mkdir -p /pcs/containers&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started right from the cluster shared Pstorage:&lt;br /&gt;
&amp;lt;code&amp;gt;vzctl start 101&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
Please contact sales FIXME&lt;br /&gt;
&lt;br /&gt;
==Pstorage Documentation==&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstroage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14942</id>
		<title>Virtuozzo Storage</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtuozzo_Storage&amp;diff=14942"/>
		<updated>2014-01-13T04:51:08Z</updated>

		<summary type="html">&lt;p&gt;Dev: added overview&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Parallels Cloud Storage (Pstorage) =&lt;br /&gt;
&lt;br /&gt;
Parallels Storage (Pstorage) is a highly-available distributed storage (virtual SAN) with built-in replication and disaster recovery. Pstorage provides a storage virtualization platform on top of commodity hardware with locally attached hard drives and enables the unification of storage into a cluster in scenarios like virtualization with the help of virtual machines (VMs) and/or Containers (CTs). Pstorage ensures a fast live migration of VMs and CTs across hardware nodes, without the need to copy VM/CT data, and high availability as the storage becomes available remotely.&lt;br /&gt;
&lt;br /&gt;
The main Pstorage features are listed below:&lt;br /&gt;
&lt;br /&gt;
* No special hardware requirements. Commodity hardware (SATA/SAS drives, 1Gbit+ Ethernet) can be used to create a storage.&lt;br /&gt;
* Strong consistency semantics. This makes Pstorage suitable for iSCSI, VMs and CTs running on top of it (unlike object storage such as Amazon S3 or Swift).&lt;br /&gt;
* Built-in replication.&lt;br /&gt;
* Automatic disaster recovery on hard drive or node failures.&lt;br /&gt;
* High availability. Data remain accessible even in case of hard drive or node failures.&lt;br /&gt;
* Optional SSD caching. SSD caches boost the overall performance in the cluster on write and read operations.&lt;br /&gt;
* Data checksumming and scrubbing. Checksumming and scrubbing greatly enhance data reliability.&lt;br /&gt;
* Grow on demand. More storage nodes can be added to the cluster to increase its disk space. A VM/CT image size is not limited by the size of any of the hard drives.&lt;br /&gt;
* Scales to Petabytes&lt;br /&gt;
* More uniform hardware performance and capacity utilization across the nodes, so overutilized nodes benefit from idle ones.&lt;br /&gt;
* High performance - comparable to SAN (FIXME link).&lt;br /&gt;
&lt;br /&gt;
NOTE: Parallels Cloud Storage is available as a TECHNOLOGY PREVIEW ONLY for OpenVZ users and can't be licensed for production. To unlock for running in production you should upgrade to a full Parallels Cloud Server product (see below). Available free capacity for in technology preview mode is 100GB of logical (Containers usable) disk space. After hitting this limit writers can get blocked w/o errors expecting for a limit to be extended, so please avoid hitting the limit.&lt;br /&gt;
&lt;br /&gt;
==Pstorage components==&lt;br /&gt;
Any Pstorage includes three components:&lt;br /&gt;
&lt;br /&gt;
* Metadata server (MDS). MDSs manage metadata, like file names, and keep control over how files are split into chunks and where the chunks are stored. They also track versions of chunks and ensure that the cluster has enough replicas. An MDS can be run in multiple instances to provide high availability. Besides, MDSs keep a global log of important events that happen in the cluster.&lt;br /&gt;
* Chunk server (CS). A CS is a service responsible for storing real user data chunks and providing access to these data. A Pstorage cluster must have multiple instances of CSs for high availability.&lt;br /&gt;
* Clients. Clients access a Pstorage cluster by communicating with MDSs and CSs. Parallels Containers and virtual machines can be run natively, i.e. directly from the Pstorage cluster. An additional Pstorage client -  can be used to mount Pstorage as a conventional file system (though Pstorage is not POSIX-compliant). Besides, Pstorage files can be mounted as a block device using the &amp;quot;ploop&amp;quot; feature and formatted as ext4 file system for other needs.&lt;br /&gt;
&lt;br /&gt;
A recommended cluster setup includes from 3 to 5 MDS instances (allowing you to survive the loss of 1 or 2 of MDSs, respectively) and multiple CSs providing storage capacity.&lt;br /&gt;
&lt;br /&gt;
=Pstorage setup HOWTO=&lt;br /&gt;
Below HOWTO explains how to setup Parallels Cloud Storage (Pstorage) cluster and run OpenVZ containers stored there. Please note, that it's just a brief HOWTO for quick and easy evaluation of Parallels Cloud Storage (configuring only 1x MDS and CS service) and is not a real manual. We highly recommend to consult Pstorage manual (FIXME) and man pages (such as pstorage, pstorage-make-cs, pstorage-make-mds etc.) as it contain a lot of important details on types of SSD drives supported, what are the recommended configurations, how to configure big clusters with failure domains and so on.&lt;br /&gt;
&lt;br /&gt;
==Installing Parallels Cloud Storage software==&lt;br /&gt;
&lt;br /&gt;
In order to install Pstorage RPM packages log in as root to all the machines planned to be added to the cluster and perform the following actions.&lt;br /&gt;
&lt;br /&gt;
Download and install the following RPM packages: pstorage-ctl, pstorage-libs-shared and pstorage-metadata-server. These packages can be downloaded from http://download.openvz.org/pstorage:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
# wget FIXME&lt;br /&gt;
# yum install pstorage-ctl pstorage-libs-shared pstorage-metadata-server pstorage-chunk-server pstorage-client&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Creating a cluster==&lt;br /&gt;
&lt;br /&gt;
Every Pstorage cluster has a unique cluster name used for remote service discovery and during authorization.&lt;br /&gt;
So choose a name for the cluster that will uniquely identify it among other clusters in your network and avoid reusing it on cluster recreate. A name may contain the characters a-z, A-Z, 0-9, dash (-), and underscore (_). Here we will use 'test_cluster' as a cluster name.&lt;br /&gt;
&lt;br /&gt;
===Create metadata servers (MDS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computers you want to configure as a metadata server as root.&lt;br /&gt;
&lt;br /&gt;
To create the very first MDS and your cluster type:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster make-mds -I -a 10.30.100.101 -r /pstorage/test_cluster-mds -p&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This command creates new Parallels Cloud Storage cluster and metadata server and configures the IP address of 10.30.100.101 for communication with this server (replace 10.30.100.101 with IP address of your own MDS server). MDS will store its data at location specified by -r option. The command will also ask you to enter the password for authentication in your cluster.&lt;br /&gt;
&lt;br /&gt;
After you have created the MDS server, start the MDS management service (pstorage-mdsd) and configure it to start automatically when the server boots:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# service pstorage-mdsd start&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# chkconfig pstorage-mdsd on&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To create 2nd and subsequent MDS services on other nodes do:&lt;br /&gt;
# Login to the node as root.&lt;br /&gt;
# Setup cluster discovery. Normally, all the Pstorage components should be capable to discover each other on the network using multicast discovery (mDNS). This may not work however in Virtual Machines or if your network doesn't support multicasts. In this case you need to setup an MDS bootstrap list on the nodes manually. To do so create the bs.list file in the /etc/pstorage/clusters/&amp;lt;cluster_name&amp;gt; directory (make this directory if it does not exist) on the server you are configuring for the cluster and specify IP addresses and ports of the MDS servers in the cluster.&lt;br /&gt;
For example to create a bootstrap list for above cluster created type:&lt;br /&gt;
&amp;lt;code&amp;gt;# echo &amp;quot;10.30.100.101:2510&amp;quot; &amp;gt;&amp;gt; /etc/pstorage/clusters/test_cluster/bs.list&amp;lt;/code&amp;gt;&lt;br /&gt;
Now future Pstorage services started on this machine will be able to discover other parties.&lt;br /&gt;
# Authenticate the server in the cluster:&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
# Add new MDS to the cluster using similar to above make-mds command w/o -I option.&lt;br /&gt;
&lt;br /&gt;
===Create chunk server (CS)===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to configure as a chunk server as root.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
NOTE: you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create CS:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster make-cs -r /pstorage/test_cluster-cs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This command will create a CS service and use the directory specified after -r option for CS data store.&lt;br /&gt;
After you have created the chunk server, start is as a service (pstorage-csd) and configure it to start automatically when the machine boots:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# service pstorage-csd start&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# chkconfig pstorage-csd on&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Setting up a client===&lt;br /&gt;
&lt;br /&gt;
Log in to the computer you want to act as a client as root.&lt;br /&gt;
&lt;br /&gt;
Authenticate the server in the cluster (skip this step if configured MDS or CS already on that server):&lt;br /&gt;
NOTE: you may need to setup a bootstrap list as described above in case cluster auto-discovery doesn't work.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage -c test_cluster auth-node&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The command will ask you the password that you specified when setting up the first MDS server.&lt;br /&gt;
&lt;br /&gt;
Create the directory to mount the Parallels Cloud Storage cluster to:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# mkdir -p /pcs&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster as a file system:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# pstorage-mount -c test_cluster /pcs/&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may want to add this mount to /etc/fstab to make it happen automatically on node boot. Consult man pstorage-mount for more details.&lt;br /&gt;
&lt;br /&gt;
Now you can access your data from all the client machines and ready to run containers!&lt;br /&gt;
&lt;br /&gt;
===Create a container running in the cluster===&lt;br /&gt;
&lt;br /&gt;
Running a container over Pstrage is no different from any other local file system, so below example is just for the reference.&lt;br /&gt;
Log in to the computer running OpenVZ and that you have configured to act as a client for the Parallels Cloud Storage cluster.&lt;br /&gt;
&lt;br /&gt;
Mount Pstorage cluster at /pcs as described above if not done yet.&lt;br /&gt;
&lt;br /&gt;
Load OpenVZ ploop kernel modules if they aren't loaded yet:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;# modprobe ploop pfmt_ploop1 pio_kaio&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Create a folder on Pstorage for the containers:&lt;br /&gt;
&amp;lt;code&amp;gt;# mkdir -p /pcs/containers&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Create a ploop-based container with CTID=101 (put your own template name below):&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;vzctl create 101 --layout ploop --ostemplate centos-6-x86_64 --private /pcs/containers/&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now container with CTID=101 is ready for use and can be started right from the cluster shared Pstorage:&lt;br /&gt;
&amp;lt;code&amp;gt;vzctl start 101&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In order to quickly relocate the container to another node (w/o data migration), just stop and unregister it on source node, then register and start on destination.&lt;br /&gt;
&lt;br /&gt;
==Upgrading to Parallels Cloud Server==&lt;br /&gt;
Please contact sales FIXME&lt;br /&gt;
&lt;br /&gt;
==Pstorage Documentation==&lt;br /&gt;
* For more information on setting up pstorage cluster please refer to the Parallels Cloud Storage documentation [http://download.parallels.com/doc/pcs/pdf/Parallels_Cloud_Storage.pdf].&lt;br /&gt;
* Pstroage performance whitepaper [http://www.parallels.com/fileadmin/parallels/documents/hosting-cloud-enablement/pcs/Production_Whitepapers/PCloudStorage_Performance_Results_WP_EN_Ltr_02192013_web.pdf].&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=FAQ&amp;diff=11789</id>
		<title>FAQ</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=FAQ&amp;diff=11789"/>
		<updated>2012-01-06T17:37:46Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== General ==&lt;br /&gt;
===== What is a container (Virtual Environment, Virtual Private Server, VPS, VE)? =====&lt;br /&gt;
:See [[Container]].&lt;br /&gt;
&lt;br /&gt;
===== What are highlights of OpenVZ technology? =====&lt;br /&gt;
In short, OpenVZ is the only highly scalable virtualization technology with near-zero overhead, strong isolation and rapid customer provisioning that's ready for production use right now. Deployment of OpenVZ improves efficiency, flexibility and quality of service in the enterprise environment.&lt;br /&gt;
&lt;br /&gt;
===== Who needs OpenVZ? How it can be used? =====&lt;br /&gt;
:See [[Use cases]].&lt;br /&gt;
&lt;br /&gt;
===== What applications can run inside an OpenVZ container? =====&lt;br /&gt;
&lt;br /&gt;
Most applications can be installed to a container without any modifications. Oracle, DB/2, Weblogic, Websphere and other big applications run just fine inside an OpenVZ container. Applications and services do not have to be aware of OpenVZ. However, direct access to hardware is not available by default.&lt;br /&gt;
&lt;br /&gt;
===== How is OpenVZ different from other technologies? =====&lt;br /&gt;
:See [[Introduction to virtualization]].&lt;br /&gt;
&lt;br /&gt;
===== How is OpenVZ secured &amp;amp; updated? =====&lt;br /&gt;
:See [[Security]].&lt;br /&gt;
&lt;br /&gt;
===== How scalable is OpenVZ? =====&lt;br /&gt;
&lt;br /&gt;
OpenVZ technology scales perfectly as standart Linux kernel does - up to thousands of CPUs and TBs of RAM. Besides, a single container could be scaled up from taking a little fraction of available resources up to all resources available dynamically - you do not even have to restart the container. For example, containers can natively use up to all available CPUs which is different from hypervisor technology which requires special tricks like co-scheduling and even best hypervisors are inefficient with more then 4-8 vCPUs.&lt;br /&gt;
&lt;br /&gt;
===== How does OpenVZ improve efficiency of services? =====&lt;br /&gt;
&lt;br /&gt;
For existing hardware, OpenVZ allows to utilize its processing power better by improving average load from 3-5% to at least 30-50%, while still providing ability to handle peak loads. To decrease complexity, OpenVZ provides standardized and centralized server management, logically decoupled from actual hardware. And when its time to buy new servers, you can now use few more powerful servers instead of many little ones — with added benefits of better reliability, better peak performance and typically longer lifespan.&lt;br /&gt;
&lt;br /&gt;
===== How does OpenVZ improve flexibility of services? =====&lt;br /&gt;
&lt;br /&gt;
By providing unified scalable platform with such unique features as rapid application and updates provisioning. Each container is hardware independent and can be moved to another OpenVZ-based system in seconds over the network. This allows for ease of hardware maintenance (move out all containers and do whatever you need with the box) and improved availability (keep a synchronized copy of your container elsewhere and start it up when primary service failed). If your old box is not able to cope with peak load anymore, just move your containers to a new one.&lt;br /&gt;
&lt;br /&gt;
===== What is a performance overhead? =====&lt;br /&gt;
&lt;br /&gt;
Near zero. There is no emulation layer, only security isolation, and all checking is done on the kernel level without context switching.&lt;br /&gt;
&lt;br /&gt;
===== What are performance expectations? =====&lt;br /&gt;
&lt;br /&gt;
Peak performance is achieved when only one container has active tasks. In this case, it could use 100% of available resources: all CPUs, all physical memory, all disk and network bandwidth. OpenVZ is not limiting you to a single-CPU virtual machine. &lt;br /&gt;
&lt;br /&gt;
===== I want to show my appreciation to OpenVZ and put some logo to my site. Where to get it? =====&lt;br /&gt;
:See [[Artwork]].&lt;br /&gt;
&lt;br /&gt;
===== Are there any control panels available for OpenVZ? =====&lt;br /&gt;
:See [[Control_panels]].&lt;br /&gt;
&lt;br /&gt;
== Installation and upgrade ==&lt;br /&gt;
&lt;br /&gt;
===== What hardware is supported by OpenVZ kernel? =====&lt;br /&gt;
:See [http://www.parallels.com/en/products/virtuozzo/hcl/ Virtuozzo HCL].&lt;br /&gt;
&lt;br /&gt;
===== Why there are different kernel flavours available and what do they mean? =====&lt;br /&gt;
:See [[Different kernel flavors (UP, SMP, ENTERPRISE, ENTNOSPLIT)]].&lt;br /&gt;
&lt;br /&gt;
===== How do I rebuild the kernel? =====&lt;br /&gt;
:See [[Kernel build]].&lt;br /&gt;
&lt;br /&gt;
===== What does 021stab018 in OpenVZ kernel version mean? =====&lt;br /&gt;
:See [[Kernel versioning]].&lt;br /&gt;
&lt;br /&gt;
===== How can I check package signatures? =====&lt;br /&gt;
:See [[Package signatures]].&lt;br /&gt;
&lt;br /&gt;
===== Is it possible to run x86 container on a x86_64 arch? =====&lt;br /&gt;
:Sure :) We actually did some work on that to enable migration of x86 container from x86 to x86_64 and back, and to enable using 32-bit iptables in 32bit container on an x86_64 system.&lt;br /&gt;
&lt;br /&gt;
===== What filesystems should I choose for saving my containers? =====&lt;br /&gt;
: Any filesystem which supports Unix style permissions is usable, such as Ext3 or ReiserFS. XFS works, but does not have support for disk quotas inside containers.&lt;br /&gt;
&lt;br /&gt;
== Networking ==&lt;br /&gt;
&lt;br /&gt;
===== How do I set up VPN for a container? =====&lt;br /&gt;
:See [[VPN via the TUN/TAP device]].&lt;br /&gt;
&lt;br /&gt;
===== What is veth and how do I use it? =====&lt;br /&gt;
:See [[Virtual Ethernet device]].&lt;br /&gt;
&lt;br /&gt;
===== Why doesn't net-snmpd work on my containers? =====&lt;br /&gt;
:See [[SNMPD in container]].&lt;br /&gt;
&lt;br /&gt;
== User Beancounters (UBC) ==&lt;br /&gt;
&lt;br /&gt;
===== What are those User Beancounters? =====&lt;br /&gt;
See [[UBC]].&lt;br /&gt;
&lt;br /&gt;
===== What units are UBC parameters measured in? =====&lt;br /&gt;
See [[UBC parameter units]].&lt;br /&gt;
&lt;br /&gt;
===== How do I set up a container which is able to get X Mb of RAM? =====&lt;br /&gt;
See [[Setting UBC parameters]].&lt;br /&gt;
&lt;br /&gt;
===== I can not start a program in container: it reports out of memory. What do I do? =====&lt;br /&gt;
See [[Resource_shortage]].&lt;br /&gt;
&lt;br /&gt;
===== How can I reset &amp;lt;code&amp;gt;failcnt&amp;lt;/code&amp;gt; in &amp;lt;code&amp;gt;/proc/user_beancounters&amp;lt;/code&amp;gt;? =====&lt;br /&gt;
See [[UBC failcnt reset]].&lt;br /&gt;
&lt;br /&gt;
== Troubleshooting ==&lt;br /&gt;
===== My kernel crashed. What should I do? =====&lt;br /&gt;
:See [[When you have an oops]].&lt;br /&gt;
&lt;br /&gt;
===== I see a lot of processes in D state. What does that mean? =====&lt;br /&gt;
:See [[Processes in D state]].&lt;br /&gt;
&lt;br /&gt;
== Quick reference card for OpenVZ ==&lt;br /&gt;
{{PDFlink|[http://pronics.fi/~eero/mirrors/openvz-reference-card.pdf openvz-reference-card.pdf]}} BROKEN LINK&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Different_kernel_flavors_(UP,_SMP,_ENTERPRISE,_ENTNOSPLIT)&amp;diff=11788</id>
		<title>Different kernel flavors (UP, SMP, ENTERPRISE, ENTNOSPLIT)</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Different_kernel_flavors_(UP,_SMP,_ENTERPRISE,_ENTNOSPLIT)&amp;diff=11788"/>
		<updated>2012-01-06T17:31:33Z</updated>

		<summary type="html">&lt;p&gt;Dev: added RHEL6 flavors&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;OpenVZ project releases several different precompiled kernels for each version. Which kernel to choose depends on what hardware do you have. The table below describes the cases when it is better to use each of these kernels.&lt;br /&gt;
&lt;br /&gt;
== RHEL6-based kernels ==&lt;br /&gt;
&lt;br /&gt;
RHEL6 kernels come in single flavor only which is SMP and PAE (for 32bit) enabled. This is because nowadays it's hard to find single core CPUs and less then 4GB RAM machines.&lt;br /&gt;
{{Note|RHEL6 kernels no longer support enterprise versions of 32bit kernels with 4/4GB split, which limits 32bit version.}}&lt;br /&gt;
&lt;br /&gt;
== RHEL5-based kernels ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+'''i686 kernel flavors list'''&lt;br /&gt;
! Kernel type !! Description !! Hardware !! Use case&lt;br /&gt;
|-&lt;br /&gt;
! i686 UP&lt;br /&gt;
| uniprocessor&lt;br /&gt;
| up to 4GB of RAM&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
! i686 SMP&lt;br /&gt;
| symmetric multiprocessor&lt;br /&gt;
| up to 4 GB of RAM&lt;br /&gt;
| 10-20 [[Container]]s&lt;br /&gt;
|-&lt;br /&gt;
! i686 entnosplit/PAE&lt;br /&gt;
| SMP + PAE support&lt;br /&gt;
| up to 64 GB of RAM&lt;br /&gt;
| 10-30 [[Container]]s&lt;br /&gt;
|-&lt;br /&gt;
! i686 enterprise/ent&lt;br /&gt;
| SMP + PAE support + 4/4GB split&lt;br /&gt;
| up to 64 GB of RAM&lt;br /&gt;
| &amp;gt;20 [[Container]]s&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
These kernels are optimized for these types of hardware configurations and usage scenarios,&lt;br /&gt;
so choosing the right kernel can help to boost performance by about 5 to 15 per cent.&lt;br /&gt;
&lt;br /&gt;
{{Note|Use &amp;lt;tt&amp;gt;rpm -ihv&amp;lt;/tt&amp;gt; command for ovzkernel RPM installation. Please do not use the &amp;lt;tt&amp;gt;rpm -Uhv&amp;lt;/tt&amp;gt; command to install the kernel, otherwise all the previously installed kernels may be removed from your system.}}&lt;br /&gt;
&lt;br /&gt;
{{Note|When using a &amp;lt;b&amp;gt;64-bit&amp;lt;/b&amp;gt; processor &amp;lt;b&amp;gt;and&amp;lt;/b&amp;gt; operating system, you need only select the SMP or non-SMP version. With the Redhat repos this will be ''ovzkernel.x86_64''. 64-bit linux can access the entire RAM in ZONE_NORMAL (low memory).  PAE and 4GB/4GB splitting is only needed for 32-bit OS, and so are not necessary and are disabled by default in 64-bit kernels.}}&lt;br /&gt;
&lt;br /&gt;
New RHEL5 based kernel uses different flavors naming: &lt;br /&gt;
* '''UP''' kernel is no longer provided &lt;br /&gt;
* '''SMP''' kernel comes without any flavor (like old UP)&lt;br /&gt;
* '''entnosplit''' kernel comes as '''PAE '''&lt;br /&gt;
* '''enterprise''' kernel comes as '''ent'''&lt;br /&gt;
* '''ovzkernel.x86_64''' for 64-bit&lt;br /&gt;
&lt;br /&gt;
[[Category: Kernel]]&lt;br /&gt;
[[Category: Installation]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_performance&amp;diff=10194</id>
		<title>WP/Containers performance</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_performance&amp;diff=10194"/>
		<updated>2011-04-22T13:22:36Z</updated>

		<summary type="html">&lt;p&gt;Dev: Created page with '__NOTOC__ = Containers performance and low overhead =  == What is density? =='&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
= Containers performance and low overhead =&lt;br /&gt;
&lt;br /&gt;
== What is density? ==&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance/Microbenchmarks&amp;diff=10193</id>
		<title>Performance/Microbenchmarks</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance/Microbenchmarks&amp;diff=10193"/>
		<updated>2011-04-22T13:12:01Z</updated>

		<summary type="html">&lt;p&gt;Dev: Created page with '== Benchmark description ==  === Testbed Configuration === Hardware * Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM * Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM * N…'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Benchmark description ==&lt;br /&gt;
&lt;br /&gt;
=== Testbed Configuration ===&lt;br /&gt;
Hardware&lt;br /&gt;
* Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM&lt;br /&gt;
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM&lt;br /&gt;
* Network: 1Gbit direct server&amp;lt;&amp;gt;client connection&lt;br /&gt;
&lt;br /&gt;
Platform:&lt;br /&gt;
* Virtualization Software: Xen CentOS 5.5 x86_64, OpenVZ (RHEL6) 2.6.32-042test006.1.x86_64&lt;br /&gt;
* Guest OS: CentOS 5.5 x86_64&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Results ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Benchmarks&lt;br /&gt;
|-&lt;br /&gt;
|| '''Operation'''&lt;br /&gt;
|| #1 Native CentOS 5.5 x64 kernel 2.6.18&lt;br /&gt;
|| #2 Xen CentOS 5.5 x64 kernel 2.6.18&lt;br /&gt;
|| #3 OpenVZ CentOS 5.5 x64 kernel 2.6.18&lt;br /&gt;
|| #4 Native RHEL 6.0 x64 kernel 2.6.32&lt;br /&gt;
|| #5 VzLin RHEL 6.0 x64 kernel 2.6.32&lt;br /&gt;
|-&lt;br /&gt;
|| Context switch using pipe || 251K || 126K || . || 194K || 166K&lt;br /&gt;
|-&lt;br /&gt;
|| Context switch using pipe (8 threads) || 6028K || 605K || 4807K || 3993K || 3686K&lt;br /&gt;
|-&lt;br /&gt;
|| Process execve() || 3162 || 1074 || 4217 || 8052 || 7288&lt;br /&gt;
|-&lt;br /&gt;
|| Process fork() || 4630 || 1958 || 5728 || 14773 || 14182&lt;br /&gt;
|-&lt;br /&gt;
|| System call || 4381K || 993K || 3583K || 4854K || 3408K&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance&amp;diff=10187</id>
		<title>Performance</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance&amp;diff=10187"/>
		<updated>2011-04-22T11:51:25Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Benchmark results ==&lt;br /&gt;
&lt;br /&gt;
This page is to collect a list of benchmark results available and demonstrate not only the words about containers technology being more superior from performance point of view compared to hypervisors but also to provide some data proving that.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Benchmarks&lt;br /&gt;
|-&lt;br /&gt;
|| '''Benchmark''' || '''Description'''&lt;br /&gt;
|-&lt;br /&gt;
|| [[/Response Time/]]&lt;br /&gt;
|| Microbenchmark demonstrating latency issues of interactive applications in virtualized and loaded systems (netperf RR in various conditions).&lt;br /&gt;
|-&lt;br /&gt;
|| [[/Network Throughput/]]&lt;br /&gt;
|| 10Gbit simple network throughput comparison using netperf test.&lt;br /&gt;
|-&lt;br /&gt;
|| [[/LAMP/]]&lt;br /&gt;
|| Linux Apache+MySql+PHP (LAMP) stack benchmark in multiple simultaneously running virtualization instances.&lt;br /&gt;
|-&lt;br /&gt;
|| [[/vConsolidate-UP/]]&lt;br /&gt;
|| UP configuration of Intel vConsolidate server consolidation benchmark (Java+Apache+MySQL workloads).&lt;br /&gt;
|-&lt;br /&gt;
|| [[/vConsolidate-SMP/]]&lt;br /&gt;
|| SMP configuration of Intel vConsolidate server consolidation benchmark (Java+Apache+MySQL workloads).&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== External sources ==&lt;br /&gt;
* [http://www.hpl.hp.com/techreports/2007/HPL-2007-59R1.pdf HP Labs: Performance Evaluation of Virtualization Technologies for Server Consolidation]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance&amp;diff=10174</id>
		<title>Performance</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance&amp;diff=10174"/>
		<updated>2011-04-22T10:59:24Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* [[/Response Time/]]&lt;br /&gt;
* [[/Network Throughput/]]&lt;br /&gt;
* [[/LAMP/]]&lt;br /&gt;
* [[/vConsolidate-UP/]]&lt;br /&gt;
* [[/vConsolidate-SMP/]]&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+ Benchmarks&lt;br /&gt;
|-&lt;br /&gt;
! Benchmark ! Description&lt;br /&gt;
|-&lt;br /&gt;
|[[/Response Time/]]&lt;br /&gt;
|| Latency&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance/vConsolidate-SMP&amp;diff=10164</id>
		<title>Performance/vConsolidate-SMP</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance/vConsolidate-SMP&amp;diff=10164"/>
		<updated>2011-04-22T09:13:00Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== Benchmark Description ===&lt;br /&gt;
&lt;br /&gt;
The goal of Intel vConsolidate benchmark is to measure aggregated server performance in consolidation scenario: when different (and non-related unlike to LAMP benchmark) applications are running on the same box each in its own virtual environment (virtual machine or container).&lt;br /&gt;
&lt;br /&gt;
vConsolidate benchmark was developed by Intel in cooperation with other vendors. It runs separate workloads with Java (SPECjbb test), Mail, Web and Database VMs running concurrently. Each set of such VMs is called CSU - Consolidation Stack Unit. Performance metric is a geomean from throughput of each workload type: transactions/sec for Db, requests/sec for Web and java operations/sec for Java. The same type of metric is commonly used in other benchmarks like those from SPEC.&lt;br /&gt;
&lt;br /&gt;
vConsolidate benchmark is very similar to other virtualization specific benchmarks like VMMark from VMWare and SPECvirt, but the latter are more enterprise oriented and generate the load requiring a fast SAN storage and high end hardware. Since we believe containers benefits are even more prominent on commodity hardware we use vConsolidate benchmark to demonstrate that.&lt;br /&gt;
&lt;br /&gt;
=== Implementation ===&lt;br /&gt;
&lt;br /&gt;
Intel vConsolidate v1.1. We do not run Mail VM as Intel benchmark has Microsoft Windows version only for mail workload.&lt;br /&gt;
&lt;br /&gt;
=== Testbed Configuration ===&lt;br /&gt;
Hardware:&lt;br /&gt;
* Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0&lt;br /&gt;
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM&lt;br /&gt;
* Network: 1Gbit direct server &amp;lt;-&amp;gt; client connection&lt;br /&gt;
&lt;br /&gt;
Platform:&lt;br /&gt;
* Virtualization Software: XenServer5.6fp1, OpenVZ (RH5) 2.6.18-028stab085.3, OpenVZ (RH6) 2.6.32-042test006.1.x86_64&lt;br /&gt;
* Guest OS: Centos 5.5 x86_64&lt;br /&gt;
&lt;br /&gt;
Software and Tunings:&lt;br /&gt;
* Each VM/CT was configured with 4 vCPUs, 1 GB RAM&lt;br /&gt;
* Custom vConsolidate profile was used: 4 load threads for Java workload, 4 load threads for Db workload and 8 threads for Web workload (standard setting)&lt;br /&gt;
* Firewall was turned off&lt;br /&gt;
* All other settings were left as defaults&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Results ===&lt;br /&gt;
&lt;br /&gt;
[[File:vConsolidate-SMP.png]]&lt;br /&gt;
&lt;br /&gt;
=== Summary ===&lt;br /&gt;
&lt;br /&gt;
OpenVZ demonstrates outstanding performance benefits over hypervisors in case of multi-processor environments and multi-threaded workloads:&lt;br /&gt;
* Almost 3x times better overall performance in case of single set of workloads (1 CSU).&lt;br /&gt;
* 2.1-2.2x times better overall performance on 5 and 10 CSU.&lt;br /&gt;
&lt;br /&gt;
=== TODO ===&lt;br /&gt;
* add ESX&lt;br /&gt;
* add a link to paper where explaining why containers are great for SMP workloads and CPU overcommit.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance/vConsolidate-UP&amp;diff=10163</id>
		<title>Performance/vConsolidate-UP</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance/vConsolidate-UP&amp;diff=10163"/>
		<updated>2011-04-22T08:58:11Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== Benchmark Description ===&lt;br /&gt;
&lt;br /&gt;
The goal of Intel vConsolidate benchmark is to measure aggregated server performance in consolidation scenario: when different (and non-related unlike to LAMP benchmark) applications are running on the same box each in its own virtual environment (virtual machine or container).&lt;br /&gt;
&lt;br /&gt;
vConsolidate benchmark was developed by Intel in cooperation with other vendors. It runs separate workloads with Java (SPECjbb test), Mail, Web and Database VMs running concurrently. Each set of such VMs is called CSU - Consolidation Stack Unit. Performance metric is a geomean from throughput of each workload type: transactions/sec for Db, requests/sec for Web and java operations/sec for Java. The same type of metric is commonly used in other benchmarks like those from SPEC.&lt;br /&gt;
&lt;br /&gt;
vConsolidate benchmark is very similar to other virtualization specific benchmarks like VMMark from VMWare and SPECvirt, but the latter are more enterprise oriented and generate the load requiring a fast SAN storage and high end hardware. Since we believe containers benefits are even more prominent on commodity hardware we use vConsolidate benchmark to demonstrate that.&lt;br /&gt;
&lt;br /&gt;
=== Implementation ===&lt;br /&gt;
&lt;br /&gt;
Intel vConsolidate v1.1. We do not run Mail VM as Intel benchmark has Microsoft Windows version only for mail workload.&lt;br /&gt;
&lt;br /&gt;
=== Testbed Configuration ===&lt;br /&gt;
Hardware:&lt;br /&gt;
* Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0&lt;br /&gt;
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM&lt;br /&gt;
* Network: 1 Gbit direct server &amp;lt;-&amp;gt; client connection&lt;br /&gt;
&lt;br /&gt;
Platform:&lt;br /&gt;
* Virtualization Software:ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH5) 2.6.18-028stab085.3&lt;br /&gt;
* Guest OS: Centos 5.5 x86_64&lt;br /&gt;
&lt;br /&gt;
Software and Tunings:&lt;br /&gt;
* Each VM/CT was configured with 1 vCPU, 1 GB RAM&lt;br /&gt;
* Custom vConsolidate profile was used: 4 load threads for Java workload, 4 load threads for Db workload and 8 threads for Web workload (standard settings).&lt;br /&gt;
* Firewall was turned off&lt;br /&gt;
* All other settings were left as defaults&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Results ===&lt;br /&gt;
&lt;br /&gt;
[[File:vconsolidate-UP.png]]&lt;br /&gt;
&lt;br /&gt;
[[File:vconsolidate-up-table.png]]&lt;br /&gt;
=== Summary ===&lt;br /&gt;
* Even on a small number of workloads OpenVZ virtualization demonstrates ~20% better overall performance compared to fastest VM products&lt;br /&gt;
* When more and more workloads are added to the server OpenVZ demonstrated ~25% better overall perforamnance&lt;br /&gt;
&lt;br /&gt;
=== TODO ===&lt;br /&gt;
* add links to benchmarks&lt;br /&gt;
* TODO: write summary&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance/LAMP&amp;diff=10162</id>
		<title>Performance/LAMP</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance/LAMP&amp;diff=10162"/>
		<updated>2011-04-21T16:35:20Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== Benchmark Description ===&lt;br /&gt;
&lt;br /&gt;
LAMP (acronym for Linux, Apache, MySQL, PHP) software stack is widely used for building modern web sites on Linux. So it's quite natural that there is a need to understand how well such type of workloads run in virtualized environment and how many LAMPs virtualization can bare on a single piece of hardware. 2 important metrics are presented in this report: total number of serviced requests/sec and average response time.&lt;br /&gt;
&lt;br /&gt;
=== Implementation ===&lt;br /&gt;
&lt;br /&gt;
To measure LAMP software stack performance and density we use DVD-Store E-Commerce benchmark developed by [http://linux.dell.com/dvdstore/ Dell]. This benchmark is also widely used by RedHat and others.&lt;br /&gt;
&lt;br /&gt;
=== Testbed Configuration ===&lt;br /&gt;
Hardware:&lt;br /&gt;
* Server: 4xHexCore Intel Xeon (2.66 GHz), 64 GB RAM, HP MSA1500 SAN Storage, 8 SATA (7200 RPM) Disks in RAID0&lt;br /&gt;
*Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM&lt;br /&gt;
* Network: 1Gbit direct server &amp;lt;-&amp;gt; client connection&lt;br /&gt;
&lt;br /&gt;
Platform:&lt;br /&gt;
* Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64&lt;br /&gt;
* Guest OS: Centos 5.5 x86_64&lt;br /&gt;
&lt;br /&gt;
Software and Tunings:&lt;br /&gt;
* Each VM/CT was configured with 1 vCPU, 1 GB RAM&lt;br /&gt;
* Small db was deployed from DVD Store samples&lt;br /&gt;
* Dvd Store benchmark client run string: ds2webdriver.exe --target=172.0.1.%VM% --think_time=0.05 --n_threads=3 --warmup_time=10 --run_time=10 --db_size_str=S --n_line_items=1 --pct_newcustomers=1&lt;br /&gt;
* Firewall was turned off&lt;br /&gt;
* All other tunings were left at default values&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Results ===&lt;br /&gt;
&lt;br /&gt;
[[File:lamp_performance_v2.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:lamp_rt_v2.png]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Summary ===&lt;br /&gt;
&lt;br /&gt;
* OpenVZ shows the best performance over solutions tested: OpenVZ 38% faster than XenServer and more than x2 times faster than HyperV and ESXi under high load.&lt;br /&gt;
* OpenVZ shows the best response time over solutions tested: 33% better response time compared to ESXi and x2 times better response time than XenServer and HyperV&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance/Network_Throughput&amp;diff=10160</id>
		<title>Performance/Network Throughput</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance/Network_Throughput&amp;diff=10160"/>
		<updated>2011-04-21T16:09:34Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=== Benchmark Description ===&lt;br /&gt;
&lt;br /&gt;
This benchmark tests throughput over 10 Gbit network connection which can be achieved in a virtualized environments, testing two traffic flow directions:&lt;br /&gt;
* from VM/CT to physical client&lt;br /&gt;
* from physical client to VM/CT&lt;br /&gt;
&lt;br /&gt;
=== Implementation ===&lt;br /&gt;
&lt;br /&gt;
To measure network throughput standard performance test '''netperf''' is used. Host with VM/CT and physical client are connected directly using cross cable (without switches, possible other traffic effects etc.)&lt;br /&gt;
&lt;br /&gt;
=== Testbed Configuration ===&lt;br /&gt;
Hardware:&lt;br /&gt;
* Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card&lt;br /&gt;
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM, Intel 82598EB 10-Gigabit network card&lt;br /&gt;
* Network: 10Gbit direct server &amp;lt;-&amp;gt; client optical connection&lt;br /&gt;
&lt;br /&gt;
Platform:&lt;br /&gt;
* Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RH6) 2.6.32-042test006.1.x86_64&lt;br /&gt;
* Guest OS: Centos 5.5 x86_64&lt;br /&gt;
&lt;br /&gt;
Software and Tunings: &lt;br /&gt;
* netperf v2.4.5&lt;br /&gt;
* '''one''' VM/CT with netperf configured with 4 vCPU, 4 GB RAM&lt;br /&gt;
* where it was possible, we set offloading &amp;amp; hardware checksumming (gro, gso,etc...) and jumbo frames (MTU=9000) features&lt;br /&gt;
* netperf run string:&lt;br /&gt;
** Server: netserver -p PORT (5 instances)&lt;br /&gt;
** Client: netperf -p PORT -HOST -t TCP_SENDFILE -l 300 (several instanes)&lt;br /&gt;
* Firewall was turned off&lt;br /&gt;
* All other tunings were left at default values&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Results ===&lt;br /&gt;
&lt;br /&gt;
[[File:10gbit_throughput_v2.png]]&lt;br /&gt;
&lt;br /&gt;
=== Summary ===&lt;br /&gt;
&lt;br /&gt;
* OpenVZ provides near native 10Gbit network throughput: 9.70Gbit on receive and 9.87Gbit on send&lt;br /&gt;
* OpenVZ is the only virtualization solution capable to achieve native 10Gbit throughput in both scenarios&lt;br /&gt;
* OpenVZ demonstrates &amp;gt;2x times greater performance on receive compared to hypervisors (x2 times faster than ESXi4.1 and x5 times faster than XenServer5.6)&lt;br /&gt;
&lt;br /&gt;
=== TODO ===&lt;br /&gt;
* record and provide CPU usage details to outline additional low CPU usage in this test case&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance/Response_Time&amp;diff=10159</id>
		<title>Performance/Response Time</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance/Response_Time&amp;diff=10159"/>
		<updated>2011-04-21T15:46:30Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Response Time&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Description ===&lt;br /&gt;
The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) react on external request under various conditions:&lt;br /&gt;
* Idle system and idle VM/CT&lt;br /&gt;
* Loaded system and idle VM/CT&lt;br /&gt;
* Loaded system and loaded VM/CT&lt;br /&gt;
&lt;br /&gt;
This workload simulates latency sensitive real life application which receives an event through the network and have to respond. Such workloads are very sensitive for CPU scheduling algorithms and work best when interactivity is taken into account.&lt;br /&gt;
Examples of such workloads: high performance computing environments (which introduce small synchronization messages), web and database servers and so on.&lt;br /&gt;
&lt;br /&gt;
=== Implementation ===&lt;br /&gt;
To measure response time a well known netperf TCP_RR test is used which measures how many round-trips a message can do between 2 hosts. To add a load in VM/CT simple CPU hog application (doing a busyloop and nothing else) is started. To emulate loaded system we run several loaded VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' of VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.&lt;br /&gt;
&lt;br /&gt;
=== Testbed Configuration ===&lt;br /&gt;
Hardware&lt;br /&gt;
* Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM&lt;br /&gt;
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM&lt;br /&gt;
* Network: 1Gbit direct server&amp;lt;&amp;gt;client connection&lt;br /&gt;
&lt;br /&gt;
Platform:&lt;br /&gt;
* Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RHEL6) 2.6.32-042test006.1.x86_64&lt;br /&gt;
* Guest OS: CentOS 5.5 x86_64&lt;br /&gt;
&lt;br /&gt;
Software and Tunings: &lt;br /&gt;
* netperf v2.4.5&lt;br /&gt;
* '''one''' VM/CT with netperf in server mode configured with 1 vCPU, 1 GB RAM&lt;br /&gt;
* '''six''' VMs/CTs (to load server CPU - see testcases) configured with 4 vCPU, 1GB RAM&lt;br /&gt;
* netperf command&lt;br /&gt;
** in VM/CT: &amp;lt;code&amp;gt;netserver -p 30300&amp;lt;/code&amp;gt;&lt;br /&gt;
** on the client: &amp;lt;code&amp;gt;netperf -p 30300 -H 172.0.1.1 -t TCP_RR -l 120 -- -r 128 -s 128&amp;lt;/code&amp;gt;&lt;br /&gt;
* Firewall was turned off&lt;br /&gt;
* All other tunables were left at default values.&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Results ===&lt;br /&gt;
&lt;br /&gt;
[[File:Response_time_v2.png]]&lt;br /&gt;
&lt;br /&gt;
=== Summary ===&lt;br /&gt;
&lt;br /&gt;
* '''In all the three cases (1 - idle system and idle VM/CT, 2 - loaded system and idle VM/CT, 3 - loaded system and loaded VM/CT) OpenVZ shows the lowest overhead over all the tested virtualization solutions and demonstrates latencies close to the native results of non-virtualized systems.'''&lt;br /&gt;
* '''VM virtualization solutions (like Xen, ESX) demonstrate latencies by an order of magnitude worse then native response times and introduce ~700-3000% overhead.'''&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance/Response_Time&amp;diff=10158</id>
		<title>Performance/Response Time</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance/Response_Time&amp;diff=10158"/>
		<updated>2011-04-21T15:43:47Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Response Time&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Description ===&lt;br /&gt;
The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) react on external request under various conditions:&lt;br /&gt;
* Idle system and idle VM/CT&lt;br /&gt;
* Loaded system and idle VM/CT&lt;br /&gt;
* Loaded system and loaded VM/CT&lt;br /&gt;
&lt;br /&gt;
This workload simulates latency sensitive real life application which receives an event through the network and have to respond. Such workloads are very sensitive for CPU scheduling algorithms and work best when interactivity is taken into account.&lt;br /&gt;
Examples of such workloads: high performance computing environments (which introduce small synchronization messages), web and database servers and so on.&lt;br /&gt;
&lt;br /&gt;
=== Implementation ===&lt;br /&gt;
To measure response time a well known netperf TCP_RR test is used which measures how many round-trips a message can do between 2 hosts. To add a load in VM/CT simple CPU hog application (doing a busyloop and nothing else) is started. To emulate loaded system we run several loaded VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' of VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.&lt;br /&gt;
&lt;br /&gt;
=== Testbed Configuration ===&lt;br /&gt;
Hardware&lt;br /&gt;
* Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM&lt;br /&gt;
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM&lt;br /&gt;
* Network: 1Gbit direct server&amp;lt;&amp;gt;client connection&lt;br /&gt;
&lt;br /&gt;
Platform:&lt;br /&gt;
* Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RHEL6) 2.6.32-042test006.1.x86_64&lt;br /&gt;
* Guest OS: CentOS 5.5 x86_64&lt;br /&gt;
&lt;br /&gt;
Software and Tunings: &lt;br /&gt;
* netperf v2.4.5&lt;br /&gt;
* '''one''' VM/CT with netperf in server mode configured with 1 vCPU, 1 GB RAM&lt;br /&gt;
* '''six''' VMs/CTs (to load server CPU - see testcases) configured with 4 vCPU, 1GB RAM&lt;br /&gt;
* netperf command&lt;br /&gt;
** in VM/CT: &amp;lt;code&amp;gt;netserver -p 30300&amp;lt;/code&amp;gt;&lt;br /&gt;
** on the client: &amp;lt;code&amp;gt;netperf -p 30300 -H 172.0.1.1 -t TCP_RR -l 120 -- -r 128 -s 128&amp;lt;/code&amp;gt;&lt;br /&gt;
* Firewall was turned off&lt;br /&gt;
* All other tunables were left at default values.&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Results ===&lt;br /&gt;
&lt;br /&gt;
[[File:Response_time_v2.png]]&lt;br /&gt;
&lt;br /&gt;
=== Summary ===&lt;br /&gt;
&lt;br /&gt;
* '''In all the three cases (1 - idle system and idle VM/CT, 2 - loaded system and idle VM/CT, 3 - loaded system and loaded VM/CT) OpenVZ shows the lowest overhead over all the tested virtualization solutions and demonstrates latencies close to the native results of non-virtualized systems.'''&lt;br /&gt;
* '''VM virtualization solutions like Xen demonstrates latencies by an order of magnitude worse then native response times.'''&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance/Response_Time&amp;diff=10157</id>
		<title>Performance/Response Time</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance/Response_Time&amp;diff=10157"/>
		<updated>2011-04-21T15:40:57Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Response Time&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Description ===&lt;br /&gt;
The aim of this benchmark is to measure how fast can application inside of virtual machine (VM) or operating system container (CT) react on external request under various conditions:&lt;br /&gt;
* Idle system and idle VM/CT&lt;br /&gt;
* Loaded system and idle VM/CT&lt;br /&gt;
* Loaded system and loaded VM/CT&lt;br /&gt;
&lt;br /&gt;
This workload simulates latency sensitive real life application which receives an event through the network and have to respond. Such workloads are very sensitive for CPU scheduling algorithms and work best when interactivity is taken into account.&lt;br /&gt;
Examples of such workloads: high performance computing environments (which introduce small synchronization messages), web and database servers and so on.&lt;br /&gt;
&lt;br /&gt;
=== Implementation ===&lt;br /&gt;
To measure response time a well known netperf TCP_RR test is used which measures how many round-trips a message can do between 2 hosts. To add a load in VM/CT simple CPU hog application (doing a busyloop and nothing else) is started. To emulate loaded system we run several loaded VM/CT (to eat all the host CPU time). Netperf runs in server mode inside of '''one''' of VM/CT. On the separate physical host we run netperf TCP_RR test against selected VM/CT over the 1Gbit network.&lt;br /&gt;
&lt;br /&gt;
=== Testbed Configuration ===&lt;br /&gt;
Hardware&lt;br /&gt;
* Server: 4xHexCore Intel Xeon (2.66 GHz), 32 GB RAM&lt;br /&gt;
* Client: 4xHexCore Intel Xeon (2.136 GHz), 32 GB RAM&lt;br /&gt;
* Network: 1Gbit direct server&amp;lt;&amp;gt;client connection&lt;br /&gt;
&lt;br /&gt;
Platform:&lt;br /&gt;
* Virtualization Software: ESXi4.1upd1, XenServer5.6fp1, HyperV (R2), OpenVZ (RHEL6) 2.6.32-042test006.1.x86_64&lt;br /&gt;
* Guest OS: CentOS 5.5 x86_64&lt;br /&gt;
&lt;br /&gt;
Software and Tunings: &lt;br /&gt;
* netperf v2.4.5&lt;br /&gt;
* '''one''' VM/CT with netperf in server mode configured with 1 vCPU, 1 GB RAM&lt;br /&gt;
* '''six''' VMs/CTs (to load server CPU - see testcases) configured with 4 vCPU, 1GB RAM&lt;br /&gt;
* netperf command&lt;br /&gt;
** in VM/CT: &amp;lt;code&amp;gt;netserver -p 30300&amp;lt;/code&amp;gt;&lt;br /&gt;
** on the client: &amp;lt;code&amp;gt;netperf -p 30300 -H 172.0.1.1 -t TCP_RR -l 120 -- -r 128 -s 128&amp;lt;/code&amp;gt;&lt;br /&gt;
* Firewall was turned off&lt;br /&gt;
* All other tunables were left at default values.&lt;br /&gt;
&lt;br /&gt;
=== Benchmark Results ===&lt;br /&gt;
&lt;br /&gt;
[[File:Response_time_v2.png]]&lt;br /&gt;
&lt;br /&gt;
=== Summary ===&lt;br /&gt;
&lt;br /&gt;
'''In all the three cases (1 - idle system and idle VM/CT, 2 - loaded system and idle VM/CT, 3 - loaded system and loaded VM/CT) OpenVZ shows the lowest overhead over all the tested virtualization solutions'''.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_vs_VMs&amp;diff=10116</id>
		<title>WP/Containers vs VMs</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_vs_VMs&amp;diff=10116"/>
		<updated>2011-04-11T14:50:59Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Containers versus Virtual Machines =&lt;br /&gt;
&lt;br /&gt;
This article gives an overview of containers for those who know what a Virtual Machine (VM) is. VMs are implemented by products such as VMware, , Parallels, Xen, Hyper-V, Virtual Box etc. If you do not have experience with those or similar products, better read [[../What are containers/]] whitepaper.&lt;br /&gt;
&lt;br /&gt;
Containers are very similar to VMs in a sense that they also let one to partition one physical computer into multiple small isolated partitions (called VMs or containers).&lt;br /&gt;
The difference is in technique used for such partitioning.&lt;br /&gt;
&lt;br /&gt;
Some of the major differences between VMs and containers, as well as their consequences, are outlined below.&lt;br /&gt;
&lt;br /&gt;
== Single kernel concept ==&lt;br /&gt;
&lt;br /&gt;
Xen, KVM, VMware and other hypervisor-based products provide an ability to have multiple instances of virtual hardware (called VMs – Virtual Machines) on a single piece of real hardware. On top of that virtual hardware one can run any Operating System, so it's possible to run multiple different OSs on one single server. Each VM runs full software stack (including an OS kernel).&lt;br /&gt;
&lt;br /&gt;
In contrast, OpenVZ and containers technology uses a single-kernel approach. There is only one single OS kernel running, and on top of that there are multiple isolated instances of user-space programs. This approach is more lightweight than VM. The consequences are:&lt;br /&gt;
&lt;br /&gt;
# Waiving the need to run multiple OS kernels results in '''higher density''' of containers (compared to VMs)&lt;br /&gt;
# Software stack that lies in between an application and the hardware is much thinner, this means '''higher performance''' of containers (compared to VMs)&lt;br /&gt;
&lt;br /&gt;
== File system ==&lt;br /&gt;
[[Image:chroot.png|300px|right]]&lt;br /&gt;
From file system point of view, a container is just a &amp;lt;code&amp;gt;chroot()&amp;lt;/code&amp;gt; environment. In other words, a container file system root is merely a directory on the host system (usually /vz/root/$CTID/, under which one can find usual directories like &amp;lt;code&amp;gt;/etc&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;/lib&amp;lt;/code&amp;gt;, &amp;lt;code&amp;gt;/bin&amp;lt;/code&amp;gt; etc.). The consequences are:&lt;br /&gt;
&lt;br /&gt;
* there is no need for a separate block device, hard drive partition or filesystem-in-a-file setup&lt;br /&gt;
* host system administrator can see all the containers' files&lt;br /&gt;
* containers backup/restore is trivial&lt;br /&gt;
* there is no I/O overhead (for VMs it can be as high as 1.5x to 3x, especially for small requests)&lt;br /&gt;
* mass deployment is easy&lt;br /&gt;
&lt;br /&gt;
== Networking ==&lt;br /&gt;
&lt;br /&gt;
== Memory management ==&lt;br /&gt;
&lt;br /&gt;
== Density ==&lt;br /&gt;
&lt;br /&gt;
There is a separate article which explains differences in technologies and why containers are better in high density environments [[WP/Containers density]].&lt;br /&gt;
&lt;br /&gt;
== Performance ==&lt;br /&gt;
&lt;br /&gt;
FIXME: link to performance paper&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=10115</id>
		<title>WP/Containers density</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=10115"/>
		<updated>2011-04-11T14:26:42Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
= Containers density. Why containers are so good at it? =&lt;br /&gt;
&lt;br /&gt;
== What is density? ==&lt;br /&gt;
&lt;br /&gt;
Density is a characteristic which tells how many containers (CTs) or Virtual Machines (VMs) virtualization technology can run successfully on a given hardware which very much depends on:&lt;br /&gt;
* virtualization technology used (containers or hypervisor);&lt;br /&gt;
* features provided by the technology (page sharing, ballooning, memory overcommitment support etc.);&lt;br /&gt;
* workload itself. Virtualization is not a miracle and can't handle more high loaded workloads then bare host can. e.g. do not expect any density except for 1VM/CT if you are running Oracle with huge request rates. On the other hand, if you are having multiple small web sites virtualization can easily consolidate them on a single host as long as host is capable to handle IO requests altogether and memory/CPU demands.&lt;br /&gt;
&lt;br /&gt;
Speaking about hypervisors, some of them (like Xen) reserve the whole guest VM memory on its startup and do not allow memory overcommitment. This leads to inability to start more then, say, 15 VMs with 1Gb RAM assigned to each on a 16Gb RAM host. Theoretically this helps to deliver maximum performance as Xen can always use large pages and avoid swapping out or other overheads. However, as other hypervisors (like ESX) demonstrate it's possible to achieve both goals - high performance and density depending on the situation, though it obviously requires more complicated technology which is not yet fully available in any of open-source hypervisors.&lt;br /&gt;
&lt;br /&gt;
Typically users also care for quality of service of their software, i.e. how well their services are working on utilized node and how fast they respond to external requests. The metrics of quality of service are average/min/max response time, 99.9% requests response time and similar. When a hardware node is capable to handle the load, these metrics either do not grow much with bigger number of containers, or grow linearly. When a hardware node becomes over utilized, these metrics typically start to degrade exponentially (due to memory swap out).&lt;br /&gt;
&lt;br /&gt;
Below we summarize differences between containers (OpenVZ, Parallels Containers, Solaris Zones) and hypervisor (ESX, Xen, KVM, HyperV) which affect density and make containers to be more suitable for high density environments then virtual machines.&lt;br /&gt;
&lt;br /&gt;
== What makes containers to be perfectly suitable for high density? ==&lt;br /&gt;
&lt;br /&gt;
* Containers do not reserve memory assigned to them. They exhibit real-time elastic behavior: if a container do not use memory, then it is free for use by other containers. In other words, overcommitment is as natural and easy as on a standalone Linux box, when multiple applications compete for memory resources. As a result, a simple container running ssh, apache, init and cron takes only 10-20Mb of physical RAM. Sure, for efficient caching of apache pages more RAM is needed, but it depends purely on active working set of web site and most frequently accessed files. If site is not accessed frequently kernel may decide to free memory at all (or swap out) and still will be able to get pages back in seconds.&lt;br /&gt;
&lt;br /&gt;
* Containers memory management is system-wide wise. If one container needs more physical RAM (e.g. for apache pages caching) and hardware node have no more memory available, kernel will automatically reclaim last recently used caches of other containers. This process is dynamic by it's nature and do not have any latency like ballooning in case of VMs.&lt;br /&gt;
&lt;br /&gt;
* Global memory management allows one containers to cache more data then RAM assigned to it. In case other containers will need physical memory this cache will be quickly reclaimed automatically. Thus caching can be much more efficient and dynamically adjusts itself to the needs.&lt;br /&gt;
&lt;br /&gt;
* Containers CPU scheduler is interactive system-wide. If some process is woken up by an external event (like networking request) CPU scheduler can quickly preempt current CPU hog task and schedule interactive one. This is not true with VMs where hypervisor doesn't know the nature of tasks inside the VM and whether VM should preempt another VM on even or not. In high-density environments it is particularly important to make sure that interactive tasks get CPU fast enough and provide low latency response to users.&lt;br /&gt;
&lt;br /&gt;
* Parallels Virtuozzo Containers product goes a step further by introducing container templates, used as a basis for all containers, and a special copy-on-write filesystem, which makes sure that original template is kept untouched and container gets its own private copy of template file when it tries to modify it. As a result all common files are shared across the containers and present on disk and in memory caches in a single instance. This saves memory, reduces I/O and makes L2/L3 caches work more effective.&lt;br /&gt;
&lt;br /&gt;
== Why Virtual Machines are not that good? ==&lt;br /&gt;
&lt;br /&gt;
Hypervisors (Xen, ESX, KVM) are not that good on high density scenarios. There are multiple reasons for that:&lt;br /&gt;
&lt;br /&gt;
* (Most) memory is basically reserved on the host on VM start. KVM and XEN reserve the whole memory by default and do not allow memory overcommitment. As a result you can't run more then 15 VMs with 1GB RAM on 16Gb box. ESX, being the most advanced hypervisor, uses page sharing and ballooning technologies to introduce memory overcommitment. However, on practice it allows to get only about 2x times overcommitment on the guests of the same type. Our experiments demonstrate that half of the improvement is due to page sharing, and half is due to ballooning.&lt;br /&gt;
&lt;br /&gt;
* Ballooning helps to reclaim fairly easily part of guest VM memory, however it have some issues. First, it have some noticeable latency since it takes time from deciding to reclaim memory till the moment when guest will do that for hypervisor (and BTW it can simply have problems and do not do that at all). Next, it may lead to swap out inside the guest which negatively affects the whole system I/O performance (IOPS is a scarce resource on practice). And what is worse it may lead to behavior different from standalone machine - e.g. OS may deny memory allocations though guest didn't used assigned resources or trigger Out-Of-Memory (OOM) killer on Linux.&lt;br /&gt;
&lt;br /&gt;
* Typical hypervisor overhead is 50-100Mb for 1Gb 1VCPU guest, i.e. almost 10% of RAM. Detailed overhead table from VMware ESX 4.0 product [p.30 http://www.vmware.com/pdf/vsphere4/r40/vsp_40_resource_mgmt.pdf] also demonstrates how overhead significantly increases with a number of VCPUs assigned to guest.&lt;br /&gt;
&lt;br /&gt;
* VMs are running multiple kernels and their system data structures in memory. RAM pages sharing helps this problem, but on VM startup when memory scanner have not yet merged multiple copies this can be a problem and lead to memory usage bursts.&lt;br /&gt;
&lt;br /&gt;
* Hypervisor CPU scheduler doesn't know details about tasks running inside and their interactivity. See above explanation on containers.&lt;br /&gt;
&lt;br /&gt;
== Numbers ==&lt;br /&gt;
XXX&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=10114</id>
		<title>WP/Containers density</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=10114"/>
		<updated>2011-04-11T14:12:01Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
= Containers density. Why containers are so good at it? =&lt;br /&gt;
&lt;br /&gt;
== What is density? ==&lt;br /&gt;
&lt;br /&gt;
Density is a characteristic which tells how many containers (CTs) or Virtual Machines (VMs) virtualization technology can run successfully on a given hardware which very much depends on:&lt;br /&gt;
* virtualization technology used (containers or hypervisor);&lt;br /&gt;
* features provided by the technology (page sharing, ballooning, memory overcommitment support etc.);&lt;br /&gt;
* workload itself. Virtualization is not a miracle and can't handle more high loaded workloads then bare host can. e.g. do not expect any density except for 1VM/CT if you are running Oracle with huge request rates. On the other hand, if you are having multiple small web sites virtualization can easily consolidate them on a single host as long as host is capable to handle IO requests altogether and memory/CPU demands.&lt;br /&gt;
&lt;br /&gt;
Speaking about hypervisors, some of them (like Xen) reserve the whole guest VM memory on its startup and do not allow memory overcommitment. This leads to inability to start more then, say, 15 VMs with 1Gb RAM assigned to each on a 16Gb RAM host. Theoretically this helps to deliver maximum performance as Xen can always use large pages and avoid swapping out or other overheads. However, as other hypervisors (like ESX) demonstrate it's possible to achieve both goals - high performance and density depending on the situation, though it obviously requires more complicated technology which is not yet fully available in any of open-source hypervisors.&lt;br /&gt;
&lt;br /&gt;
Typically users also care for quality of service of their software, i.e. how well their services are working on utilized node and how fast they respond to external requests. The metrics of quality of service are average/min/max response time, 99.9% requests response time and similar. When a hardware node is capable to handle the load, these metrics either do not grow much with bigger number of containers, or grow linearly. When a hardware node becomes over utilized, these metrics typically start to degrade exponentially (due to memory swap out).&lt;br /&gt;
&lt;br /&gt;
Below we summarize differences between containers (OpenVZ, Parallels Containers, Solaris Zones) and hypervisor (ESX, Xen, KVM, HyperV) which affect density and make containers to be more suitable for high density environments then virtual machines.&lt;br /&gt;
&lt;br /&gt;
== What makes containers to be perfectly suitable for high density? ==&lt;br /&gt;
&lt;br /&gt;
* Containers do not reserve memory assigned to them. They exhibit real-time elastic behavior: if a container do not use memory, then it is free for use by other containers. In other words, overcommitment is as natural and easy as on a standalone Linux box, when multiple applications compete for memory resources. As a result, a simple container running ssh, apache, init and cron takes only 10-20Mb of physical RAM. Sure, for efficient caching of apache pages more RAM is needed, but it depends purely on active working set of web site and most frequently accessed files. If site is not accessed frequently kernel may decide to free memory at all (or swap out) and still will be able to get pages back in seconds.&lt;br /&gt;
&lt;br /&gt;
* Containers memory management is system-wide wise. If one container needs more physical RAM (e.g. for apache pages caching) and hardware node have no more memory available, kernel will automatically reclaim last recently used caches of other containers. This process is dynamic by it's nature and do not have any latency like ballooning in case of VMs.&lt;br /&gt;
&lt;br /&gt;
* Global memory management allows one containers to cache more data then RAM assigned to it. In case other containers will need physical memory this cache will be quickly reclaimed automatically. Thus caching can be much more efficient and dynamically adjusts itself to the needs.&lt;br /&gt;
&lt;br /&gt;
* Containers CPU scheduler is interactive system-wide. If some process is woken up by an external event (like networking request) CPU scheduler can quickly preempt current CPU hog task and schedule interactive one. This is not true with VMs where hypervisor doesn't know the nature of tasks inside the VM and whether VM should preempt another VM on even or not. In high-density environments it is particularly important to make sure that interactive tasks get CPU fast enough and provide low latency response to users.&lt;br /&gt;
&lt;br /&gt;
* Parallels Virtuozzo Containers product goes a step further by introducing container templates, used as a basis for all containers, and a special copy-on-write filesystem, which makes sure that original template is kept untouched and container gets its own private copy of template file when it tries to modify it. As a result all common files are shared across the containers and present on disk and in memory caches in a single instance. This saves memory, reduces I/O and makes L2/L3 caches work more effective.&lt;br /&gt;
&lt;br /&gt;
== Why Virtual Machines are not that good? ==&lt;br /&gt;
&lt;br /&gt;
Hypervisors (Xen, ESX, KVM) are not that good on high density scenarios. There are multiple reasons for that:&lt;br /&gt;
&lt;br /&gt;
* (Most) memory is basically reserved on the host on VM start. KVM and XEN reserve the whole memory by default and do not allow memory overcommitment. As a result you can't run more then 15 VMs with 1GB RAM on 16Gb box. ESX, being the most advanced hypervisor, uses page sharing and ballooning technologies to introduce memory overcommitment. However, on practice it allows to get only about 2x times overcommitment on the guests of the same type. Our experiments demonstrate that half of the improvement is due to page sharing, and half is due to ballooning.&lt;br /&gt;
&lt;br /&gt;
* Ballooning helps to reclaim fairly easily part of guest VM memory, however it have some issues. First, it have some noticeable latency since it takes time from deciding to reclaim memory till the moment when guest will do that for hypervisor (and BTW it can simply have problems and do not do that at all). Next, it may lead to swap out inside the guest which negatively affects the whole system I/O performance (IOPS is a scarce resource on practice). And what is worse it may lead to behavior different from standalone machine - e.g. OS may deny memory allocations though guest didn't used assigned resources or trigger Out-Of-Memory (OOM) killer on Linux.&lt;br /&gt;
&lt;br /&gt;
* Typical hypervisor overhead is 50-100Mb for 1Gb 1VCPU guest, i.e. almost 10% of RAM. Detailed overhead table from VMware ESX 4.0 product [p.30 http://www.vmware.com/pdf/vsphere4/r40/vsp_40_resource_mgmt.pdf] also demonstrates how overhead significantly increases with a number of VCPUs assigned to guest.&lt;br /&gt;
&lt;br /&gt;
* VMs are running multiple kernels and their system data structures in memory. RAM pages sharing helps this problem, but on VM startup when memory scanner have not yet merged multiple copies this can be a problem and lead to memory usage bursts.&lt;br /&gt;
&lt;br /&gt;
* Hypervisor CPU scheduler doesn't know details about tasks running inside and their interactivity. See above explanation on containers.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=10113</id>
		<title>WP/Containers density</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=10113"/>
		<updated>2011-04-11T13:24:56Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
= Containers density. Why containers are so good at it? =&lt;br /&gt;
&lt;br /&gt;
== What is density? ==&lt;br /&gt;
&lt;br /&gt;
Density is a characteristic which tells how many containers (CTs) or Virtual Machines (VMs) virtualization technology can run successfully on a given hardware. Density very much depends on:&lt;br /&gt;
* virtualization technology used (containers or hypervisor);&lt;br /&gt;
* features provided by the technology (page sharing, ballooning, memory overcommitment support etc.);&lt;br /&gt;
* workload itself. Virtualization is not a miracle and can't handle more high loaded workloads then bare host can. e.g. do not expect&lt;br /&gt;
any density except for 1VM/CT if you are running Oracle with huge request rates. On the other hand, if you are having multiple small web sites virtualization can easily consolidate them on a single host as long as host is capable to handle IO requests altogether and memory/CPU demands.&lt;br /&gt;
&lt;br /&gt;
Typically users also care for quality of service of their software, i.e. how well their services are working on utilized node and how fast they respond to external requests. The metrics of quality of service are average/min/max response time, 99.9% requests response time and similar. When a hardware node is capable to handle the load, these metrics either do not grow much with bigger number of containers, or grow linearly. When a hardware node becomes over utilized, these metrics typically start to degrade exponentially (due to memory swap out). &lt;br /&gt;
&lt;br /&gt;
== What makes containers to be perfectly suitable for high density? ==&lt;br /&gt;
* Containers do not reserve memory assigned to them. They exhibit real-time elastic behavior: if a container do not use memory, then it is free for use by other containers. In other words, overcommitment is as natural and easy as on a standalone Linux box, when multiple applications compete for memory resources. As a result, a simple container running ssh, apache, init and cron takes only 10-20Mb of physical RAM. Sure, for efficient caching of apache pages more RAM is needed.&lt;br /&gt;
&lt;br /&gt;
* Containers memory management is system-wide wise. If one container needs more physical RAM (e.g. for apache pages caching) and hardware node have no more memory available, kernel will automatically reclaim last recently used caches of other containers.&lt;br /&gt;
&lt;br /&gt;
* Parallels Virtuozzo Containers product goes a step further by introducing container templates, used as a basis for all containers, and a special copy-on-write filesystem, which makes sure that original template is kept untouched and container gets its own private copy of template file when it tries to modify it. As a result all common files are shared across the containers and present on disk and in memory caches in a single instance. This saves memory, reduces I/O and makes L2/L3 caches work more effective.&lt;br /&gt;
&lt;br /&gt;
== Why Virtual Machines are not that good? ==&lt;br /&gt;
&lt;br /&gt;
Hypervisors (Xen, ESX, KVM) are not that good on high density scenarios. There are multiple reasons for that:&lt;br /&gt;
&lt;br /&gt;
* Memory is basically reserved on the host on VM start. KVM and XEN reserve the whole memory by default and do not allow memory overcommitment. As a result you can't run more then 15 VMs with 1GB RAM on 16Gb box. ESX, being the most advanced hypervisor, uses page sharing and ballooning technologies to introduce memory overcommitment. However, on practice it allows to get only about 2x times overcommitment on the guests of the same type. Our experiments tell that half of the improvement is due to page sharing, and half is due to ballooning.&lt;br /&gt;
* Multiple kernels and their system data structures in memory. RAM pages sharing and ballooning help a bit here, too.&lt;br /&gt;
* what happens when CT is above it's limit&lt;br /&gt;
* what happens when node RAM is exhausted&lt;br /&gt;
* plots and examples. Kir had http_load plot in the past. We will have LAMP results as well.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=10087</id>
		<title>WP/Containers density</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=10087"/>
		<updated>2011-04-03T12:33:04Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
= Containers density. Why containers are so good at it? =&lt;br /&gt;
&lt;br /&gt;
== What is density? ==&lt;br /&gt;
Density is a characteristic which tells how many containers (CTs) or Virtual Machines (VMs) virtualization technology can run successfully on a given hardware. Typically users also care for quality of service of their software, i.e. how well their services are working on utilized node and how fast they respond to external requests. Typical metrics of quality of service are average response time, 99.9% requests response time, and max response time. When a hardware node is capable to handle the load, these metrics either do not grow much with bigger number of containers, or grow linearly. When a hardware node becomes over utilized, these metrics typically start to degrade exponentially (due to memory swap out). &lt;br /&gt;
&lt;br /&gt;
== What makes containers to be perfectly suitable for high density? ==&lt;br /&gt;
* Containers do not reserve memory assigned to them. They exhibit real-time elastic behavior: if a container do not use memory, then it is free for use by other containers. In other words, overcommitment is as natural and easy as on a standalone Linux box, when multiple applications compete for memory resources. As a result, a simple container running ssh, apache, init and cron takes only 10-20Mb of physical RAM. Sure, for efficient caching of apache pages more RAM is needed.&lt;br /&gt;
&lt;br /&gt;
* Containers memory management is system-wide wise. If one container needs more physical RAM (e.g. for apache pages caching) and hardware node have no more memory available, kernel will automatically reclaim last recently used caches of other containers.&lt;br /&gt;
&lt;br /&gt;
* Parallels Virtuozzo Containers product goes a step further by introducing container templates, used as a basis for all containers, and a special copy-on-write filesystem, which makes sure that original template is kept untouched and container gets its own private copy of template file when it tries to modify it. As a result all common files are shared across the containers and present on disk and in memory caches in a single instance. This saves memory, reduces I/O and makes L2/L3 caches work more effective.&lt;br /&gt;
&lt;br /&gt;
== Why Virtual Machines are not that good? ==&lt;br /&gt;
&lt;br /&gt;
Hypervisors (Xen, ESX, KVM) are not that good on high density scenarios. There are multiple reasons for that:&lt;br /&gt;
&lt;br /&gt;
* Memory is basically reserved on the host on VM start. KVM and XEN reserve the whole memory by default and do not allow memory overcommitment. As a result you can't run more then 15 VMs with 1GB RAM on 16Gb box. ESX, being the most advanced hypervisor, uses page sharing and ballooning technologies to introduce memory overcommitment. However, on practice it allows to get only about 2x times overcommitment on the guests of the same type. Our experiments tell that half of the improvement is due to page sharing, and half is due to ballooning.&lt;br /&gt;
* Multiple kernels and their system data structures in memory. RAM pages sharing and ballooning help a bit here, too.&lt;br /&gt;
* what happens when CT is above it's limit&lt;br /&gt;
* what happens when node RAM is exhausted&lt;br /&gt;
* plots and examples. Kir had http_load plot in the past. We will have LAMP results as well.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=9917</id>
		<title>WP/Containers density</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=9917"/>
		<updated>2011-03-14T18:36:00Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Containers density. Why containers are so good at it? =&lt;br /&gt;
&lt;br /&gt;
== What is density? ==&lt;br /&gt;
Density is a characteristics which tells one how many containers (CTs) or Virtual Machines (VMs) virtualization technology can run successfully on the given hardware. Typically users also care for quality of service of their software, i.e. how well their services are working on utilized node and how fast they respond to external requests. Average response time, 99.9% requests response time and max response time are typical metrics of quality of service. When hardware node is capable to bear the load these metrics either do not grow much with bigger number of containers or grow linearly. When hardware node becomes over utilized these metrics typically start to degrade exponentially (e.g. due to memory swap out). &lt;br /&gt;
&lt;br /&gt;
== What makes containers to be perfectly suitable for high density? ==&lt;br /&gt;
# Containers do not reserve memory assigned to it. They exhibit real-time elastic behavior, if applications do not use memory, then it is free for other containers usage. i.e. overcommit is natural and easy like on standalone Linux box when multiple applications compete for memory resources.&lt;br /&gt;
As a result simple container running ssh, apache, init and cron takes only 10-20Mb of physical RAM. Sure, for efficient caching of apache pages more RAM is needed.&lt;br /&gt;
&lt;br /&gt;
# Containers memory management is system-wide wise. If one container needs more physical RAM (e.g. for apache pages caching) and hardware node have no more memory available, kernel will automatically reclaim last recently used caches of other containers.&lt;br /&gt;
&lt;br /&gt;
# Parallels Virtuozzo containers product does a step further and introduces containers templates, which are used as a basis for all containers and special Copy-on-Write filesystem makes sure that original template is kept untouched and container gets its own private copy of template file when it tries to modify it. As a result all common files are shared across the containers and present on disk and in memory caches in a single instance. This saves memory, reduces I/O and makes L2/L3 caches work more effective.&lt;br /&gt;
&lt;br /&gt;
== Why Virtual Machines are not that good? ==&lt;br /&gt;
&lt;br /&gt;
Hypervisors (Xen, ESX, KVM) are not that good on high density scenarios. There are multiple reasons for that:&lt;br /&gt;
# Memory is basically reserved on the host on VM start. e.g. KVM and XEN by default reserve whole memory and do not allow memory overcommitment. As a result you can't run more then 15 VMs with 1GB RAM on 16Gb box. ESX as the most advanced hypervisor uses page sharing and ballooning technologies to introduce memory overcommitment. However, on practice it allows to get only about 2x times overcommitment on the guests of the same type. From our experiments half of this improvement is due to page sharing and half due to ballooning.&lt;br /&gt;
&lt;br /&gt;
# Multiple kernels and their system data structures in memory.&lt;br /&gt;
There are some technologies like RAM pages sharing and ballooning which help a bit.&lt;br /&gt;
&lt;br /&gt;
# what happens when CT is above it's limit&lt;br /&gt;
# what happens when node RAM is exhausted&lt;br /&gt;
# plots and examples. Kir had http_load plot in the past. We will have LAMP results as well.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=9916</id>
		<title>WP/Containers density</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=9916"/>
		<updated>2011-03-14T17:56:54Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Containers density. Why containers are so good at it? =&lt;br /&gt;
&lt;br /&gt;
== What is density? ==&lt;br /&gt;
Density is a characteristics which tells one how many containers (CTs) or Virtual Machines (VMs) virtualization technology can run successfully on the given hardware. Typically users also care for quality of service of their software, i.e. how well their services are working on utilized node and how fast they respond to external requests. Average response time, 99.9% requests response time and max response time are typical metrics of quality of service. When hardware node is capable to bear the load these metrics either do not grow much with bigger number of containers or grow linearly. When hardware node becomes over utilized these metrics typically start to degrade exponentially (e.g. due to memory swap out). &lt;br /&gt;
&lt;br /&gt;
== What makes containers to be perfectly suitable for high density? ==&lt;br /&gt;
# Containers do not reserve memory assigned to it. They exhibit elastic behavior, if applications do not use &lt;br /&gt;
&lt;br /&gt;
# explain that even best hypervisors (ESX) achieve only 2x memory overcommit. Actually 50% of it are due to page sharing, and 50% due to balloon.&lt;br /&gt;
&lt;br /&gt;
# Virtuozzo templates and file sharing add even more savings&lt;br /&gt;
# what happens when CT is above it's limit&lt;br /&gt;
# what happens when node RAM is exhausted&lt;br /&gt;
# plots and examples. Kir had http_load plot in the past. We will have LAMP results as well.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=9915</id>
		<title>WP/Containers density</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=9915"/>
		<updated>2011-03-14T17:56:25Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Containers density =&lt;br /&gt;
&lt;br /&gt;
== What is density? ==&lt;br /&gt;
Density is a characteristics which tells one how many containers (CTs) or Virtual Machines (VMs) virtualization technology can run successfully on the given hardware. Typically users also care for quality of service of their software, i.e. how well their services are working on utilized node and how fast they respond to external requests. Average response time, 99.9% requests response time and max response time are typical metrics of quality of service. When hardware node is capable to bear the load these metrics either do not grow much with bigger number of containers or grow linearly. When hardware node becomes over utilized these metrics typically start to degrade exponentially (e.g. due to memory swap out). &lt;br /&gt;
&lt;br /&gt;
== What makes containers to be perfectly suitable for high density? ==&lt;br /&gt;
# Containers do not reserve memory assigned to it. They exhibit elastic behavior, if applications do not use &lt;br /&gt;
&lt;br /&gt;
# explain that even best hypervisors (ESX) achieve only 2x memory overcommit. Actually 50% of it are due to page sharing, and 50% due to balloon.&lt;br /&gt;
&lt;br /&gt;
# Virtuozzo templates and file sharing add even more savings&lt;br /&gt;
# what happens when CT is above it's limit&lt;br /&gt;
# what happens when node RAM is exhausted&lt;br /&gt;
# plots and examples. Kir had http_load plot in the past. We will have LAMP results as well.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=9914</id>
		<title>WP/Containers density</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=WP/Containers_density&amp;diff=9914"/>
		<updated>2011-03-14T17:11:57Z</updated>

		<summary type="html">&lt;p&gt;Dev: Created page with '= Containers density = Why OpenVZ containers density is so much better that that of Virtual Machines (Xen, VMware, KVM). - automatic elastic behaviour and no memory reservation -…'&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Containers density =&lt;br /&gt;
Why OpenVZ containers density is so much better that that of Virtual Machines (Xen, VMware, KVM).&lt;br /&gt;
- automatic elastic behaviour and no memory reservation -- real advantage&lt;br /&gt;
- explain that even best hypervisors (ESX) achieve only 2x memory overcommit. Actually 50% of it are due to page sharing, and 50% due to balloon.&lt;br /&gt;
- Virtuozzo templates and file sharing add even more savings&lt;br /&gt;
- what happens when CT is above it's limit&lt;br /&gt;
- what happens when node RAM is exhausted&lt;br /&gt;
- plots and examples. Kir had http_load plot in the past. We will have LAMP results as well.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Control_panels&amp;diff=3937</id>
		<title>Control panels</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Control_panels&amp;diff=3937"/>
		<updated>2008-01-13T12:43:42Z</updated>

		<summary type="html">&lt;p&gt;Dev: added vtonf&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page contains links to different control panels for OpenVZ, written by third parties. If you know the project that's missing here, please add it.&lt;br /&gt;
&lt;br /&gt;
== Free software ==&lt;br /&gt;
* Webmin: [http://www.webmin.com/index8.html homepage] | [http://webadminmodules.sourceforge.net/?page=Search&amp;amp;action=search OpenVZ plugin] (search for OpenVZ) [outdated / nonworking?]&lt;br /&gt;
* Mwamko: [http://mwamko.devjavu.com/ homepage]&lt;br /&gt;
* Vtonf: [http://www.vtonf.com/ homepage]&lt;br /&gt;
&lt;br /&gt;
== Non-free ==&lt;br /&gt;
* VZ-Manager: [http://vzmanager.de/ homepage (German)]&lt;br /&gt;
* HyperVM: [http://lxlabs.com/software/hypervm/ homepage]&lt;br /&gt;
* vzAdmin: [http://www.vzAdmin.info/ homepage (German)]&lt;br /&gt;
&lt;br /&gt;
== Unknown license ==&lt;br /&gt;
* OpenVZ Control panel for Windows(r): {{forum|1491}} | [http://downloads.qmailrocks.ru/vz/ downloads] ''unknown license''&lt;br /&gt;
&lt;br /&gt;
== Frozen projects ==&lt;br /&gt;
* VZAdmin: [http://www.ronny-goerner.de/ homepage] ''seems not available now''&lt;br /&gt;
* WVZ: [http://homaly.dunanet.hu/wvz/ homepage] ''seems frozen''&lt;br /&gt;
* New OpenVZ Web Based Control Panel by rsailor: {{forum|230}} ''seems not available now''&lt;br /&gt;
* EasyVZ: [http://easyvz.sourceforge.net/ screenshots] | [http://sourceforge.net/projects/easyvz sf.net project page] (little bit outdated, but only working and free control panel?) (requires Unix/Linux)&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Locales_inside_VE&amp;diff=3734</id>
		<title>Locales inside VE</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Locales_inside_VE&amp;diff=3734"/>
		<updated>2007-12-10T17:40:35Z</updated>

		<summary type="html">&lt;p&gt;Dev: New page: == Problem description ==  After creating a VE (e.g. using centos-4-i386-default template) running perl (any perl script), results in the warning message:   perl: warning: Setting locale f...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Problem description ==&lt;br /&gt;
&lt;br /&gt;
After creating a VE (e.g. using centos-4-i386-default template)&lt;br /&gt;
running perl (any perl script), results in the warning message:&lt;br /&gt;
&lt;br /&gt;
 perl: warning: Setting locale failed.&lt;br /&gt;
 perl: warning: Please check that your locale settings:&lt;br /&gt;
         LANGUAGE = &amp;quot;en_US:en&amp;quot;,&lt;br /&gt;
         LC_ALL = (unset),&lt;br /&gt;
         LANG = &amp;quot;en_US&amp;quot;&lt;br /&gt;
     are supported and installed on your system.&lt;br /&gt;
 perl: warning: Falling back to the standard locale (&amp;quot;C&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
== Resolution ==&lt;br /&gt;
&lt;br /&gt;
Some of templates have removed locales inside, since locales take really much space (~20Mb)&lt;br /&gt;
while not needed in most cases (except for the default &amp;quot;C&amp;quot; locale).&lt;br /&gt;
&lt;br /&gt;
So in this example '''/usr/lib/locale/en_US/LC_TIME''' and other files are missing.&lt;br /&gt;
&lt;br /&gt;
== Fix 1 ==&lt;br /&gt;
&lt;br /&gt;
reinstall glibc-common package using the command:&lt;br /&gt;
 # rpm -ihv --force glibc-common.rpm&lt;br /&gt;
&lt;br /&gt;
== Fix 2 ==&lt;br /&gt;
&lt;br /&gt;
Or '''disable''' overriding of LC_* variables in '''/etc/ssh/sshd_config''':&lt;br /&gt;
&lt;br /&gt;
 # Allow client to pass locale environment variables&lt;br /&gt;
 AcceptEnv LANG LC_*&lt;br /&gt;
&lt;br /&gt;
to&lt;br /&gt;
&lt;br /&gt;
 #AcceptEnv LANG LC_*&lt;br /&gt;
&lt;br /&gt;
so the default LC will be used.&lt;br /&gt;
&lt;br /&gt;
[[Category: Troubleshooting]]&lt;br /&gt;
[[Category: Templates]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=OS_template_cache_preparation&amp;diff=3728</id>
		<title>OS template cache preparation</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=OS_template_cache_preparation&amp;diff=3728"/>
		<updated>2007-12-06T12:32:27Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This article describes the procedure of an OS template cache creation.  It assumes you already have OpenVZ installed and running. The steps needed to achieve it are documented in the [[Quick installation]] document.&lt;br /&gt;
&lt;br /&gt;
== Terminology ==&lt;br /&gt;
&lt;br /&gt;
Please make sure you understand these terms:&lt;br /&gt;
&lt;br /&gt;
* [[OS template]]&lt;br /&gt;
* [[OS template metadata]]&lt;br /&gt;
* [[OS template cache]]&lt;br /&gt;
&lt;br /&gt;
== Creating an OS template cache ==&lt;br /&gt;
You can create an [[OS template cache]] using template utilities and [[OS template metadata]] right on your [[hardware node]]. The process is automated and will take from about 10 minutes to a few hours, depending on the network speed, and the result will be most up-to-date template cache.&lt;br /&gt;
&lt;br /&gt;
=== Installing template utilities ===&lt;br /&gt;
&lt;br /&gt;
You have to install a few packages in order to be able to create/update OS template cache(s).&lt;br /&gt;
&lt;br /&gt;
==== Using yum ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# yum install vzpkg vzyum vzrpm43-python vzrpm44-python&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Using rpm ====&lt;br /&gt;
Packages are available from [http://openvz.org/download/template/utils/ Download » Templates » Utilities]. You need both &amp;lt;tt&amp;gt;vzpkg&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;vzyum&amp;lt;/tt&amp;gt; packages, as well as one or both &amp;lt;tt&amp;gt;vzrpm43&amp;lt;/tt&amp;gt;/&amp;lt;tt&amp;gt;vzrpm44&amp;lt;/tt&amp;gt; (including their &amp;lt;tt&amp;gt;-python&amp;lt;/tt&amp;gt; counterparts), depending on the OS templates being used.&lt;br /&gt;
&lt;br /&gt;
Install these utilities using rpm:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# rpm -ihv vzpkg*.rpm vzyum*.rpm vzrpm44*.rpm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In Red Hat Enterprise Linux, to install &amp;lt;tt&amp;gt;vzyum&amp;lt;/tt&amp;gt; you will need &amp;lt;tt&amp;gt;[http://rpmfind.net/linux/rpm2html/search.php?query=python-elementtree&amp;amp;system=redhat python-elementtree]&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;[http://rpmfind.net/linux/rpm2html/search.php?query=python-sqlite&amp;amp;system=redhat python-sqlite]&amp;lt;/tt&amp;gt;, and &amp;lt;tt&amp;gt;[http://rpmfind.net/linux/rpm2html/search.php?query=python-urlgrabber&amp;amp;system=redhat python-urlgrabber]&amp;lt;/tt&amp;gt;. These packages might have dependencies of their own. For example, &amp;lt;tt&amp;gt;python-sqlite&amp;lt;/tt&amp;gt; needs &amp;lt;tt&amp;gt;[http://rpmfind.net/linux/rpm2html/search.php?query=sqlite&amp;amp;system=redhat sqlite]&amp;lt;/tt&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== Installing OS template metadata ===&lt;br /&gt;
&lt;br /&gt;
To create an [[OS template cache]], you need to get the [[OS template metadata|metadata]] for the chosen OS template(s).&lt;br /&gt;
&lt;br /&gt;
==== Using yum ====&lt;br /&gt;
To see which templates are available, run&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# yum search vztmpl&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To install some of the templates, run&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# yum install vztmpl-XXX [...]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Using rpm ====&lt;br /&gt;
Get the chosen &amp;lt;tt&amp;gt;vztmpl-*&amp;lt;/tt&amp;gt; packages from [http://openvz.org/download/template/metadata/ Downloads » Templates » Metadata] (or directly from [http://download.openvz.org/template/metadata/ download.openvz.org/template/metadata] or one of the [[Download mirrors|mirrors]] and install them:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# rpm -ihv vztmpl-*.rpm&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Installing repository cache (optional) ===&lt;br /&gt;
&lt;br /&gt;
Optionally, you may want to get a snapshot of the local copy of the package repository for the chosen OS template(s). This is not required but might speed up the initial OS template cache creation considerably. The tarballs are available from [http://openvz.org/download/template/repocache/ Downloads » Templates » Repo Cache]; download and untar them to the &amp;lt;tt&amp;gt;/vz/template&amp;lt;/tt&amp;gt; directory on your OpenVZ [[Hardware Node]]. If you choose to skip this step, all the needed files will be downloaded from the Internet automatically when needed.&lt;br /&gt;
&lt;br /&gt;
Note - The cache may be out of date meaning you end up downloading them all again anyway.&lt;br /&gt;
&lt;br /&gt;
=== Running &amp;lt;tt&amp;gt;vzpkgcache&amp;lt;/tt&amp;gt; ===&lt;br /&gt;
&lt;br /&gt;
Run the &amp;lt;tt&amp;gt;vzpkgcache&amp;lt;/tt&amp;gt; utility; see the vzpkgcache(8) man page for details. It will create or update the caches of all the templates for which the corresponding metadata exist.&lt;br /&gt;
&lt;br /&gt;
 # vzpkgcache centos-4-i386-minimal&lt;br /&gt;
&lt;br /&gt;
== Alternative: use precreated template cache ==&lt;br /&gt;
&lt;br /&gt;
As an alternative to creating a cache using template metadata, you can use precreated template cache taken from [http://openvz.org/download/template/cache Downloads » Templates » Precreated], or directly from [http://download.openvz.org/template/precreated/ download.openvz.org/template/precreated], or from one of the [[Download mirrors|mirrors]].&lt;br /&gt;
&lt;br /&gt;
Precreated templates can be easily updated using the following algorithm:&lt;br /&gt;
# create temporary VE based on template&lt;br /&gt;
# update VE using OS-specific tools (yum, apt or similar)&lt;br /&gt;
# pack VE as a new template&lt;br /&gt;
Examples of this procedure are described in details at [[Updating Ubuntu template]], [[Updating Debian template]], [[Fedora template update]]&lt;br /&gt;
&lt;br /&gt;
In order to use precreated template cache files, download files for chosen OS distributions and place them as-is (no unpacking needed) to the &amp;lt;tt&amp;gt;/vz/template/cache&amp;lt;/tt&amp;gt; directory.&lt;br /&gt;
&lt;br /&gt;
'''NOTE:''' If you use precreated CentOS-4 templates and wish to install software using vzyum, you will probably run into error like this:&lt;br /&gt;
&lt;br /&gt;
 [root@localhost tmp]# vzyum MYVPSID install mypackage&lt;br /&gt;
 [root@localhost tmp]# ERROR: No such OS template: install&lt;br /&gt;
&lt;br /&gt;
This might apply to Fedora also. To fix this problem, install the appropriate [[OS template metadata]] on the OpenVZ host, for example&lt;br /&gt;
&lt;br /&gt;
 yum install vztmpl-centos-4&lt;br /&gt;
&lt;br /&gt;
== Next step ==&lt;br /&gt;
&lt;br /&gt;
Follow on to the [[VE creation]] article.&lt;br /&gt;
&lt;br /&gt;
[[Category: Installation]]&lt;br /&gt;
[[Category: Templates]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Disappearing_routes_in_HN&amp;diff=3698</id>
		<title>Disappearing routes in HN</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Disappearing_routes_in_HN&amp;diff=3698"/>
		<updated>2007-12-03T14:40:31Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Problem statement ==&lt;br /&gt;
&lt;br /&gt;
Sometimes people complain about VE-related routes disappering in HN.&lt;br /&gt;
&lt;br /&gt;
These routes usually look like this:&lt;br /&gt;
&lt;br /&gt;
 # ip r l&lt;br /&gt;
 &amp;lt;skip&amp;gt;&lt;br /&gt;
 192.168.225.195 dev venet0  scope link&lt;br /&gt;
&lt;br /&gt;
and tell the kernel that IP address 192.168.225.195 belongs to venet0 device. Thus&lt;br /&gt;
packets with destination IP equal to 192.168.225.195 are forwarded to venet0 and&lt;br /&gt;
then to appropriate VE.&lt;br /&gt;
&lt;br /&gt;
== Resolution ==&lt;br /&gt;
&lt;br /&gt;
The problem is usually one of these:&lt;br /&gt;
# '''DHCP client'''. If your '''''host system''''' uses DHCP for acquiring IP address, then DHCP is for sure to blame. DHCP client tries to be smart and resets all the routes to those got from the server. Check your logs for DHCP re-lease events or other messages correlating with routes disappearing.&lt;br /&gt;
# '''Hotplug events'''. Modern Linux distros come with hotplug subsytem which tries to handle events like &amp;quot;new device found&amp;quot;, &amp;quot;device was unplugged&amp;quot;, etc. It also tries to be smart when LINK is DOWN/UP event from network device is received and can remove manually set routes. Check that your dmesg have anything related to this events. (AFAIK SUSE is the worst distro in this regard).&lt;br /&gt;
&lt;br /&gt;
== Debugging ==&lt;br /&gt;
&lt;br /&gt;
If you still can't find what happens with your network settings try to replace /sbin/ip and /sbin/route with scripts&lt;br /&gt;
logging the commands and programs which executed them and calling original binaries after that.&lt;br /&gt;
This will help to find the victim if it's some script. More robust but similar debug can be added&lt;br /&gt;
to kernel if first approach doesn't help.&lt;br /&gt;
&lt;br /&gt;
[[Category: Troubleshooting]]&lt;br /&gt;
[[Category: Networking]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Disappearing_routes_in_HN&amp;diff=3697</id>
		<title>Disappearing routes in HN</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Disappearing_routes_in_HN&amp;diff=3697"/>
		<updated>2007-12-03T14:39:47Z</updated>

		<summary type="html">&lt;p&gt;Dev: New page: == Problem statement ==  Sometimes people complain about VE-related routes disappering in HN.  These routes usually look like this:   # ip r l  &amp;lt;skip&amp;gt;  192.168.225.195 dev venet0  scope li...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Problem statement ==&lt;br /&gt;
&lt;br /&gt;
Sometimes people complain about VE-related routes disappering in HN.&lt;br /&gt;
&lt;br /&gt;
These routes usually look like this:&lt;br /&gt;
&lt;br /&gt;
 # ip r l&lt;br /&gt;
 &amp;lt;skip&amp;gt;&lt;br /&gt;
 192.168.225.195 dev venet0  scope link&lt;br /&gt;
&lt;br /&gt;
and tell the kernel that IP address 192.168.225.195 belongs to venet0 device. Thus&lt;br /&gt;
packets with destination IP equal to 192.168.225.195 are forwarded to venet0 and&lt;br /&gt;
then to appropriate VE.&lt;br /&gt;
&lt;br /&gt;
== Resolution ==&lt;br /&gt;
&lt;br /&gt;
The problem is usually one of these:&lt;br /&gt;
# '''DHCP client'''. If your '''''host system''''' uses DHCP for acquiring IP address, then DHCP is for sure to blame. DHCP client tries to be smart and resets all the routes to those got from the server. Check your logs for DHCP re-lease events or other messages correlating with routes disappearing.&lt;br /&gt;
# '''Hotplug events'''. Modern Linux distros come with hotplug subsytem which tries to handle events like &amp;quot;new device found&amp;quot;, &amp;quot;device was unplugged&amp;quot;, etc. It also tries to be smart when LINK is DOWN/UP event from network device is received and can remove manually set routes. Check that your dmesg have anything related to this events. (AFAIK SUSE is the worst distro in this regard).&lt;br /&gt;
&lt;br /&gt;
== Debugging ==&lt;br /&gt;
&lt;br /&gt;
If you still can find what happens with your network settings try to replace /sbin/ip and /sbin/route with scripts&lt;br /&gt;
logging the commands and programs which executed them and calling original binaries after that.&lt;br /&gt;
This will help to find the victim if it's some script. More robust but similar debug can be added&lt;br /&gt;
to kernel if first approach doesn't help.&lt;br /&gt;
&lt;br /&gt;
[[Category: Troubleshooting]]&lt;br /&gt;
[[Category: Networking]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Grsecurity&amp;diff=3664</id>
		<title>Grsecurity</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Grsecurity&amp;diff=3664"/>
		<updated>2007-11-27T10:38:51Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;There is a huge demand from people for support of grsecurity on OpenVZ.&lt;br /&gt;
However, unfortunately, grsecurity patch doesn't work as is (nor even applies) with OpenVZ kernel.&lt;br /&gt;
There were some efforts of supporting grsec in [http://bugzilla.openvz.org/show_bug.cgi?id=601 bug #607], but&lt;br /&gt;
failed and the grsecurity patch was never stable with OpenVZ.&lt;br /&gt;
&lt;br /&gt;
So instead OpenVZ team selected another approach. We port the features of grsecurity most requested by users and add them, maintain,&lt;br /&gt;
document and support.&lt;br /&gt;
&lt;br /&gt;
== TPE (Trusted Path Execution) ==&lt;br /&gt;
&lt;br /&gt;
Starting from 2.6.18-028stab047.1 stable kernels OpenVZ kernels support TPE grsecurity feature out of the box.&lt;br /&gt;
Which means root user can configure TPE inside VE as usual, i.e. via the following /proc files:&lt;br /&gt;
* /proc/sys/kernel/grsecurity/grsec_lock&lt;br /&gt;
* /proc/sys/kernel/grsecurity/tpe&lt;br /&gt;
* /proc/sys/kernel/grsecurity/tpe_gid&lt;br /&gt;
* /proc/sys/kernel/grsecurity/tpe_restrict_all&lt;br /&gt;
&lt;br /&gt;
To enable TPE feature in a standard way just type:&lt;br /&gt;
 # echo &amp;lt;GID&amp;gt; &amp;gt; /proc/sys/kernel/grsecurity/tpe_gid&lt;br /&gt;
 # echo 1 &amp;gt; /proc/sys/kernel/grsecurity/tpe&lt;br /&gt;
 ' lock grsecurity settings&lt;br /&gt;
 # echo 1 &amp;gt; /proc/sys/kernel/grsecurity/grsec_lock&lt;br /&gt;
&lt;br /&gt;
== Links ==&lt;br /&gt;
* http://www.grsecurity.net/&lt;br /&gt;
&lt;br /&gt;
[[Category: Kernel]]&lt;br /&gt;
[[Category: HOWTO]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Grsecurity&amp;diff=3571</id>
		<title>Grsecurity</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Grsecurity&amp;diff=3571"/>
		<updated>2007-11-07T18:28:13Z</updated>

		<summary type="html">&lt;p&gt;Dev: New page: There is a huge demand from people for support of grsecurity on OpenVZ. However, unfortunately, grsecurity patch doesn't work as is (nor even applies) with OpenVZ kernel. There were some e...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;There is a huge demand from people for support of grsecurity on OpenVZ.&lt;br /&gt;
However, unfortunately, grsecurity patch doesn't work as is (nor even applies) with OpenVZ kernel.&lt;br /&gt;
There were some efforts of supporting grsec in [http://bugzilla.openvz.org/show_bug.cgi?id=601 bug #607], but&lt;br /&gt;
failed and the grsecurity patch was never stable with OpenVZ.&lt;br /&gt;
&lt;br /&gt;
So instead OpenVZ team selected another approach. We port the features of grsecurity most requested by users and add them, maintain,&lt;br /&gt;
document and support.&lt;br /&gt;
&lt;br /&gt;
== TPE (Trusted Path Execution) ==&lt;br /&gt;
&lt;br /&gt;
Starting from 2.6.18-028stab047.1 stable kernels OpenVZ kernels support TPE grsecurity feature out of the box.&lt;br /&gt;
Which means root user can configure TPE inside VE as usually accessing the following /proc files:&lt;br /&gt;
* /proc/sys/kernel/grsecurity/grsec_lock&lt;br /&gt;
* /proc/sys/kernel/grsecurity/tpe&lt;br /&gt;
* /proc/sys/kernel/grsecurity/tpe_gid&lt;br /&gt;
* /proc/sys/kernel/grsecurity/tpe_restrict_all&lt;br /&gt;
&lt;br /&gt;
To enable TPE feature standart way just type:&lt;br /&gt;
 # echo &amp;lt;GID&amp;gt; &amp;gt; /proc/sys/kernel/grsecurity/tpe_gid&lt;br /&gt;
 # echo 1 &amp;gt; /proc/sys/kernel/grsecurity/tpe&lt;br /&gt;
 ' lock grsecurity settings&lt;br /&gt;
 # echo 1 &amp;gt; /proc/sys/kernel/grsecurity/grsec_lock&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Bridge_doesn%27t_forward_packets&amp;diff=3528</id>
		<title>Bridge doesn't forward packets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Bridge_doesn%27t_forward_packets&amp;diff=3528"/>
		<updated>2007-10-19T11:16:31Z</updated>

		<summary type="html">&lt;p&gt;Dev: New page: = Bridge doesn't forward packets =   Sometimes bridge can mysteriously drop the packets and not forward them. e.g. eyck user experienced a problem when some of the broadcasts were not deli...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Bridge doesn't forward packets = &lt;br /&gt;
&lt;br /&gt;
Sometimes bridge can mysteriously drop the packets and not forward them.&lt;br /&gt;
e.g. eyck user experienced a problem when some of the broadcasts were not delivered to VE via the bridge.&lt;br /&gt;
&lt;br /&gt;
Original report and the thread: [http://forum.openvz.org/index.php?t=tree&amp;amp;th=4052&amp;amp; forum thread]&lt;br /&gt;
&lt;br /&gt;
== Simplest configuration ==&lt;br /&gt;
&lt;br /&gt;
VE #101 with veth interface (veth101.0) connected to eth0 physical interface via bridge.&lt;br /&gt;
&lt;br /&gt;
== Problem statement ==&lt;br /&gt;
&lt;br /&gt;
We faced a situation when some of the broadcast packets were not delivered to the VE.&lt;br /&gt;
Actually it could happen with any packets, not with the broadcasts only. But broadcasts are&lt;br /&gt;
simpler and obviously should have been delivered to all the networking interfaces with no doubt.&lt;br /&gt;
&lt;br /&gt;
Using tcpdump we see that BOOTP/DHCP request is visible on br0 interface in the host system (VE0):&lt;br /&gt;
  15:21:52.258220 00:1b:d5:2c:bf:38 &amp;gt; ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 &amp;gt; 255.255.255.255.67:&lt;br /&gt;
    BOOTP/DHCP, Request from 00:1b:d5:2c:bf:38, length 308&lt;br /&gt;
  15:21:52.287269 00:08:02:ac:36:20 &amp;gt; ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 172.17.8.254.67 &amp;gt; 255.255.255.255.68:&lt;br /&gt;
    BOOTP/DHCP, Reply, length 300&lt;br /&gt;
&lt;br /&gt;
However, eth0 inside VE receives only 2nd packet with BOOTP/DHCP reply and doesn't see the 1st one with the request itself:&lt;br /&gt;
  15:21:52.291145 00:08:02:ac:36:20 &amp;gt; ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 172.17.8.254.67 &amp;gt; 255.255.255.255.68:&lt;br /&gt;
    BOOTP/DHCP, Reply, length 300&lt;br /&gt;
&lt;br /&gt;
== Resolution ==&lt;br /&gt;
&lt;br /&gt;
It is not obvious at all, but bridges (though have own ebtables filters) do also call iptables FORWARD chain when forwarding packets between interfaces.&lt;br /&gt;
Thus your FORWARD iptables rules should allow all the packets which are supposed to go through.&lt;br /&gt;
&lt;br /&gt;
in our case eyck had a default DROP policy on FORWARD and had to add:&lt;br /&gt;
  iptables -A FORWARD -d 255.255.255.255 -j ACCEPT&lt;br /&gt;
to fix the issue.&lt;br /&gt;
&lt;br /&gt;
== Credits ==&lt;br /&gt;
Many credits to Dariush Pietrzak, who patiently helped to debug this.&lt;br /&gt;
&lt;br /&gt;
[[Category:Troubleshooting]]&lt;br /&gt;
[[Category:Networking]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&amp;diff=3527</id>
		<title>Virtual Ethernet device</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&amp;diff=3527"/>
		<updated>2007-10-19T10:42:20Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Virtual ethernet device''' is an ethernet-like device which can be used inside a [[VE]]. Unlike&lt;br /&gt;
[[venet]] network device, veth device has a MAC address. Due to this, it can be used in configurations, when veth is bridged to ethX or other device and VE user fully sets up his networking himself, &lt;br /&gt;
including IPs, gateways etc.&lt;br /&gt;
&lt;br /&gt;
Virtual ethernet device consist of two ethernet devices - one in [[VE0]] and another one &lt;br /&gt;
in VE. These devices are connected to each other, so if a packet goes to one&lt;br /&gt;
device it will come out from the other device.&lt;br /&gt;
&lt;br /&gt;
== Virtual ethernet device usage ==&lt;br /&gt;
&lt;br /&gt;
=== Kernel module ===&lt;br /&gt;
First of all, make sure the &amp;lt;code&amp;gt;vzethdev&amp;lt;/code&amp;gt; module is loaded:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# lsmod | grep vzeth&lt;br /&gt;
vzethdev                8224  0&lt;br /&gt;
vzmon                  35164  5 vzethdev,vznetdev,vzrst,vzcpt&lt;br /&gt;
vzdev                   3080  4 vzethdev,vznetdev,vzmon,vzdquota&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In case it is not loaded, load it:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# modprobe vzethdev&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You might want to add the module to &amp;lt;code&amp;gt;/etc/init.d/vz script&amp;lt;/code&amp;gt;, so it will be loaded during startup.&lt;br /&gt;
&lt;br /&gt;
{{Note|since vzctl version 3.0.11, vzethdev is loaded by /etc/init.d/vz}}&lt;br /&gt;
&lt;br /&gt;
=== MAC addresses ===&lt;br /&gt;
In the below commands, you should use random MAC addresses. Do not use MAC addresses of real eth devices, because this can lead to collisions.&lt;br /&gt;
&lt;br /&gt;
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.&lt;br /&gt;
&lt;br /&gt;
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is to be used like this:&lt;br /&gt;
&lt;br /&gt;
 chmod +x easymac.sh&lt;br /&gt;
 ./easymac.sh -R&lt;br /&gt;
&lt;br /&gt;
=== Adding veth to a VE ===&lt;br /&gt;
&lt;br /&gt;
==== syntax vzctl version &amp;lt; 3.0.14 ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
vzctl set &amp;lt;VEID&amp;gt; --veth_add &amp;lt;dev_name&amp;gt;,&amp;lt;dev_addr&amp;gt;,&amp;lt;ve_dev_name&amp;gt;,&amp;lt;ve_dev_addr&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here &lt;br /&gt;
* &amp;lt;tt&amp;gt;dev_name&amp;lt;/tt&amp;gt; is the ethernet device name that you are creating on the [[VE0|host system]]&lt;br /&gt;
* &amp;lt;tt&amp;gt;dev_addr&amp;lt;/tt&amp;gt; is its MAC address&lt;br /&gt;
* &amp;lt;tt&amp;gt;ve_dev_name&amp;lt;/tt&amp;gt; is the corresponding ethernet device name you are creating on the VE&lt;br /&gt;
* &amp;lt;tt&amp;gt;ve_dev_addr&amp;lt;/tt&amp;gt; is its MAC address&lt;br /&gt;
&lt;br /&gt;
{{Note| that this option is incremental, so devices are added to already existing ones.}}&lt;br /&gt;
&lt;br /&gt;
NB there are no spaces after the commas&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
vzctl set 101 --veth_add veth101.0,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
After executing this command &amp;lt;tt&amp;gt;veth&amp;lt;/tt&amp;gt; device will be created for VE 101 and veth configuration will be saved to a VE configuration file.&lt;br /&gt;
Host-side ethernet device will have &amp;lt;tt&amp;gt;veth101.0&amp;lt;/tt&amp;gt; name and &amp;lt;tt&amp;gt;00:12:34:56:78:9A&amp;lt;/tt&amp;gt; MAC address.&lt;br /&gt;
VE-side ethernet device will have &amp;lt;tt&amp;gt;eth0&amp;lt;/tt&amp;gt; name and &amp;lt;tt&amp;gt;00:12:34:56:78:9B&amp;lt;/tt&amp;gt; MAC address.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== syntax vzctl version &amp;gt;= 3.0.14 ====&lt;br /&gt;
&lt;br /&gt;
Read Update infos about [http://openvz.org/news/updates/vzctl-3.0.14-1 vzctl 3.0.14]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
vzctl set &amp;lt;VEID&amp;gt; --netif_add &amp;lt;ifname&amp;gt;[,&amp;lt;mac&amp;gt;,&amp;lt;host_ifname&amp;gt;,&amp;lt;host_mac]&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here&lt;br /&gt;
* &amp;lt;tt&amp;gt;ifname&amp;lt;/tt&amp;gt; is the ethernet device name in the VE&lt;br /&gt;
* &amp;lt;tt&amp;gt;mac&amp;lt;/tt&amp;gt; is its MAC address in the VE&lt;br /&gt;
* &amp;lt;tt&amp;gt;host_ifname&amp;lt;/tt&amp;gt;  is the ethernet device name on the host ([[VE0]])&lt;br /&gt;
* &amp;lt;tt&amp;gt;host_mac&amp;lt;/tt&amp;gt; is its MAC address on the host ([[VE0]])&lt;br /&gt;
&lt;br /&gt;
{{Note|All parameters except ifname are optional and are automatically generated if not specified.}}&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Removing veth from a VE ===&lt;br /&gt;
&lt;br /&gt;
==== syntax vzctl version &amp;lt; 3.0.14 ====&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
vzctl set &amp;lt;VEID&amp;gt; --veth_del &amp;lt;dev_name&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
Here &amp;lt;tt&amp;gt;dev_name&amp;lt;/tt&amp;gt; is the ethernet device name in the [[VE0|host system]].&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
vzctl set 101 --veth_del veth101.0 --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
After executing this command veth device with host-side ethernet name veth101.0 will be removed from VE 101 and veth configuration will be updated in VE config file.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== syntax vzctl version &amp;gt;= 3.0.14 ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
vzctl set &amp;lt;VEID&amp;gt; --netif_del &amp;lt;dev_name&amp;gt;|all&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here&lt;br /&gt;
* &amp;lt;code&amp;gt;dev_name&amp;lt;/code&amp;gt; is the ethernet device name in the [[VE]].&lt;br /&gt;
&lt;br /&gt;
{{Note|If you want to remove all ethernet devices in VE, use &amp;lt;code&amp;gt;all&amp;lt;/code&amp;gt;.}}&lt;br /&gt;
&lt;br /&gt;
Example:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
vzctl set 101 --netif_del eth0 --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Common configurations with virtual ethernet devices ==&lt;br /&gt;
Module &amp;lt;tt&amp;gt;vzethdev&amp;lt;/tt&amp;gt; must be loaded to operate with veth devices.&lt;br /&gt;
&lt;br /&gt;
=== Simple configuration with virtual ethernet device ===&lt;br /&gt;
&lt;br /&gt;
==== Start a VE ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# vzctl start 101&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Add veth device to VE ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# vzctl set 101 --veth_add veth101.0,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Configure devices in VE0 ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# ifconfig veth101.0 0&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv4/conf/veth101.0/forwarding&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv4/conf/veth101.0/proxy_arp&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv4/conf/eth0/forwarding&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv4/conf/eth0/proxy_arp&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Configure device in VE ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# vzctl enter 101&lt;br /&gt;
[ve-101]# /sbin/ifconfig eth0 0&lt;br /&gt;
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0&lt;br /&gt;
[ve-101]# /sbin/ip route add default dev eth0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Add route in [[VE0]] ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# ip route add 192.168.0.101 dev veth101.0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Virtual ethernet device with IPv6 ===&lt;br /&gt;
&lt;br /&gt;
==== Start [[VE]] ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# vzctl start 101&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Add veth device to [[VE]] ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# vzctl set 101 --veth_add veth101.0,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Configure devices in [[VE0]] ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# ifconfig veth101.0 0&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv6/conf/veth101.0/forwarding&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv6/conf/eth0/forwarding&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv6/conf/all/forwarding&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Configure device in [[VE]] ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# vzctl enter 101&lt;br /&gt;
[ve-101]# /sbin/ifconfig eth0 0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Start router advertisement daemon (radvd) for IPv6 in VE0 ====&lt;br /&gt;
First you need to edit radvd configuration file. Here is a simple example of &amp;lt;tt&amp;gt;/etc/radv.conf&amp;lt;/tt&amp;gt;:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
interface veth101.0&lt;br /&gt;
{&lt;br /&gt;
        AdvSendAdvert on;&lt;br /&gt;
        MinRtrAdvInterval 3;&lt;br /&gt;
        MaxRtrAdvInterval 10;&lt;br /&gt;
        AdvHomeAgentFlag off;&lt;br /&gt;
&lt;br /&gt;
        prefix 3ffe:2400:0:0::/64&lt;br /&gt;
        {&lt;br /&gt;
                AdvOnLink on;&lt;br /&gt;
                AdvAutonomous on;&lt;br /&gt;
                AdvRouterAddr off;&lt;br /&gt;
        };&lt;br /&gt;
};&lt;br /&gt;
&lt;br /&gt;
interface eth0&lt;br /&gt;
{&lt;br /&gt;
        AdvSendAdvert on;&lt;br /&gt;
        MinRtrAdvInterval 3;&lt;br /&gt;
        MaxRtrAdvInterval 10;&lt;br /&gt;
        AdvHomeAgentFlag off;&lt;br /&gt;
&lt;br /&gt;
        prefix 3ffe:0302:0011:0002::/64&lt;br /&gt;
        {&lt;br /&gt;
                AdvOnLink on;&lt;br /&gt;
                AdvAutonomous on;&lt;br /&gt;
                AdvRouterAddr off;&lt;br /&gt;
        };&lt;br /&gt;
};&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Then, start radvd:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# /etc/init.d/radvd start&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Add IPv6 addresses to devices in [[VE0]] ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# ip addr add dev veth101.0 3ffe:2400::212:34ff:fe56:789a/64&lt;br /&gt;
[host-node]# ip addr add dev eth0 3ffe:0302:0011:0002:211:22ff:fe33:4455/64&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Virtual ethernet devices can be joined in one bridge ===&lt;br /&gt;
Perform steps 1 - 4 from Simple configuration chapter for several VEs and/or veth devices&lt;br /&gt;
&lt;br /&gt;
==== Create bridge device ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# brctl addbr vzbr0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Add veth devices to bridge ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# brctl addif vzbr0 veth101.0&lt;br /&gt;
...&lt;br /&gt;
[host-node]# brctl addif vzbr0 veth101.n&lt;br /&gt;
[host-node]# brctl addif vzbr0 veth102.0&lt;br /&gt;
...&lt;br /&gt;
...&lt;br /&gt;
[host-node]# brctl addif vzbr0 vethXXX.N&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Configure bridge device ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# ifconfig vzbr0 0&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv4/conf/vzbr0/forwarding&lt;br /&gt;
[host-node]# echo 1 &amp;gt; /proc/sys/net/ipv4/conf/vzbr0/proxy_arp&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Add routes in [[VE0]] ====&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
[host-node]# ip route add 192.168.101.1 dev vzbr0&lt;br /&gt;
...&lt;br /&gt;
[host-node]# ip route add 192.168.101.n dev vzbr0&lt;br /&gt;
[host-node]# ip route add 192.168.102.1 dev vzbr0&lt;br /&gt;
...&lt;br /&gt;
...&lt;br /&gt;
[host-node]# ip route add 192.168.XXX.N dev vzbr0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Thus you'll have more convinient configuration, i.e. all routes to VEs will be through this bridge and VEs can communicate with each other even without these routes.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Making a veth-device persistent ===&lt;br /&gt;
&lt;br /&gt;
At the moment, it is not possible to have the commands needed for a persistent veth being made automatically be vzctl. A  bugreport ( http://bugzilla.openvz.org/show_bug.cgi?id=301 ) has already been made. Until then, here's a way to make the above steps persistent.&lt;br /&gt;
&lt;br /&gt;
1. First, edit the VE's configuration to specify what the veth's IP address(es) should be, and to indicate that a custom script should be run when starting up a VE.&lt;br /&gt;
* Open up /etc/vz/conf/VEID.conf&lt;br /&gt;
* Comment out any IP_ADDRESS entries to prevent a VENET-device from being created in the VE&lt;br /&gt;
* Add or change the entry CONFIG_CUSTOMIZED=&amp;quot;yes&amp;quot;&lt;br /&gt;
* Add an entry VETH_IP_ADDRESS=&amp;quot;&amp;lt;VE IP&amp;gt;&amp;quot; The VE IP can have multiple IPs, separated by spaces&lt;br /&gt;
&lt;br /&gt;
2. Now to create that &amp;quot;custom script&amp;quot;. The following helper script will check the configuration file for IP addresses and for the veth interface, and configure the IP routing accordingly. Create the script /usr/sbin/vznetaddroute to have the following, and then &amp;lt;code&amp;gt;chmod 0500 /usr/sbin/vznetaddroute&amp;lt;/code&amp;gt; to make it executable.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
#!/bin/bash&lt;br /&gt;
# /usr/sbin/vznetaddroute&lt;br /&gt;
# a script to bring up virtual network interfaces (veth's) in a VE&lt;br /&gt;
&lt;br /&gt;
CONFIGFILE=/etc/vz/conf/$VEID.conf&lt;br /&gt;
. $CONFIGFILE&lt;br /&gt;
VZHOSTIF=`echo $NETIF |sed 's/^.*host_ifname=\(.*\),.*$/\1/g'`&lt;br /&gt;
&lt;br /&gt;
if [ ! -n &amp;quot;$VETH_IP_ADDRESS&amp;quot; ]; then&lt;br /&gt;
   echo &amp;quot;According to $CONFIGFILE VE$VEID has no veth IPs configured.&amp;quot;&lt;br /&gt;
   exit 1&lt;br /&gt;
fi&lt;br /&gt;
&lt;br /&gt;
if [ ! -n &amp;quot;$VZHOSTIF&amp;quot; ]; then&lt;br /&gt;
   echo &amp;quot;According to $CONFIGFILE VE$VEID has no veth interface configured.&amp;quot;&lt;br /&gt;
   exit 1&lt;br /&gt;
fi&lt;br /&gt;
&lt;br /&gt;
for IP in $VETH_IP_ADDRESS; do&lt;br /&gt;
   echo &amp;quot;Adding interface $VZHOSTIF and route $IP for VE$VEID to VE0&amp;quot;&lt;br /&gt;
   /sbin/ifconfig $VZHOSTIF 0&lt;br /&gt;
   echo 1 &amp;gt; /proc/sys/net/ipv4/conf/$VZHOSTIF/proxy_arp&lt;br /&gt;
   echo 1 &amp;gt; /proc/sys/net/ipv4/conf/$VZHOSTIF/forwarding&lt;br /&gt;
   /sbin/ip route add $IP dev $VZHOSTIF&lt;br /&gt;
done&lt;br /&gt;
&lt;br /&gt;
exit 0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
3. Now create /etc/vz/vznet.conf containing the following. This is what defines the &amp;quot;custom script&amp;quot; as being the vznetaddroute which you just created.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
#!/bin/bash&lt;br /&gt;
EXTERNAL_SCRIPT=&amp;quot;/usr/sbin/vznetaddroute&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
4. Of course, the VE's operating system will need to be configured with those IP address(es) as well. Consult the manual for your VE's OS for details.&lt;br /&gt;
&lt;br /&gt;
That's it! At this point, when you restart the VE you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the VE and use the network.&lt;br /&gt;
&lt;br /&gt;
=== Virtual ethernet devices + VLAN ===&lt;br /&gt;
This configuration can be done by adding vlan device to the previous configuration.&lt;br /&gt;
&lt;br /&gt;
== See also ==&lt;br /&gt;
* [[Virtual network device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;br /&gt;
* Troubleshooting: [[Bridge doesn't forward packets]]&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category: Networking]]&lt;br /&gt;
[[Category: HOWTO]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Talk:VE_inside_VE&amp;diff=3476</id>
		<title>Talk:VE inside VE</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Talk:VE_inside_VE&amp;diff=3476"/>
		<updated>2007-10-01T16:48:36Z</updated>

		<summary type="html">&lt;p&gt;Dev: New page: it's not possible to run VE inside VE, the same way like VM inside VM usually is not allowed as well. mostly this is due to performance reasons. nested namespaces/environments/... add noti...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;it's not possible to run VE inside VE, the same way like VM inside VM usually is not allowed as well. mostly this is due to performance reasons. nested namespaces/environments/... add noticable overhead.&lt;br /&gt;
So simply buy another cheap VE where you can play with your untrusted apps.&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Oracle9i_in_SLES9_container&amp;diff=3464</id>
		<title>Oracle9i in SLES9 container</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Oracle9i_in_SLES9_container&amp;diff=3464"/>
		<updated>2007-09-24T12:06:11Z</updated>

		<summary type="html">&lt;p&gt;Dev: New page: = Oracle9i in SLES9 SP2 VE =  This small HOWTO is to help people to install Oracle 9i in SLES9-SP2 VE. Installation of Oracle is quite a complicated procedure and actually has little to do...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Oracle9i in SLES9 SP2 VE =&lt;br /&gt;
&lt;br /&gt;
This small HOWTO is to help people to install Oracle 9i in SLES9-SP2 VE.&lt;br /&gt;
Installation of Oracle is quite a complicated procedure and actually has little&lt;br /&gt;
to do anything with VE or OpenVZ virtualization, but is frequently asked about.&lt;br /&gt;
&lt;br /&gt;
Installation of other Oracle versions in other VE OS can differ and should be decribed&lt;br /&gt;
in separate Wiki pages.&lt;br /&gt;
&lt;br /&gt;
== Inside host system (VE0) ==&lt;br /&gt;
&lt;br /&gt;
First, create and cache SLES9 x8664.&lt;br /&gt;
You will need to install gcc, binutils and other packages required by Oracle&lt;br /&gt;
either in SLES9 cache or alter directly inside the VE.&lt;br /&gt;
&lt;br /&gt;
Create VE based on latest SLES9 x8664 template:&lt;br /&gt;
 vzctl create $VEID --ostemplate sles-9-x86_64&lt;br /&gt;
&lt;br /&gt;
Assign some IP address to the VE:&lt;br /&gt;
 vzctl set $VEID --ipadd $VE_IP_ADDRESS --save&lt;br /&gt;
&lt;br /&gt;
Setup nameserver inside VE (/etc/resolv.conf):&lt;br /&gt;
 vzctl set $VEID --nameserver $DNS_IP&lt;br /&gt;
&lt;br /&gt;
Set enough resource limits inside VE (in this example ~2GB RAM):&lt;br /&gt;
 vzctl set $VEID --save --applyconfig vps.2048MB&lt;br /&gt;
&lt;br /&gt;
Set enough disk space for the VE (e.g. to 15GB):&lt;br /&gt;
 vzctl set $VEID --save --diskspace 15000000&lt;br /&gt;
&lt;br /&gt;
== Inside VE ==&lt;br /&gt;
&lt;br /&gt;
All the following instructions are not OpenVZ/Virtuozzo specific and mostly taken as is from&lt;br /&gt;
official [http://ftp.novell.com/partners/oracle/docs/9205_sles9_install.pdf SUSE guide]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Login to VE and do the following:&lt;br /&gt;
&lt;br /&gt;
Run '''yast''' and setup SLES9 repository or SLES9 CDs local repository,&lt;br /&gt;
then install following packages:&lt;br /&gt;
  - glibc-devel-32bit&lt;br /&gt;
  - pdksh&lt;br /&gt;
  - libaio&lt;br /&gt;
  - libaio-devel&lt;br /&gt;
&lt;br /&gt;
Now install &amp;quot;orarun&amp;quot; package from SLES9 SP2 CD2. You can use YaST setup&lt;br /&gt;
tool or manual installation instruction to install '''orarun''' package.&lt;br /&gt;
&lt;br /&gt;
After '''orarun''' package is installed enable ''''oracle'''' user:&lt;br /&gt;
 usermod -s /bin/bash oracle&lt;br /&gt;
&lt;br /&gt;
Specify password for ''''oracle'''' user&lt;br /&gt;
 passwd oracle&lt;br /&gt;
&lt;br /&gt;
Run '''rcoracle''' script to set kernel parameters. Ignore any errors.&lt;br /&gt;
 /usr/sbin/rcoracle start&lt;br /&gt;
&lt;br /&gt;
Create link for libdb library:&lt;br /&gt;
 ln -s /usr/lib/libdb.so.3 /usr/lib/libdb.so.2&lt;br /&gt;
&lt;br /&gt;
Setup graphical access to VE via ssh or via vnc, at your choice:&lt;br /&gt;
* For access via ssh:&lt;br /&gt;
** Change X11Forwarding in /etc/ssh/sshd_config to 'yes' inside VE&lt;br /&gt;
** Restart sshd inside VE (/etc/init.d/sshd restart)&lt;br /&gt;
** Login to VE via ssh with '-X' option (run this command from your host):&lt;br /&gt;
 ssh -X oracle@$VE_ADDRESS&lt;br /&gt;
&lt;br /&gt;
* For access via VNC, do inside VE:&lt;br /&gt;
** Install XFree86, XFree86-Vnc packages inside VE&lt;br /&gt;
** Login to VE as 'oracle' (run this command from your host):&lt;br /&gt;
 ssh oracle@$VE_ADDRESS&lt;br /&gt;
** start VNC server:&lt;br /&gt;
 Xvnc :0 &amp;amp;&lt;br /&gt;
** set DISPLAY environment variable:&lt;br /&gt;
 export DISPLAY=:0&lt;br /&gt;
** From your host attach to vnc screen (run this command from your host):&lt;br /&gt;
 vncviewer $VE_ADDRESS:0&lt;br /&gt;
&lt;br /&gt;
 NOTE: this may require to use vncviewer from SLES9 OS, since newer vncviewer's are not compatible with it.&lt;br /&gt;
&lt;br /&gt;
Now, as ''''oracle'''' user inside VE:&lt;br /&gt;
&lt;br /&gt;
Get Oracle 9iR2 (9204) Software from oracle web or use your Oracle Disks.&lt;br /&gt;
If you have downloaded SW then gunzip and cpio files.&lt;br /&gt;
 gunzip $file_name&lt;br /&gt;
 cpio command: cpio -idmv &amp;lt; file_name&lt;br /&gt;
&lt;br /&gt;
It will create three directory '''Disk1''', '''Disk2''' and '''Disk3'''.&lt;br /&gt;
&lt;br /&gt;
Finally start oracle installer (under '''oracle''' user):&lt;br /&gt;
 Disk1/runInstaller&lt;br /&gt;
&lt;br /&gt;
and carefully follow installation instructions.&lt;br /&gt;
&lt;br /&gt;
After the installation succeeds oracle automaticaly runs a created by default database instance,&lt;br /&gt;
so you can use sqlplus to test it.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
NOTE: Oracle 9i installation on SLES9 is tricky and requires a lot of steps&lt;br /&gt;
and workarounds described in official papers and in the internet. The following links may be helpful:&lt;br /&gt;
&lt;br /&gt;
* http://ftp.novell.com/partners/oracle/docs/9205_sles9_install.pdf&lt;br /&gt;
* http://ivan.kartik.sk/oracle/install_ora9_suse.html&lt;br /&gt;
* http://www.nextre.it/oracledocs/oracle9ionsles9amd64.html&lt;br /&gt;
* http://www.chmouel.com/blog/2006/12/21/error-loading-native-library-libnjni9so/&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Talk:DB2_installation&amp;diff=3445</id>
		<title>Talk:DB2 installation</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Talk:DB2_installation&amp;diff=3445"/>
		<updated>2007-09-11T05:54:29Z</updated>

		<summary type="html">&lt;p&gt;Dev: New page: 1.  I would use some existing VE config sample in chapter &amp;quot;Set VE resource limits appropriately&amp;quot;, e.g.: # vzctl set &amp;lt;VEID&amp;gt; --appylyconfig vps.1GB-sample --save  2. Can you please add: - ex...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;1. &lt;br /&gt;
I would use some existing VE config sample in chapter &amp;quot;Set VE resource limits appropriately&amp;quot;, e.g.:&lt;br /&gt;
# vzctl set &amp;lt;VEID&amp;gt; --appylyconfig vps.1GB-sample --save&lt;br /&gt;
&lt;br /&gt;
2.&lt;br /&gt;
Can you please add:&lt;br /&gt;
- exact debian version you used,&lt;br /&gt;
- exact commands on how to install additional packages?&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance_tuning&amp;diff=3385</id>
		<title>Performance tuning</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance_tuning&amp;diff=3385"/>
		<updated>2007-08-03T16:14:19Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page describes how to improve performance of OpenVZ system.&lt;br /&gt;
&lt;br /&gt;
= HW node environment tuning =&lt;br /&gt;
&lt;br /&gt;
== Disable unnecessary services ==&lt;br /&gt;
&lt;br /&gt;
Disable all default services that you do not need to use and then reboot your host. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For example, the &amp;lt;code&amp;gt;audit&amp;lt;/code&amp;gt; daemon can significantly decrease performance of linux kernel system calls (up to ~&amp;lt;font color=red&amp;gt;20%&amp;lt;/font&amp;gt;) even if you do not use any audit rules, or even if you just stopped this service without host reboot!&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To setup default services, use &amp;lt;code&amp;gt;chkconfig&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;ntsysv&amp;lt;/code&amp;gt; in RedHat, or &amp;lt;code&amp;gt;rc-update&amp;lt;/code&amp;gt; in Gentoo, &amp;lt;code&amp;gt;update-rc.dv&amp;lt;/code&amp;gt; on Debian&lt;br /&gt;
&lt;br /&gt;
= Virtual Environment tuning =&lt;br /&gt;
&lt;br /&gt;
== CPU distribution inside VE on SMP hosts ==&lt;br /&gt;
&lt;br /&gt;
* If the total number of VE's in your host is more than CPUs number, and there are many '''threads''' running inside each VE it is better to give just a single VCPU to each VE.&lt;br /&gt;
In this case thread memory locality will significantly reduce overhead on SMP memory coherence and overall performance can be increased up to ~&amp;lt;font color=red&amp;gt;50-100%&amp;lt;/font&amp;gt;!&lt;br /&gt;
&lt;br /&gt;
To set the number of CPUs available inside VE use:&lt;br /&gt;
&lt;br /&gt;
 # vzctl set $VEID --cpus N&lt;br /&gt;
&lt;br /&gt;
== network checksumming ==&lt;br /&gt;
('''TODO''')&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Performance_tuning&amp;diff=3384</id>
		<title>Performance tuning</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Performance_tuning&amp;diff=3384"/>
		<updated>2007-08-03T16:13:38Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page describes how to improve performance of OpenVZ system.&lt;br /&gt;
&lt;br /&gt;
= HW node environment tuning =&lt;br /&gt;
&lt;br /&gt;
== Disable unnecessary services ==&lt;br /&gt;
&lt;br /&gt;
Disable all default services that you do not need to use and then reboot your host. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For example, the &amp;lt;code&amp;gt;audit&amp;lt;/code&amp;gt; daemon can significantly decrease performance of linux kernel system calls (up to ~&amp;lt;font color=red&amp;gt;20%&amp;lt;/font&amp;gt;) even if you do not use any audit rules, or even if you just stopped this service without host reboot!&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To setup default services, use &amp;lt;code&amp;gt;chkconfig&amp;lt;/code&amp;gt; or &amp;lt;code&amp;gt;ntsysv&amp;lt;/code&amp;gt; in RedHat, or &amp;lt;code&amp;gt;rc-update&amp;lt;/code&amp;gt; in Gentoo, &amp;lt;code&amp;gt;update-rc.dv&amp;lt;/code&amp;gt; on Debian&lt;br /&gt;
&lt;br /&gt;
== network checksumming ==&lt;br /&gt;
('''TODO''')&lt;br /&gt;
&lt;br /&gt;
= Virtual Environment tuning =&lt;br /&gt;
&lt;br /&gt;
== CPU distribution inside VE on SMP hosts ==&lt;br /&gt;
&lt;br /&gt;
* If the total number of VE's in your host is more than CPUs number, and there are many '''threads''' running inside each VE it is better to give just a single VCPU to each VE.&lt;br /&gt;
In this case thread memory locality will significantly reduce overhead on SMP memory coherence and overall performance can be increased up to ~&amp;lt;font color=red&amp;gt;50-100%&amp;lt;/font&amp;gt;!&lt;br /&gt;
&lt;br /&gt;
To set the number of CPUs available inside VE use:&lt;br /&gt;
&lt;br /&gt;
 # vzctl set $VEID --cpus N&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Different_kernel_flavors_(UP,_SMP,_ENTERPRISE,_ENTNOSPLIT)&amp;diff=3346</id>
		<title>Different kernel flavors (UP, SMP, ENTERPRISE, ENTNOSPLIT)</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Different_kernel_flavors_(UP,_SMP,_ENTERPRISE,_ENTNOSPLIT)&amp;diff=3346"/>
		<updated>2007-07-20T14:31:48Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;OpenVZ project releases several different precompiled kernels for each version. Which kernel to choose depends on what hardware do you have. The table below describes the cases when it is better to use each of these kernels.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+'''i686 kernel flavors list'''&lt;br /&gt;
! Kernel type !! Description !! Hardware !! Use case&lt;br /&gt;
|-&lt;br /&gt;
! UP&lt;br /&gt;
| uniprocessor&lt;br /&gt;
| up to 4GB of RAM&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
! SMP&lt;br /&gt;
| symmetric multiprocessor&lt;br /&gt;
| up to 4 GB of RAM&lt;br /&gt;
| 10-20 [[VE]]s&lt;br /&gt;
|-&lt;br /&gt;
! entnosplit/PAE&lt;br /&gt;
| SMP + PAE support&lt;br /&gt;
| up to 64 GB of RAM&lt;br /&gt;
| 10-30 [[VE]]s&lt;br /&gt;
|-&lt;br /&gt;
! enterprise/ent&lt;br /&gt;
| SMP + PAE support + 4/4GB split&lt;br /&gt;
| up to 64 GB of RAM&lt;br /&gt;
| &amp;gt;20-30 [[VE]]s&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
These kernels are optimized for these types of hardware configurations and usage scenarios,&lt;br /&gt;
so choosing the right kernel can help to boost performance by about 5 to 15 per cent.&lt;br /&gt;
&lt;br /&gt;
{{Note|Use &amp;lt;tt&amp;gt;rpm -ihv&amp;lt;/tt&amp;gt; command for ovzkernel RPM installation. Please do not use the &amp;lt;tt&amp;gt;rpm -Uhv&amp;lt;/tt&amp;gt; command to install the kernel, otherwise all the previously installed kernels may be removed from your system.}}&lt;br /&gt;
&lt;br /&gt;
{{Note|When using a &amp;lt;b&amp;gt;64-bit&amp;lt;/b&amp;gt; processor &amp;lt;b&amp;gt;and&amp;lt;/b&amp;gt; operating system, you need only select the SMP or non-SMP version.  64-bit linux can access the entire 64Gb of ram in ZONE_NORMAL (low memory).  PAE and 4GB/4GB splitting are only needed for 32-bit OS, and so are not necessary and are disabled by default in 64-bit kernels.}}&lt;br /&gt;
&lt;br /&gt;
New RHEL5 based kernel uses different flavors naming. I.e. &lt;br /&gt;
* '''UP''' kernel is no longer provided &lt;br /&gt;
* '''SMP''' kernel comes without any flavor (like old UP)&lt;br /&gt;
* '''entnosplit''' kernel comes as '''PAE '''&lt;br /&gt;
* '''enterprise''' kernel comes as '''ent'''&lt;br /&gt;
&lt;br /&gt;
[[Category: Kernel]]&lt;br /&gt;
[[Category: Need Categorization]]&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Jobs&amp;diff=3338</id>
		<title>Jobs</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Jobs&amp;diff=3338"/>
		<updated>2007-07-19T07:06:26Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;OpenVZ project is seeking for people to work in our team.&lt;br /&gt;
&lt;br /&gt;
== Position: Linux Kernel Developer ==&lt;br /&gt;
&lt;br /&gt;
=== Position overview ===&lt;br /&gt;
We are seeking Linux Kernel Software Engineers, with experience&lt;br /&gt;
and skills described below and  willing to work in a professional&lt;br /&gt;
team on challenging open source projects. The ideal candidate&lt;br /&gt;
should be enthusiastic, team-oriented and motivated.&lt;br /&gt;
&lt;br /&gt;
You can work either in our Moscow, Russia office, or remotely.&lt;br /&gt;
&lt;br /&gt;
The office is situated in Dolgoprudniy in the building&lt;br /&gt;
of Moscow Institute of Physics and Technology (2 km from Moscow&lt;br /&gt;
and 15 mins from m. Altufievo). The company provides transport&lt;br /&gt;
from m. Rechnoy Vokzal and m. Altufievo.&lt;br /&gt;
&lt;br /&gt;
=== Major Responsibilities ===&lt;br /&gt;
* new Linux Kernel code (containers, file systems, scheduling, quota, networking etc.)&lt;br /&gt;
* porting of the existing code to new kernel version&lt;br /&gt;
* bug hunting and fixing&lt;br /&gt;
&lt;br /&gt;
=== Qualification &amp;amp; Requirements ===&lt;br /&gt;
* Strong C language skills (2+ years)&lt;br /&gt;
* Strong knowledge of computer science algorithms and&lt;br /&gt;
understanding of algorithm performance and complexity&lt;br /&gt;
* Linux kernel coding experience (memory management, file systems, networking, drivers and other components)&lt;br /&gt;
* Knowledge of IA-32 or other architectures and assembler language&lt;br /&gt;
* Technical English&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
* high salary&lt;br /&gt;
* medical insurance (in russia)&lt;br /&gt;
* free meals on site (in russia)&lt;br /&gt;
&lt;br /&gt;
=== Contacts ===&lt;br /&gt;
If you are interested, email &amp;lt;code&amp;gt;jobs/@/openvz/./org&amp;lt;/code&amp;gt; (remove slashes from the address).&lt;br /&gt;
&lt;br /&gt;
== Position: OpenVZ support engineer ==&lt;br /&gt;
&lt;br /&gt;
=== Position overview ===&lt;br /&gt;
We are seeking Linux Kernel Software Engineers, with experience&lt;br /&gt;
and skills described below and  willing to work in a professional&lt;br /&gt;
team on challenging open source projects. The ideal candidate&lt;br /&gt;
should be enthusiastic, team-oriented and motivated.&lt;br /&gt;
&lt;br /&gt;
You can work either in our Moscow, Russia office, or remotely.&lt;br /&gt;
&lt;br /&gt;
The office is situated in Dolgoprudniy in the building&lt;br /&gt;
of Moscow Institute of Physics and Technology (2 km from Moscow&lt;br /&gt;
and 15 mins from m. Altufievo). The company provides transport&lt;br /&gt;
from m. Rechnoy Vokzal and m. Altufievo.&lt;br /&gt;
&lt;br /&gt;
=== Major Responsibilities ===&lt;br /&gt;
* bug hunting and fixing&lt;br /&gt;
* support&lt;br /&gt;
&lt;br /&gt;
=== Qualification &amp;amp; Requirements ===&lt;br /&gt;
* Strong C language skills (2+ years)&lt;br /&gt;
* Technical English&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
* high salary&lt;br /&gt;
* medical insurance (in russia)&lt;br /&gt;
* free meals on site (in russia)&lt;br /&gt;
&lt;br /&gt;
=== Contacts ===&lt;br /&gt;
If you are interested, email &amp;lt;code&amp;gt;jobs/@/openvz/./org&amp;lt;/code&amp;gt; (remove slashes from the address).&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=Jobs&amp;diff=3337</id>
		<title>Jobs</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=Jobs&amp;diff=3337"/>
		<updated>2007-07-19T07:03:29Z</updated>

		<summary type="html">&lt;p&gt;Dev: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;OpenVZ project is seeking for people to work in our team.&lt;br /&gt;
&lt;br /&gt;
== Position: Linux Kernel Developer ==&lt;br /&gt;
&lt;br /&gt;
=== Position overview ===&lt;br /&gt;
We are seeking Linux Kernel Software Engineers, with experience&lt;br /&gt;
and skills described below and  willing to work in a professional&lt;br /&gt;
team on challenging open source projects. The ideal candidate&lt;br /&gt;
should be enthusiastic, team-oriented and motivated.&lt;br /&gt;
&lt;br /&gt;
You can work either in our Moscow, Russia office, or remotely.&lt;br /&gt;
&lt;br /&gt;
The office is situated in Dolgoprudniy in the building&lt;br /&gt;
of Moscow Institute of Physics and Technology (2 km from Moscow&lt;br /&gt;
and 15 mins from m. Altufievo). The company provides transport&lt;br /&gt;
from m. Rechnoy Vokzal and m. Altufievo.&lt;br /&gt;
&lt;br /&gt;
=== Major Responsibilities ===&lt;br /&gt;
* new Linux Kernel code (containers, file systems, scheduling, quota, networking etc.)&lt;br /&gt;
* porting of the existing code to new kernel version&lt;br /&gt;
* bug hunting and fixing&lt;br /&gt;
&lt;br /&gt;
=== Qualification &amp;amp; Requirements ===&lt;br /&gt;
* Strong C language skills (2+ years)&lt;br /&gt;
* Strong knowledge of computer science algorithms and&lt;br /&gt;
understanding of algorithm performance and complexity&lt;br /&gt;
* Linux kernel coding experience (memory management, file systems, networking, drivers and other components)&lt;br /&gt;
* Knowledge of IA-32 or other architectures and assembler language&lt;br /&gt;
* Technical English&lt;br /&gt;
&lt;br /&gt;
=== Benefits ===&lt;br /&gt;
* high salary&lt;br /&gt;
* medical insurance (in russia)&lt;br /&gt;
* free meals on site (in russia)&lt;br /&gt;
&lt;br /&gt;
=== Contacts ===&lt;br /&gt;
If you are interested, email &amp;lt;code&amp;gt;jobs/@/openvz/./org&amp;lt;/code&amp;gt; (remove slashes from the address).&lt;/div&gt;</summary>
		<author><name>Dev</name></author>
		
	</entry>
</feed>