# [Virtualisation] après xen, qemu et vmware voici openvz

## zyprexa

Bonjour

Ceci est mon premier howto (constitué en grande partie grâce au wiki du site officiel)

Encore une solution de virtualisation me direz-vous ? Et oui, mais celle-ci a ma préférence par rapport à xen et qemu car elle ne brise pas la compatibilité avec les drivers nvidia propriétaires (non ya pas que ca).

C'est une solution de paravirtualisation mais qui peut seulement faire tourner linux sur linux. OpenVZ constitue le pendant open-source des solutions commerciales Virtuozzo utilisées par OVH et Amen.

Cette solution se constitue d'une série de patchs kernel ainsi que d'outils de contrôle en ligne de commande tous disponibles dans portage.

QUALITES

- extrême légèreté, il est possible d'en lancer un sacré paquet ... (1-2% de cpu / VE)

- flexibilité : on part d'un template et on peut générer des dizaines d'environnement debian, gentoo, ubuntu (celui que vous préférer torturer :p). Il est également possible de créer un template soi-même.

- fixer des quotas, autant que pour l'utilisation du cpu que pour la consommation de ram est facile

- compatibilité avec les drivers propriétaires nvidia !

- la dernière version en date devrait apporter la virtualisation de nfs (vais tester ca après reboot)

INSTALLATION

Pour commencer, on démasque et on installe les sources :

```
echo "sys-kernel/openvz-sources ~x86" >> /etc/portage/package.keywords && emerge openvz-sources
```

Ainsi que les outils de contrôle :

```
echo "sys-cluster/vzctl ~x86" >> /etc/portage/package.keywords && emerge vzctl
```

Cf config & install kernel classique. Un sous-menu openvz a été ajouté, je n'ai rien trouvé de véritablement inutile ... j'ai donc décidé de tout mettre.

```
#

# OpenVZ

#

CONFIG_VE=y

CONFIG_VE_CALLS=m

CONFIG_VZ_GENCALLS=y

CONFIG_VE_NETDEV=m

CONFIG_VE_ETHDEV=m

CONFIG_VZ_DEV=m

CONFIG_VE_IPTABLES=y

CONFIG_VZ_WDOG=m

CONFIG_VZ_CHECKPOINT=m
```

Il y en a qui se sont cachées dans les systèmes de fichiers là :

```
#

# File systems

#

CONFIG_VZ_QUOTA=m

CONFIG_VZ_QUOTA_UNLOAD=y

CONFIG_VZ_QUOTA_UGID=y
```

Celle-ci est requise afin permettre de fixer des quotas cpu :

```
#

# Processor type and features

#

CONFIG_SCHED_VCPU=y
```

Puis comme à l'accoutumée, on adapte le symlink, on copie le noyau et on met grub à jour.

INITIALISATION

On reboote, puis on commence par lancer ceci :

```
/etc/init.d/vz start
```

Ceci prépare l'environnement de la machine hôte (également appelée Hardware Node ou HN), nous pouvons donc passer aux environnement virtuels (ou VE).

Les templates de ceux-ci sont stockés dans le répertoire /vz/template/cache/, après installation celui-ci est vide. Vous pouvez soit en récupérer un, soit en créer un vous-même ... suffit juste de choisir, la procédure est très bien expliquée ici : http://wiki.openvz.org/Category:Templates.

Etape suivante : nous allons créer le premier VE, ceci se fait grâce à la commande vzctl (la page de man est très instructive).

```
vzctl create 101 --ostemplate debian --ipadd 192.168.1.101 --hostname deb101 
```

(il me semblent qu'ils conseillaient d'utiliser que des veid >100 ... je ne pourrais plus dire pourquoi, en tout cas le n°1 est réservé car désigne le HN).

Grâce à cette ligne, nous lui demandons de créer un VE debian en lui attribuant l'identifiant 101, le reste est suffisamment parlant pour se passer d'explications  :Smile: .

GESTION

