Catégorie : Xen

La configuration réseau de Xen

Antoine 3 commentaires

J’ai déjà eu l’occasion d’évoquer la spécificité de la configuration réseau dans le cadre d’une plateforme de virtualisation dans un précédent billet. Je vais traiter ici des différentes configuration réseau possible avec Xen. Bien que cet article s’attachera aux modes présents dans Xen, vous pourrez sans aucun doute retrouver dans d’autres solutions de virtualisation. Si vous souhaitez un rappel de la terminologie Xen qui sera utilisé ici, je vous invite à relire l’article sur la terminologie.

Les trois modes de configuration réseau dans Xen sont : bridge, route et NAT. En Français, nous aurons donc pont, routage et NAT. Ces trois modes répondent à différents besoins en terme de configuration réseau. Le premier critère de choix du mode réseau est la topologie logique du réseau existant. Les éléments de topologie vont inclure les VLAN ainsi que les différents réseaux IP.

Le mode pont

RzoXen-Bridge

Le schéma ci-dessus explique le fonctionnement du mode pont. Il s’agit du mode le plus simple agissant au niveau le plus bas. Les domU sont connectés au dom0 via des interfaces réseau virtuels. Le dom0 ne fait qu’une simple commutation en redirigeant les trames soit vers le bon domaine soit vers le reste du réseau.

L’avantage de ce mode est l’extrême simplicité de la configuration qui permet une transparence par rapport au reste de l’architecture. La configuration des domU est également simple et ne nécessite aucune particularité. Il est possible de superposer n’importe quelle configuration IP en utilisant ce mode. Vous remarquerez que ce mode ne prend pas en compte les VLAN nativement. Nous verrons ultérieurement une possibilité de fonctionnement de ce mode avec la prise en compte des VLAN via 802.1Q.

Le mode routage

RzoXen-Route

Le schéma ci-dessus explique le fonctionnement du mode routage. Il s’agit d’un mode assez peu utilisé. La raison de la faible utilisation de ce mode est lié au fort lien entre topologie physique et topologique logique. Je m’explique. Avec cette configuration, il est pratiquement impossible de migrer des machines virtuelles entre des machines physiques sans modification de routage.

Ce mode est cependant très utile dans le cadre d’un serveur OVH doté d’IP supplémentaires. Ceci est du au fait qu’une bonne partie des serveurs OVH ne supportent pas le mode pont pour un raison inconnue.

Le mode NAT

RzoXen-NAT

Le mode NAT est une évolution du mode routage. Vous avez toujours deux plages d’IP différentes de part et d’autre du dom0 mais les IP des domU ne seront pas visibles sur le réseau public.

Par défaut, ce mode permet un accès au réseau public par les domU mais pas d’accès dans le sens inverse. Vous pourrez mettre en place des accès dans le sens inverse en utilisant iptables.

Installation de Xen sur Debian Lenny

Antoine 1 commentaire

Xen_logoJ’ai déjà eu l’occasion de parler de Xen à de multiples reprises sur ce blog. Je n’ai pas tellement eu l’occasion de proposer de tutoriels pratiques par rapport à cet outil. Je cède certes un peu à la facilité mais je pense que ce type de billet peut être utile.

Pour ce tutoriel, je vais supposer que vous avez une installation neuve de Debian Lenny. Lorsque j’ai testé ce tutoriel, j’ai effectué cette installation sur un serveur dédié OVH. Je vais également supposer que vous êtes en 64-bits. Si vous ne l’êtes pas, il va juste falloir adapter le nom des paquets à votre version. On va tout d’abord installer les paquets liés à Xen et au réseau.

apt-get install xen-hypervisor-3.2-1-amd64 xen-linux-system-2.6.26-1-xen-amd64 xen-utils-3.2-1 xenstore-utils xenwatch xen-shell xen-tools

Vous ne devriez pas avoir d’erreurs lors de l’installation de ces paquets. Si c’est le cas, je vous laisse vous documenter sur Internet afin de résoudre ces messages d’erreurs. Il y a peu de chance que l’installation fonctionne si vous avez des messages d’erreur, c’est donc le moment de les résoudre.

Nous allons ensuite augmenter le nombre de devices de « loopback ». Ces devices servent à monter les systèmes des fichier des domU (machines virtuelles). IL va donc falloir dire au module loop qu’il est nécessaire d’accepter plus de devices de « loopback ». Nous allons donc devoir rajouter la ligne suivante dans le fichier /etc/modules :

