La configuration réseau de Xen

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

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.

Blog Orange Business Services Virtualisation (MàJ)

EDIT : Mon article a été publié ce matin. Vous pouvez le consulter en cliquant ici.

orange_logo

Je n’ai pas pour habitude de faire la publicité d’autres blogs mais je vais faire une exception dans ce billet. Je vais également faire une exception car ce billet sera plus court que les autres n’ayant pas matière à développer infiniment sur ce sujet.

Tout d’abord, je suis actuellement en stage dans la filiale virtualisation du groupe Orange Business Services. Si vous voyez donc dans ce billet une publicité déguisée, vous voyez donc juste.

Ensuite, on m’a proposé de reprendre des billets extraits de ce blog sur le blog virtualisation d’Orange Business Services. Vous vous doutez bien que j’ai bien évidemment accepté. Vous allez donc pouvoir retrouver certains articles de ce blog légèrement remixés sur le blog Orange Business Services Virtualisation que vous pourrez consulter ici. Les modifications se situent essentiellement au niveau de la mise en forme car le contexte n’est pas tout à fait le même.

Mon premier article sur ce blog sera donc une reprise du premier article sur la théorie de Popek et Goldberg. La publication est prévue pour le Vendredi 9 Octobre dans la matinée. Pour la suite des événements, je continuerais sans aucun doute à poster des billets ne traitant pas de la virtualisation sur ce blog. Les billets traitant de la virtualisation seront surement postés sur chaque blog.

Je vous invite à consulter ce blog qui a l’occasion de traiter de nombreux sujets liés à la virtualisation et surtout aux produits de virtualisation d’application Citrix ainsi qu’à l’apport de la virtualisation par rapport à la pandémie.

Aller plus loin que Linux : Solaris

Je vais commencer une nouvelle série de billets sur un système d’exploitation alternatif à Linux. Je ne parlerais pas ici de Windows car mes compétences dans ce système d’exploitation sont fortement limités. Je vais parler de Solaris édité par Sun Microsystems. Je m’attacherais dans un premier temps à faire un tour d’horizon des éléments qui rendent intéressant ce système d’exploitation.

solaris-logo

La plupart de mon expérience en administration système s’est faite autour de la distribution Linux Debian. Debian est une distribution qui je trouve particulièrement simple à utiliser. Les développeurs de cette distribution ont pris un soin particulier de simplifier les différentes taches d’administration système. Ceci passe par une gestion claire et simplifiée des répertoires systèmes mais surtout par un gestionnaire de paquets apt-get. J’ai également eu l’occasion d’utiliser CentOS et Red Hat qui sont pratiquement identiques. L’environnement de cette distribution est également largement simplifié avec une gestion simplifiée des répertoires systèmes et divers utilitaires visant à simplifier l’administration système. Je ne pourrais pas dire que le gestionnaire de paquets inclus dans ces distributions simplifie réellement la vie car je n’ai jamais réussi à le faire marcher correctement.

Un inconvénient fréquemment évoqué par rapport à ces distributions est le fait qu’il est plus difficile de comprendre le mécanisme de fonctionnement du système d’exploitation. Ceci est lié à la simplification des taches d’administration et n’est pas forcément un inconvénient a priori. Cette simplification devient problématique lorsqu’il s’agit de faire du débuggage dans un système de production qui présente un comportement bizarre. Les messages d’erreurs standards sont relativement faciles à diagnostiquer mais lorsque le problème est moins « franc », les choses se corsent. J’adhére partiellement à cet inconvénient. Je souhaitais surtout obtenir une connaissance plus approfondie d’un système d’exploitation. Je me suis donc penché sur Sun Solaris.

Lorsque l’on commence à s’intéresser à Solaris, les choses sont relativement claires dès le début, on va avoir à faire à un Unix dit « traditionnel ». Ceci signifie que les repères acquis sous Linux vont disparaitre totalement et que les outils de simplification seront soit incomplets soit inexistants. D’un autre coté, Solaris est un système d’exploitation qui a de nombreux arguments en sa faveur. Vous avez surement entendu parler de ZFS, le système de fichier révolutionnaire. Vous avez peut être entendu parler de DTrace qui vous donne une vision approfondie du fonctionnement de votre système d’exploitation. Vous avez peut être entendu parler des zones Solaris et de l’intégration native de Xen sous le nom xVM. Et encore, nous n’avons parler de SMF. Bref, autant dire que les arguments sont bien présents.

Solaris permet de s’affranchir des outils et couches de simplification d’un système d’exploitation Linux et de se plonger réellement dans la compréhension du fonctionnement d’un système d’exploitation Unix. Afin de réussir à l’utiliser correctement, il va être nécessaire de comprendre les mécanismes internes. Ceci est un chantier tout à fait passionnant que je vous encourage à entreprendre. Vous ne serez pas seul dans cette entreprise, Sun a prévu pour vous des documentations particulièrement claire et explicite que vous trouverez sur leur site. Sun a également prévu un cursus de certification accessible gratuitement sur leur site. Le passage de l’examen est payant par contre pour la modique somme de 40€.

