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.

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).

La théorie de Popek et Goldberg : les pré-requis de la virtualisation

Après avoir parlé en long et en large des anneaux de protection système, je souhaite parler un peu de la théorie de la virtualisation. Je suis conscient que vous êtes surement plus habitués à voir des billets plus concrets sur les blogs à travers le net. Cependant, ce sujet m’intéresse beaucoup et je pense qu’il pourrait intéresser certains d’entre vous. Il est vrai que l’utilité de ce type de billet n’est pas tout à fait immédiate. Je reviendrais sur des billets plus concrets par la suite.

La naissance de la virtualisation

Tout d’abord, la virtualisation est un concept ancien à l’échelle de l’informatique. Ce n’est pas VMWare qui a inventé la virtualisation en 1999 avec leurs applications. La virtualisation totale n’est pas non plus le premier type de virtualisation. La virtualisation est un concept qui date d’au moins 1970, année à laquelle vous n’étiez (probablement) pas né.  A cette époque est arrivé la révolution des ordinateurs IBM System/360 qui étaient exceptionnels par le fait qu’ils étaient compatibles à l’intérieur d’un même gamme. Un System/360 ressemble à la photo suivante :

2423PH2065C

A cette époque, la virtualisation se faisait de manière matérielle avec un cloisonnement électronique des divers composants applicatifs. Ce type de virtualisation semble toujours exister aujourd’hui dans certains mainframes.

Popek et Goldberg

Popek et Goldberg sont deux chercheurs en informatique de cette époque. Ils ont souhaité formuler les pré-requis nécessaires à la virtualisation de manière formelle. Ils définissent plusieurs termes que l’ont connait toujours aujourd’hui. Une « VM » est une « Virtual Machine » ou machine virtuelle. Un VMM est un « Virtual Machine Monitor » ou moniteur de machine virtuel. Ce dernier correspond à la couche de virtualisation. Ce terme est peu utilisé mais il est possible de le retrouver occasionnellement.

Trois contraintes imposées au VMM

Ils ont tout d’abord défini trois critères que doivent remplir les systèmes de virtualisation afin de pouvoir être considéré en tant que tel. Ces critères serviront par la suite à définir les théorèmes de leur théorie.

Le premier critère est le critère « équivalence». Ce critère implique qu’une application quelconque doit s’exécuter de la même manière qu’elle soit exécuté au dessus d’un VMM ou d’une machine physique. Ceci est nuancé par la disponibilité des ressources physiques qui peuvent modifier la temporalité de l’exécution d’un programme.

Any program run under the VMM should exhibit an effect identical with that demonstrated if the program had been run on the original machine directly, with the possible exception of differences caused by the availibility of system resources and differences caused by timing dependencies.

Le second critère est le critère « efficacité». Ce critère indique qu’une part majoritaire d’instructions soit exécutée par le processeur directement sans intervention du VMM. Ce critère exclut donc les émulateurs et les techniques de virtualisation totale. La virtualisation matérielle assistée permet de répondre plus correctement à ce critère.

The second characteristic of a virtual machine monitor is efficiency. It demands that a statiscally dominant subset of the virtual processor’s instructions be executed directly by the real processor, with no software intervention by the VMM.

Le troisième critère est le critère  « contrôle de ressources». Ce critère indique que le VMM doit avoir le contrôle exclusif des ressources à partager. N’importe quelle application doit donc passer par la VMM pour pouvoir accès à une ressource partagée.

The VMM is said to have complete control of these resources if it is not possible for a program running under it in the created environment to access any resource not explicitly allocated and it is possible under certain circumstances for the VMM to regain control of resources already allocated.

Ces trois critères servent de base à la suite de leur papiers énonçant leurs théories. Nous verrons dans un prochain billet la suite des théorèmes.