loop max_loop=64

L’installation de Xen à proprement dit est finie. Vous allez devoir vérifier que Grub est bien installé car Xen ne fonctionne pas avec LILO. OVH installe LILO par défaut, vous devez donc faire l’installation de Grub. Je vous laisse remplacer sda par votre disque dur de démarrage.

apt-get install grub

grub-install /dev/sda

update-grub

Vérifiez ensuite le contenu de /boot/grub/menu.lst afin de vous assurer que Xen est bien présent. Vous pouvez ensuite redémarrer votre machine qui devrait booter sur Xen. Si vous n’avez pas eu d’erreur jusqu’ici, tout devrait se passer correctement. Si ce n’est pas le cas, je vous invite à parcourir la mailing-liste de Xen afin de trouver la correspondance de ces erreurs. Pour vérifier que vous êtes bien sur Xen, vous pouvez exécuter uname -r qui vous donnera un noyau Xen si tout est bon.

Voici un rapide aperçu du fonctionnement de l’installation de Xen sur une Debian Lenny. J’évoquerais ultérieurement la configuration réseau et les outils de management.

Terminologie Xen

Antoine 1 commentaire

Xen_logoAprès une longue série d’articles plutôt théoriques sur la virtualisation (Anneaux système et  Popek & Goldberg), je vais revenir sur le projet Xen afin de pouvoir toucher un public plus large. J’ai déjà eu l’occasion de faire un article sur le projet Xen. Si vous souhaitez avoir un aperçu de ce projet, je vous invite à relire l’article en question.

Par le biais de ce billet, je souhaite faire un point sur tous les termes qui sont utilisés très fréquemment lorsque nous sommes amenés à parler du projet Xen. J’ai essayé de faire une première liste. Si jamais vous en voyez d’autre, n’hésitez pas à me le faire remarquer et je les rajouterais ici.

Domaine – Un domaine est une machine virtuelle. Le projet Xen a choisi de s’affranchir de la notion de machine virtuelle car cela avait tendance à renvoyer vers les techniques conventionnelles de virtualisation totale.

  • Domaine privilégié ou dom0 : Le domaine 0 qui correspond au système d’exploitation installé initialement sur le matériel physique. Ce domaine dispose de tous les outils pour gérer les paramètres de l’hyperviseur et l’état des autres domaines
  • Domaine non privilégié ou domU : Il s’agit d’un domaine standard qui correspond à la définition conventionnelle de la machine virtuelle mais transposée dans le monde de la paravirtualisation.

Hyperviseur – L’hyperviseur est la première interface entre le matériel et les couches applicatives. Il n’est pas positionné par dessus un système d’exploitation hôte. VMWare utilise le terme d’hyperviseur alors qu’il s’agit d’une application inclue dans un système d’exploitation hôte. Je n’utiliserais que la définition de l’hyperviseur au sens de Xen sur ce blog.

PV – Il s’agit là de l’abréviation de paravirtualisation. Il sera souvent évoqué la notion de « domaine PV » ce qui correspond à un domaine interfacé avec l’hyperviseur via l’API Xen.

HVM (Hardware Virtual Machine) – Le HVM est l’appellation de la virtualisation matérielle assistée dans le projet Xen. Le projet Xen est donc capable de faire de la paravirtualisation et de la virtualisation matérielle assistée. Typiquement, le HVM permet d’exécuter des domaines Windows. Le module de virtualisation matérielle assistée est une version modifiée de QEMU.

VIF (Virtual Interface) – Une VIF est une interface réseau virtuelle par opposition aux interfaces réseau physiques. Ces interfaces servent à mettre à disposition une interface réseau aux domaines. Les interfaces virtuelles seront ensuite reliées par divers méthodes (Pont, NAT, Routage) aux interfaces physiques.

XM (Xen Management) – Xen Management est le jeu d’outils qui permettent de passer des commandes à l’hyperviseur au niveau du dom0. Il permet notamment d’exécuter, de mettre en pause et de couper les différents domaines présents sur la machine. Pour plus d’informations, n’hésitez pas à saisir la commande « xm help ».