A partir de là, lancer et stopper ce VE est aussi simple que d'utiliser un init-script :

```
vzctl start 101

vzctl stop 101

vzctl restart 101
```

Assis debout couché ... je vous passe les détails on y prend goût très vite.

Une fois lancé, un simple :

```
vzctl enter 101
```

et on se retrouve dans le VE.

Il faut savoir que si l'on n'attribue pas d'ip au moment de la création, le VE n'en aura pas. Il est toujours possible d'en ajouter une en faisant ainsi :

```
vzctl set 101 --ipadd 192.168.1.101 --save 
```

(sans le --save, l'ip disparaît au redémarrage du VE)

Ceci n'est qu'un exemple, il est également possible d'ajouter d'autres ip, de créer des interfaces ethernet virtuelles, d'en supprimer, de changer le hostname ... bref tout ce qu'il faut pour faire la pluie et le beau temps là-dedans  :Smile: . Il est intéressant de noter que ces paramètres sont enregistrés ici (pour notre VE) : /etc/vz/conf/101.conf.

CONCLUSION

Ce système m'a très vite plus par rapport à xen et à qemu, le lancement et l'arrêt des VE étant très rapide. Ca m'a permis de renforcer mes connaissances en réseau (tunnels, ppp, bridge toussa ....), et j'en ai également profité pour isoler mon client p2p par cette technique mais ca c'est une autre histoire (paranoia inside).

Après, il ne vous reste plus qu'à jouer avec sysctl, iptables, iproute et tout le binz.

----------

## CourJuS

Glorifion zyprexa !!!!!!!!! 

yapaphoto j'test ILICO quand je rentre du boulo ... 

Grand merci pour se tuto qui m'a l'aire facil et pratique

[edit]

Voila testé et adopté je dit "Bravo" 

rm -rf /opt/vmware* hahahaha

[/edit]

----------

## truc

ahah, c'est pile ce qu'il me faut, et ça coutera moins cher que d'acheter tout plein de pc, tout ça pour faire des tests  :Smile: 

----------

## CourJuS

Juste une petite sugjestion qui pourait à mon avis, évité des problèmes à des débutants en réseau. 

Remplacer la ligne suivant du fichier /etc/sysctl.conf pour que le réseau soie disponible après chaque reboot

```
#net.ipv4.ip_forward = 0
```

par

```
net.ipv4.ip_forward = 1
```

et pour seux qui l'ont ouvlié pour pas rebooter ...  :Smile: 

```
echo "1" > /proc/sys/net/ipv4/ip_forward
```

Pour résumer ça vous permet de pouvoir acceder au réseau via une interface physique sur votre réseau locale.

Bonne amusement.

----------

## VisualStation

Mince il faut pour le moment le kernel 2.6.18  :Sad: 

Je suis en 2.6.19 :$

----------

## truc

 *VisualStation wrote:*   

> Mince il faut pour le moment le kernel 2.6.18 
> 
> Je suis en 2.6.19 :$

 

toutes façon il faut changer de noyau quoiqu'il arrive, donc à la limite, ça n'est génant que si tu as un réel besoin d'une fonctionnalité présente dans le 2.6.19 et pas dans le 2.6.18

----------

## VisualStation

 *truc wrote:*   

>  *VisualStation wrote:*   Mince il faut pour le moment le kernel 2.6.18 
> 
> Je suis en 2.6.19 :$ 
> 
> toutes façon il faut changer de noyau quoiqu'il arrive, donc à la limite, ça n'est génant que si tu as un réel besoin d'une fonctionnalité présente dans le 2.6.19 et pas dans le 2.6.18

 

Pas sur mon pc fixe mais j'aurais aussi voulu le mettre sur mon portable et la version 2.6.19 apporte d'énormes changements pour le sata :$, mon frame buffer ne plante plus, et surtout je peux enfin me passer de tout ce qui est ide avec la 19.

Mais je viens de refaire le kernel, car j'ai pensé comme toi que pour le moment le 2.6.19 pour mon fixe n'était pas utile.

En tout cas, c'est une excellent moyen de virtualisation ! Qui me permet de ne pas devoir "salir" mon installation de gentoo avec Oracle.

Je peux ainsi lancer facilement la machine virtuelle avec Ubuntu+Oracle quand j'en ai besoin et facilement l'éteindre ... Plus pratique que vmware pour ca  :Smile: 

----------

## truc

salut, y'en a t'il qui ont essayé le dernier noyau dans l'arbre? 2.6.18-openvz-015 ? j'peux faire tout comme avec le -010, sauf que je ne peux pas entrer dans les VE :/, j'me suis peut-être chié sur la .config ? d'autres ont eu les même choses?

Sinon, question:

Quand on switch d'un noyau à l'autre (des noyaux déjà installé) c'est normal de devoir à chaque fois refaire le symlink /usr/src/linux, puis de devoir réinstaller nvidia-drivers? car c'est vite ennervant, et je ne me souviens pas que c'était le cas avant :/

(/lib/modules/2.6.XX/video/nvideo.ko est effacé quand je réinstall les drivers nvidia avec un autre noyau 2.6.XX , ça vous fait ça aussi? avec emerge? paludis? )

----------

## kwenspc

Loin de moi de vouloir critiquer OpenVZ que je n'ai pas (encore) testé.

Ceci dit je voudrais savoir quels sont vraiment les avantages par rapport à Xen? 

Car là la différence au niveau temps de mis en place, complexité de mise me semble complètement kif-kif.  :Neutral: 

Il faut un noyau pour la base (appellé dom0 en xen), on peut faire des templates pour les machines virtuelles etc...

(ah si petit détail: les machine virtuelle n'ont pas beoins de noyau spécifique pour tourner sur OpenVZ?)

Sinon dire que c'est mieux que qemu, non. En fait c'est pas comparable: qemu fait de l'émulation pure, le module kqemu permet une virtualisation limitée afin de gagner en performance lors de l'émulation et ce sur (et pour) cpu x86 uniquement. L'interêt de qemu n'est pas du tout le même qu'on peut avoir avec Xen ou OpenVZ. Par exemple j'utilise principalement qemu pour émuler l'arm (là kemu sert à rien) où dans certains cas particulier afin de débugger très précisement (dans l'osdev par exemple, qemu ouvre un accès serveur gdb très pratique), bochs permet la même chose mais qemu est nettement plus rapide. Xen et OpenVZ ne visent pas du tout cette utilisation.

Allez, dites moi tout sur OpenVZ, afin que je sache pourquoi je vais l'utiliser et laisser tomber Xen  :Smile: 

----------

## truc

salut, je ne vais pas pouvoir dire grand chose étant donné que je n'ai utilisé que openvz jusque là.. je peux cependant dire ce qui m'a plu:)

