**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
# Howto OpenVZ
OpenVZ permet de compartimenter les processus au sein de conteneurs. Ce n'est pas vraiment de la virtualisation car un seul et même noyau est utilisé par tous les conteneurs.
Cependant un VE (Virtual Environment) ne peut voir que ses processus (un init avec un PID=1 est recréé pour chaque VE, ce qui ne perturbe pas le schéma standard des processus dans le VE).
Le principe de conteneur permet d'obtenir de meilleures performances (un seul noyau chargé en mémoire, accès aux périphériques plus rapide (moins de couches logicielles à traverser))
et de modifier les ressources matérielles allouées à chaud.
Cependant, tous les systèmes virtualisés partagerons la même version du noyau et les mêmes modules.
Il ne peut donc y avoir un système Debian et un FreeBSD sur la même machine physique par exemple.
## Configuration du système hôte (VE0)
Au niveau du partitionement, il peut être utile de créer une partition contenant tous les VE, à monter dans _/var/lib/vz/_, étant donné que les fichiers des VE sont des _vrais fichiers_ pour le système de fichiers hôte (contrairement à d'autres solutions de virtualisation où les fichiers sont dans une image).
Ensuite, on installe le noyau Linux avec le support d'OpenVZ (ne pas oublier de rebooter dessus après l'install avant de continuer) :
Il faut avant tous posséder un template du système à installer. On peut les trouver [ici](http://download.openvz.org/contrib/template/precreated/). Un template se présente sous la forme d'une archive contenant le système de fichier du système à installer. Elle doit être placée (non décompressée) dans _/var/lib/vz/template/cache/_.
Ensuite on peut créer un nouveau VE en utilisant ce template :
_1_ représente l'id du VE. l'id 0 est réservé au système hôte. l'ostemplate doit correspondre au nom du template sans l'extension. ipadd permet de spécifier l'adresse IP du VE.
On peut également définir une configuration à l'aide de `vzctl set`, par exemple :
L'option _online_ permet de minimiser le temps indisponibilité du VE (il est en pratique de quelques secondes).
Cette méthode a plusieurs limitations, qui peuvent être gênantes dans certains cas :
* Impossibilité de renommé l'ID du VE pendant la migration. Si un VE possède déjà le même ID sur la machine cible, la migration échouera ;
* Impossibilité de changer les paramètres réseau (IP, passerelle, DNS...). Si la machine cible se trouve dans un autre réseau, ou bien l'IP du VE est déjà prise, la migration échouera.
Enfin, il faut s'assurer également que les limitations matérielles (quota mémoire, disque...) sont cohérentes avec l'environnement cible.
## Créer et restaurer une snapshot d'un VE
Un snapshot consister à freeze tous les processus et sauvegarder toutes les informations d'état, puis créer une image du VE.
L'image pourra ensuite être restaurer pour que tous les processus se retrouvent exactement dans le même état au moment du freeze.
Dans cet exemple, si tous les VE ont besoins du CPU en même temps, OpenVZ accordera 2 fois plus de temps CPU au VE 2. L'avantage de cette méthode est que si le VE 2 n'utilise pas le CPU, le VE 1 peut prendre jusqu'à 100% du temps CPU. Ainsi, il n'y a pas de ressources inutilisées inutilement.
}}}
### Les paramètres UBC
Les UBC (Users BeanCounters) permettent de régler plus finement l'utilisation des ressources par VE. En général (ce n'est pas le cas de tous les paramètres), il faut définir une valeur barrière (limite soft) et une valeur limite (limite hard), dans le même esprit que les quotas Linux.
La liste des UBC peut se trouver [ici](http://wiki.openvz.org/UBC_parameters_table)
## OpenVZ via Proxmox
sources.list :
~~~
deb <http://download.proxmox.com/debian> wheezy pve-no-subscription