GPLPV – Les drivers GPLPV sont les drivers qui permettent d’ajouter des extensions de paravirtualisation à des domaines HVM. L’objectif de ces drivers est d’améliorer les performances des domaines HVM. Les drivers GPLPV sont comparables aux VMWare Tools.

Au final, je pense avoir fait un petit tour des termes les plus utilisés dans les ressources évoquant le projet Xen. J’espère que ce billet permettra à quelques personnes de mieux comprendre le projet Xen et de, pourquoi pas, se lancer dans une installation.

La paravirtualisation

Antoine 7 commentaires

tech-presentation-2Je vais continuer et finir la série d’articles présentant les différents types de virtualisation. J’ai déjà eu l’occasion de proposer une classification des différents types de virtualisation et de parler de la virtualisation totale ainsi que de la virtualisation matérielle assistée. Je vais continuer en vous parlant de paravirtualisation. J’ai déjà eu l’occasion d’évoquer la notion de paravirtualisation dans la présentation de Xen que j’avais faite il y a quelques temps.

L’idée de base des précédents types de virtualisation était de faire croire au système d’exploitation qu’il s’exécutait sur une machine physique alors que ce n’était pas le cas. Cette technique est la technique la plus évidente lorsqu’on essaye de virtualiser des systèmes d’exploitation principalement propriétaires ce qui est le cas de VMWare par exemple. Il s’agit d’une méthode qui permet de centraliser toutes les fonctionnalités de virtualisation dans un seul endroit, à savoir la couche de virtualisation. L’inconvénient de cette méthode est que la couche de virtualisation devient rapidement très lourde avec la quantité croissante du nombre de fonctionnalités à implémenter.

La paravirtualisation adopte une vision radicalement différente. Au lieu de chercher à faire croire aux systèmes d’exploitation qu’ils s’exécutent sur une machine physique, il est possible d’adapter le système d’exploitation à la couche de virtualisation. Ceci n’aurait bien évidemment pas été possible sans la présence de logiciels libres…

virtus

La paravirtualisation vise donc à modifier les systèmes d’exploitation pour communiquer avec un hyperviseur au lieu de communiquer avec une machine physique. Sur ce blog, je parlerais d’hyperviseur au sens de Xen ou d’Hyper-V. VMWare parle d’hyperviseur à tord et à travers mais il ne s’agit pas, selon moi, d’un vrai hyperviseur. En réalité, il s’agit d’un système d’exploitation hôte déguisé.

L’hyperviseur au sens de la paravirtualisation est en contact direct avec le matériel physique. Il est l’intermédiaire exclusif entre le matériel et les systèmes d’exploitation. Lorsqu’on se trouve donc dans un système de paravirtualisation, il n’y a plus de notion de système d’exploitation invité et de système d’exploitation hôte. Tous les systèmes d’exploitation sont virtualisés dans le sens où ils disposent d’un noyau adaptés à la couche de virtualisation. Tous les systèmes d’exploitation ne seront pas égaux pour autant, il est possible de donner des accès spécifiques à différents systèmes d’exploitation.

Les systèmes d’exploitation communiquent avec l’hyperviseur via des API de communication. Ces API de communication remplacent les traditionnels appels systèmes. Chaque couche de virtualisation dispose donc de sa propre API. Pour adapter un système d’exploitation à un hyperviseur, il faut donc intégrer son API au noyau. Cela explique en partie le passage en GPL des pilotes Hyper-V de Microsoft.

Au final, la paravirtualisation est une technique particulièrement innovante qui présente une approche plus efficace de la virtualisation. Les avantages de cette technique sont une perte de performance largement réduite par rapport à une virtualisation totale. L’inconvénient majeur est qu’il est nécessaire d’adapter les systèmes d’exploitation pour chaque couche de virtualisation. Afin de résoudre ce problème, il est possible de coupler paravirtualisation et virtualisation matérielle assistée comme dans Xen.

Les livres pour comprendre Xen 2

Antoine

Voici le second opus des livres permettrant de mieux comprendre Xen. Alors que le premier livre était un plutôt un guide d’installation et de configuration de Xen, ce livre a pour but d’être une présentation en profondeur de Xen permettant un compréhension approfondie de son fonctionnement.

The Definitive Guide to the Xen Hypervisor

DefinitiveGuideXenHyp