Tout d'abord, au cas où tu ne l'avais pas vu sur le site, voici un descriptif très bref des différentes technologies : http://wiki.openvz.org/Introduction_to_virtualization

Ensuite, bon voila dans le désordre, ce que j'aime bien, (gardé bien en tête que je n'ai essayé que ça, donc ça existe très probablement ailleurs..)

* Bon, les templates préfaits, c'est bien pratique, j'me sentais pas le courage d'en faire moi même toutes façons  :Smile: 

* Je n'ai réalisé que en bootant, l'intéret de la compatibilité du noyau openvz avec les drivers nvidia, => bah oui c'est mon pc de bureau, donc pas besoin de rebooter sur un autre noyau si je veux me faire un quake..   :Wink: 

* franchement, niveau performance je n'ai rien à dire, j'peux oublié que j'ai des ve de lancés, et faire mes trucs sans y penser, ça ne prends vraiment rien..

* les "interfaces" vzctl & Cie sont vraiment bien pratiques, on se fait très facilement des scripts pour démarer tout ce qu'on veut, c'est très pratique.

Voila désolé, je ne peux pas en dire plus...

sam.

----------

## Bapt

Suite à ce howto, j'ai mené dans la société (grosse structure) pour laquelle je travaille en ce moment une étude pour la virtualisation de leur serveurs linux dans laquelle j'ai proposé openvz. Solution qui a été retenue.