Mais, pourquoi pas Gentoo ou BSD ? Ces distributions permettent certes de comprendre plus en profondeur le fonctionnement d’un système d’exploitation mais n’ont pas les arguments qu’a Solaris ni la documentation ni le parcours de certification. Je ne dis pas que s’intéresser à Gentoo ou BSD n’aurait eu aucun intérêt, loin de là. J’ai juste préféré changer d’orientation vers une distribution, certes un peu moins libre, radicalement différente.

Terminologie Xen

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 théorie de Popek et Goldberg : les pré-requis de la virtualisation (suite)

img-ressources-processeur-psd-aqua16-1365.jpgCe billet fait suite au billet précédent sur la théorie de Popek et Goldberg ainsi que la mise dans le contexte historique de cette théorie.

Nous avons vu précédemment les trois contraintes imposés au VMM par leur théorie. Pour rappel, le VMM (Virtual Machine Monitor) est la couche applicative de virtualisation.  L’objectif de leur théorie est d’établir les pré-requis nécessaires à la virtualisation. Les trois contraintes servent de base à ces pré-requis et sont en quelque sorte les pré-requis élémentaires. La suite de leur papier s’attache à énoncer des règles plus spécifiques quand à ces pré-requis.

Trois groupes d’instructions processeur

Ils ont tout d’abord distingué trois groupes d’instructions processeur. Leur théorie étant plutôt générique, ces instructions ne sont pas mentionnées nominativement. Elles sont évoqués par leur comportement. Le processeur dispose de deux modes d’exécution : le mode utilisateur et le mode privilégié. Les instructions « utilisateur » sont les instructions classiques de calcul alors que les instructions « privilégiées » sont les instructions de manipulation de données.

Le premier groupe d’instructions processeur est le groupe des instructions privilégiées. Ces instructions nécessitent donc que le processeur soit en mode privilégié pour être exécuté. Si ce n’est pas le cas, elles sont « piégées » (de l’anglais trap) par le système afin d’être traités par le VMM. Le « piège » consiste en un changement de contexte et un traitement de l’instruction par le VMM qui décidera de la suite à donner à cette instruction. Il peut soit l’ignorer soit émuler son fonctionnement.

Le second groupe d’instructions processeur est le groupe des instructions sensibles à la configuration. Ces instructions qui va modifier la configuration du système physique. Ce groupe inclut les instructions visant à à modifier la quantité de mémoire disponible à un processus ou celles visant à changer le mode du processeur sans être « piégées ».

Le troisième groupe d’instructions processeur est le groupe des instructions sensible au comportement. Il s’agit des instructions dont le comportement est impacté par la localisation son exécution. Ce groupe inclut les instructions visant à lire une zone de mémoire vive spécifique ou à se déplacer dans la mémoire vive.

Les trois théorèmes

Après avoir posé tout ces pré-requis, ils énoncent ensuite le coeur de leur théorie, à savoir les théorèmes. Le premier théorème porte sur la possibilité de virtualisation une architecture processeur. Le second théorème porte sur la possibilité de faire de virtualisation récursive, à savoir faire fonctionner plusieurs machines virtuelles dans une machine virtuelle. Le troisième porte sur la possibilité d’exécuter des HVM (Hybrid Virtual Machine) sur une architecture processeur. Un HVM au sens de Popek & Goldberg est une VM pour laquelle une majorité d’instructions sont interprétées par le VMM.

Le premier théorème énonce que pour qu’une architecture processeur soit virtualisable il faut que les instructions sensibles fassent parti des instructions privilégiés.

For any conventional third generation computer, a virtual machine monitor may be constructed if the set of sensitive instructions for that computer is a subset of the set of privileged instructions.

L’architecture la plus répandue actuellement ne répond pas à ce théorème, il y a quelques instructions qui posent problème d’où la nécessité d’utiliser les techniques de virtualisation que nous connaissons aujourd’hui.

Le second théorème énonce qu’il est possible de faire de la virtualisation récursive sur une architecture processeur si elle répond au premier théorème et qu’un VMM sans dépendance de temps peut être élaboré.

A conventional third generation computer is recursively virtualizable if it is : virtualizable and a VMM without any timing dependencies can be constructed for it.

Le troisième théorème énonce  qu’un HVM est réalisable si les instructions sensibles exécutables en mode utilisateur font partie des instructions privilégiées.

A hybrid virtual machine monitor may be constructed for any conventional third generation machine in which the set of user sensitive instructions are a subset of the set of privileged instructions.

Au final, je pense avoir fait le tour de la théorie de Popek et Goldberg. Je suis conscient que ce sujet est assez compliqué à appréhender. Je ne pense pas avoir été d’une clarté légendaire mais j’espère avoir clarifié quelque peu cette théorie. Si vous souhaitez en savoir plus sur cette théorie, je vous invite à lire le document initial (maitrise de l’anglais requise).