Ce livre a pour objectif d’être la bible des développeurs de Xen et de former les futurs développeurs. Cependant, ce livre peut être abordé à plusieurs niveaux : un niveau développeur et un niveau administration système. C’est le deuxième niveau que m’avait conduit à m’intéresser à ce livre.

Ce livre contentera les développeurs dans la mesure où il part d’un point de vue global pour aller jusqu’à une analyse très approfondie du fonctionnement de Xen avec des exemples de fonctions en C et l’explication de leur fonctionnement.  N’étant pas développeur et n’ayant que très peu de compétences en programmation, il m’est assez difficile de commenter ce niveau de compréhension.

Ce livre contentera également les administrateurs système. La totalité de son contenu n’est pas forcément accessible à ces derniers surtout s’ils n’ont pas fait beaucoup de programmation auparavant. Cependant, une grande partie l’est tout de même. Un effort de compréhension conséquent est nécessaire pour réussir à assimilier les connaissances correctement. Une fois cet effort de compréhension effectué, le niveau de connaissance du lecteur sera largement supérieur à une personne qui a lu le livre précédent. Ceci donnera à la personne les connaissances permettant de résoudre bon nombres de problématiques liés à Xen qui dépassent la simple erreur de configuration.

Ce livre est cependant complémentaire au précédent. La lecture de ce livre ne suffit pas pour obtenir la configuration d’un serveur Xen et des domaines associés. Pour bien connaitre Xen, la lecture de ces deux livres est donc fortement intéressante. Ce livre peut servir de « suite » permettant d’approfondir au premier livre qui permet de faire une première mise en place.

TX : Etude de la virtualisation : Réseau et Cloisonnement

Antoine

Suite à l’AC que j’ai effectué au semestre d’Automne avec Romain Hinfray, j’ai voulu aller plus loin dans l’étude de la virtualisation. Ceci s’explique principalement par le fait que nous n’avions pas du tout utilisé Xen dans le cadre de l’AC. C’est donc sous la forme d’une TX (sorte de TPE) que j’ai continué l’étude de la virtualisation. Cette TX s’est faite avec Julie Facon.

Nous avons voulu prolonger l’AC en y injectant du pratique. Les deux points qui étaient restés le plus en suspens après l’AC étaient l’intégration de la virtualisation dans une infrastructure réseau conventionnelle et la gestion du cloisonnement des performances. Le powerpoint est disponible ci-dessous via slideshare.net et le rapport est téléchargeable ici.

Etude de la virtualisation : Réseau & Cloisonnement

Je vais tout de même vous résumer ici les deux études afin de, potentiellement, vous donner envie d’en lire plus. L’étude sur le réseau a tout d’abord inclus l’installation de l’outil Xen ainsi que de l’outil de gestion de machines virtuelles ConVirt. L’installation détaillée est une installation par le biais des paquets Debian mais ce que nous avons utilisé dans le cadre de notre TX est l’installation par les sources. Cette dernière est la seule qui permet d’utiliser une version de Xen à jour. Nous avons ensuite exploré les différents modes de réseau de Xen, à savoir, pont, routeur et NAT. Nous avons étendu l’étude vers l’utilisation des VLAN via le biais du protocole 802.1Q. La conclusion de cette étude est que le mode pont est de loin le mode le plus simple et que le mode NAT permet d’introduire des fonctionnalités tout à fait intéressantes. Le mode routeur n’est cependant pas fonctionnel et est d’une utilité fortement réduite. Ce qu’il faut noter également, c’est que le réseau sous Xen dépend totalement de la gestion du réseau sous Linux.

Ensuite, la seconde partie est donc la partie sur le cloisonnement de performances. L’objectif de cette partie était de montrer l’intérêt de la virtualisation par rapport à une plateforme classique. Nous avons donc simulé une montée en charge de différents services et mesurer l’impact sur les autres services. Nous avons utilisé l’outil Apache Bench pour implémenter une montée en charge modérée et l’Isolation Benchmark Suite pour implémenter une très forte montée en charge. Nous avons pu constaté l’agilité avec laquelle la virtualisation arrivé à gérer une montée en charge tout en assurant une qualité de service aux machines virtuelles qui ne demande que peu de ressources. Ceci n’est bien entendu absolument pas du tout le cas d’une plateforme non virtualisée. La virtualisation est une solution efficace pour assurer un cloisonnement en termes de performances.