Avant d’utiliser cette technologie avec un objectif de rationnalisation de mes serveurs de dev (restons très modeste je parle de ce qui me sert à developper quelque site perso dont celui-ci), j’ai essayé deux produits me semblant être les principaux outils concernant ma cible d’implémentation à savoir Linux : vmware, outil payant mais disponible en version communautaire et xen, outil totalement ouvert.

J’ai donc commencé par vmware et de dois avoué que c’est à peut pret aussi simple qu’une installation de logiciel classique : installation du RPM qui va bien, lancement de l’executable en temps que root … la compilation des package, la signature de je ne sais trop quoi … tout est automatique. C’est beau c’est pro. nickel !
L’installation d’une VM est assez simple : vmware lance un vrai machine completement virtuelle, avec son bios, ses périphériques virtuel qui ne sont autre que les vrai périphériques physiques de la machine après association faite lors de la configuration de la VM. Bref, il suffit de mettre un cd d’install dans le lecteur, démarrer la VM en cliquant sur le bouton et zou, on boot la VM sur le CD et l’installation débute. Trop facile !!
Une fois installé, le petit package de drivers pour le système hôte se déploie en un clic et optimise grandement la performance des périphériques souris et clavier.
Avantage de vmware, simulant une machine physique, il supporte n’importe quel systeme fonctionnant sur la même plateforme (voir une autre plateforme dans des conditions plus pro). Du coup il est possible de s’en servir pour l’installation de windows XP sous linux lorsque l’on en a une utilisation très ponctuelle comme par exemple vérifier la compatibilité d’un site avec IE ou flasher un périphérique USB pour lequel on a qu’une version windows du soft (c’est du vecu). Parceque oui, le petit plus c’est la possibilité en un click de connecter un element USB sur la VM ! solution très interressante qui ouvre de nombreuses nouvelles possibilités en terme de support de périphérique sur une VM.
Bien sure, il faut aussi regarder les performance de cet environnent virtuel, et de ce point de vue là, dans un cadre d’utilisation simple c’est vraiment correct : pour vous dire j’ai fait tourner un XP sous Linux avec en tache de fond un calcul distributed.net + un calcul BOINC et franchement, l’utilisation etait acceptable, le tout sur une machine à environ 1.5Gz. Les problèmes de performance apparaissent vraiment avec le manque de mémoire : à savoir que le disque est simulé, il s’agit en réalité d’un fichier, lui-même écrit sur un file-système géré par linux et mappé sur un disque physique. Lorsque le système virtuel vient à manquer de mémoire physique, celui-ci se met à swapper dans un fichier, lui-même ecrit dans le fichier décrit ci-dessus … bref, l’empilement d’IO virtuelles et réelles que l’on rencontre alors finit vite par venir à bout de n’importe quoi … et vous amenè par exemple à fermer windows en plus de 2h … beau score ! POur une utilisation plus proffessionnelle ou resemblant moins à des tests je ne peux que conseiller l’utilisation de partitions physique plutot que logique pour les VM.

C’est ainsi que j’ai ensuite décidé de faire quelque essais avec Xen, d’autant que ma suse préférée offrait cette possibilitée. Pour la petite histoire, j’ai tout d’abord essayer ça dans une VM sous vmware (lol).
Le principe de Xen est un peu différent, il ne s’agit pas d’une application hébergée par un système hôte qui va faire tourner des VM, mais d’une couche basse, située en dessous du noyau hôte et qui va permettre le partage des ressources matérielles. Donc en gros, au boot, on demarre une sorte de noyau Xen (l’hyperviseur) qui lui-même va démarrer un noyau principal, le domaine0 depuis lequel on va pouvoir lancer les machines secondaires.
Le noyau est compilé spécifiquement pour Xen avec une architecture eponyme. Xen ne fournit pas une machine vituel, au même sens que vmware qui vous fournit une sorte de PC version logiciel, il fournit un service de partage des ressources matérielle à plusieurs systèmes ce qui est assez différent, surtout dans le sens où il n’est pas possible d’installer avec Xen n’importe quelle VM, mais seulement des noyaux type linux, openbsd & co. Pas de Windows ici bas. L’installation d’une VM ne se fait d’ailleurs pas de le même façon que celle d’un système classique : ici pas de boot depuis le cd pour l’install … on se débrouille pour installer l’OS dans un file système (logique ou physique) puis on boot sur ce file system. Un peu moins user-friendly, mais après tout, la création de VM est-ce vraiment une fonctionnalité grand publique ?
Les performances sont plutot au rendez-vous, j’utilise une VM comme serveur de DEV avec tomcat, mysql & co, les temps de réponse sont les même que sur mon serveur précédent dont la conf était certe un peu inférieur mais sans que ce soit sensible. Grosso modo, je concidère que le fait que ce soit une VM est transparent avec Xen, pour l’instant. A noter qu’il est possible de gérer la priorité entre les différentes VM, solution utile si l’on souhaite partager le même hardware pour des serveur de DEV et PROD par exemple.

Pourquoi utiliser des VM me direz-vous ? hors mis pour se trouver dans le situation hubuesque mais présente : lorsque je boot mon serveur de dev la séquence est la suivante :

• Un bootloader sur disquette va chercher un booloader pxe sur un serveur tftp
• Celui-ci charge un bootloder plus perfectionné qui permet de booter un noyau Xen (multi-kernel)
• Ce dernier va ensuite chercher l’hyperviseur Xen
• Qui boot le noyau du domaine principal présent sur NFS
• Qui demarre enfin la VM, elle aussi présente sur un autre lien NFS

Pourquoi faire simple quand on peut faire compliqué ? et bien simplement pour détacher le matériel du logiciel !!! voila qui permet de se sortir en un clein d’oeil des problèmes de pannes, mais qui permet aussi de migrer de matériel sans avoir à faire de réinstallation fastidieuses.