Avantage pour la structure en question : 

Il n'y a quasiment pas de perte de performance entre les VE et le serveur hôte.

Nous avons défini de multiples templates (multiples configurations possibles) correspondant à des serveurs types.

En 10 minutes nous pouvons avoir une nouvelle VE fonctionnelle selon un modèle donné (serveur de développement, serveur d'intégration, serveur de recette). Ce qui dans le cadre de développement/recette d'application est excellentissime. Une nouvelle application à recetter : création d'un nouveau VE, installation des composant, la recette se fait dans un environnement neuf et propre.

La gestion des droits d'accès aux matériels/ressources de la machines permet de gérer au mieux les ressources qui sont disponibles : limitation de l'accès CPU, priorité d'accès aux ressources par les VE, permettant ainsi de faire des traitements lourds sur certaines VE sans pour autant pénaliser les autres VE.

En gros sur chaque serveur (10) actuellement utilisé pour la phase de test : 5 VE tournent continuellement avec de l'Oracle et des applications métiers, et ça ne pose aucun problèmes. Les serveurs sont quand même de belle machines : (bi Xeon MP (double core) avec 4Go de RAM)

concernant le réseau c'est encore une fois que du bonheur. un gros bridge qui prends les nouvelles interfaces réseaux dynamiquement au démarrage des VE et tout le monde à accès au réseau avec sa propre IP.

Seul point noir : pas de gentoo ici, que du rhel  :Smile: .

----------

## truc

ça me fait penser qu'il me semble que virtuozo (donc openvz découle) est quand même une solution bien connue et reconnue dans le monde professionnel.

Sinon, bapt, simple curiosité, pourquoi utiliser les interfaces veth? Un besoin par rapport à certains des applicatins qui tournent et qui ont besoin des broadcasts arp? c'est une question gratuite hein?  :Wink:  (personnellement j'm'amuse bien plus avec les interfaces veth que les interfaces venet..)

----------

## Bapt

 *truc wrote:*   

> Sinon, bapt, simple curiosité, pourquoi utiliser les interfaces veth? Un besoin par rapport à certains des applicatins qui tournent et qui ont besoin des broadcasts arp? c'est une question gratuite hein?  (personnellement j'm'amuse bien plus avec les interfaces veth que les interfaces venet..)

 

J'ai besoin que mes utilisateurs ne fassent pas la différence entre les VE et les "vrais serveurs" donc tous mes VE ont une adresse IP sur mon réseau, donc j'utilise un gros bridge donc pas de venet possible. Tout simplement.

----------

## truc

eh bien normalement, avec les interfaces venet ça devrait être également possible, à moins que tu veuilles que tes serveurs optionnent une adresse par dhcp, il suffit (corriges moi bien sûr si je me trompe) de mettre l'adresse IP de l'interface venet du VE sur la même plage d'adresse que l'HN, en tout cas, chémoua ça marche, mon routeur materiel ping les VE  qui sont dans le même sous réseau(bon biensûr il faut activer l'ip_forward)

----------

## truc

 *truc wrote:*   

> salut, y'en a t'il qui ont essayé le dernier noyau dans l'arbre? 2.6.18-openvz-015 ? j'peux faire tout comme avec le -010, sauf que je ne peux pas entrer dans les VE :/, j'me suis peut-être chié sur la .config ? d'autres ont eu les même choses?

 

eh bien , y'avait bel et bien un petit souci avec ce noyau, les devs sont très sympas/réactifs que ce soit sur le forum ou bugzilla, ça fait plaisir  :Smile: 

Donc pour ceux qui veulent utiliser ce noyau avec "preemption", vous trouverez le patch kivabien ici  :Smile: 

----------

