Les domaines Xen : le domaine privilégié

Xen_logoCela fait désormais un bon bout de temps que je n’ai pas eu l’occasion de vous parler de Xen. Lors du dernier article sur ce sujet, nous avions surtout parlé de configuration réseau. J’aurais peut être l’occasion d’en reparler par la suite, nous verrons bien.

J’ai déjà eu l’occasion de vous parler des domaines Xen à plusieurs occasions sur ce blog. J’ai défini la notion dans l’article sur la terminologie Xen. Dans ce billet je vais essayer d’élaborer un petit plus sur ce sujet en détaillant un peu plus les interactions entre le domaine privilégié et le matériel.

Domaine privilégié : dom0

Le domaine privilégié ou dom0 est le système d’exploitation « visible » d’une installation Xen. Il s’agit du système d’exploitation que l’on installe avant d’installer l’hyperviseur. Pour rappel, cela ne veut pas dire que l’hyperviseur est au desssus du dom0 car il est bien en dessous. Vous pouvez le vérifier au démarrage, car on voit bien que Xen s’exécute avant la distribution du dom0.

Le domaine privilégié est un domaine exceptionnellement sensible. Il s’agit du domaine qui va avoir accès à toutes les ressources physiques auxquelles l’hyperviseur n’aura pas l’accès exclusif. L’hyperviseur n’a un accès exclusif au processeur et à la mémoire. Tout le reste relèvera donc de la compétence du dom0. Ceci inclut donc tout particulièrement les supports de stockage. Le dom0 a donc accès à toutes les données de votre hyperviseur, il est donc indispensable de le sécuriser.

Le rôle du domaine privilégié

En ce qui concerne le rôle du dom0, il est essentiellement de gérer les supports de stockage, les périphériques éventuels ainsi que les éventuels interfaces d’administration. Il n’est pas souhaitable de lui attribuer plus de rôles que cela. Il est cependant indispensable de lui allouer des ressources physiques convenables. Etant donné que la gestion de support de stockage fait partie de sa compétence, il est nécessaire qu’il se voit attribuer suffisamment de mémoire vive afin de pouvoir constituer un cache performant.

L’hyperviseur attribue par défaut tous les périphériques au domaine privilégié. Certaines configurations spécifiques peuvent nécessiter de rendre accessible un périphérique à une machine virtuelle. Ces configurations sont relativement compliquées à mettre en place dans un contexte de haute disponibilité avec migration à chaud. Ceci s’explique habituellement par le simple fait que le périphérique ne peut être branché sur un seul serveur à la fois. Des solutions d’USB sur IP sont plus simples. Il reste cependant possible d’effectuer une délégation de périphérique vers un domaine non privilégié. Il y a déjà eu des exemples de délégation de cartes graphique permettant de jouer à des jeux 3D dans des domaines non privilégiés.

Interface avec les autres domaines

Les autres domaines vont accéder aux ressources relevant de la compétence du dom0 via des pilotes génériques de périphérique. Ces pilotes génériques permettent de maximiser la compatibilité et d’éviter les différences entre les différentes plateformes Xen. L’intérêt des pilotes génériques est immédiat dans le cas de la migration à chaud où la standardisation des environnements est primordiale.

Le schéma suivant récapitule très bien toutes ces interactions.

Capture d’écran 2009-12-14 à 14.39.27

Au final, je pense avoir fait une présentation plutôt détaillée du domaine privilégié. Si vous avez des questions ou des remarques, n’hésitez pas, les commentaires sont faits pour cela. Dans un prochain article, j’évoquerais plus en détail les domaines non privilégiés.

L’envers de la virtualisation, épisode 2

tech-presentation-2Lors du précédent article, j’ai introduit cette série d’articles par le portrait marketing de la virtualisation. Vous l’aurez sans doute compris que ce portrait se voulait ironique. L’ironie puise cependant ses origines dans la réalité. Les discours marketing sont souvent assez peu loin de ce que j’ai eu l’occasion de décrire.

Une boite noire qui fait tout

La virtualisation se vend actuellement sous forme de solutions « boite noire » qu’on installe sur un serveur standard. Cette configuration incite à faire penser qu’il est possible d’installer cette « boite noire » en mode Windows sans se poser la moindre question. Lorsque vous installez une plateforme de virtualisation, l’hyperviseur de virtualisation est la couche applicative la plus critique de votre infrastructure. Vous comprendrez donc aisément l’importance et la criticité de ce composant applicatif.

L’installation d’un hyperviseur de virtualisation doit être la plus standard possible. Vous allez sans aucun doute être amené à migrer des machines virtuelles d’un serveur à un autre. Il faut donc que la couche la plus basse soit standardisée. De plus, il est nécessaire de limiter au strict nécessaire les fonctions exécutées par la couche de virtualisation afin de limiter les possibilités de bugs.

On l’installe et on l’oublie

Au cours de l’exploitation de votre plateforme, vous serez sans aucun doute amener à rencontrer des problèmes liés à la couche de virtualisation. Penser que la virtualisation est quelque chose de parfaitement transparent est parfaitement faux. Il est nécessaire de maintenir cette plateforme. Des actions de maintenance classique sont l’analyse des performances afin de déterminer si votre plateforme est correctement dimensionnée ainsi que l’analyse des fichiers de logs.

Tous les défauts inhérents à un système d’exploitation peuvent se retrouver au niveau des couches de virtualisation. Il n’y a pas de magie spécifique qui tendrait à rendre parfait une plateforme de virtualisation. Il est nécessaire d’y porter un regard attentif et régulier.

Tout marche tout seul

Cette affirmation peut être vraie. Cependant, la limite de sa véracité se limite à la survenue du premier problème lié à la couche de virtualisation. Les problèmes vont avoir besoin de personnes pour se résoudre. Les problèmes de couche de virtualisation ne sont pas forcément simples. Il est donc nécessaire d’avoir du personnel formés à la virtualisation qui connaissent les spécificités de cet outil ainsi que son fonctionnement.

Au final, la virtualisation est une technique informatique exceptionnelle qui s’implante avec succès dans les infrastructures actuelles. Il est cependant nécessaire de prévoir soigneusement l’installation des couches de virtualisation afin d’assurer une homogénéité et d’éviter de nombreuses surprises en cas de défaillance. Il est également nécessaire de prévoir et prendre le temps d’analyser le fonctionnement quotidien de cette couche de virtualisation afin de s’assurer de sa santé et de prévoir les évolutions. De plus, une couche de virtualisation n’est pas un système d’exploitation comme un autre et nécessite une formation spécifique.

L’envers de la virtualisation, épisode 1

tech-presentation-2J’ai eu l’occasion d’évoquer les nombreux mérites de la virtualisation dans ce blog. La virtualisation est un des « buzzword » très à la mode actuellement. On en parle en long, en large, en travers et en profondeur (rien que ca …). Je n’évoquerais pas le « cloud computing » dans cet article car j’aurais l’occasion d’évoquer le sujet ultérieurement.

A en croire les louanges faites de la virtualisation, il serait quasiment possible de croire qu’il s’agit du paradis de l’informatique, la solution pour toutes les dominer. Dans un premier épisode, je dresserais le tableau qui est dressé par les commerciaux de produits de virtualisation. Dans un second épisode, je m’attacherais à coller plus à la réalité. Cet article se veut ironique au cas où vous auriez un doute.

En route vers le paradis

La virtualisation présente de nombreux avantages et permet de donner un nouveau souffle aux architectures informatiques. Ceci se fait essentiellement à travers la mutualisation des équipements physiques. Cette mutualisation des équipements permet donc des réductions de coûts. Vous allez juste devoir rajouter une petite « boite noire » qui se maintient automatiquement et qui permet de donner une flexibilité incroyable à votre infrastructure.

Vous allez pouvoir remplacer votre baie de serveurs physiques ayant chacun leur utilité par un petit nombre de serveurs plus puissants dotés d’une plateforme de virtualisation. Cette affirmation est exceptionnellement alléchante mais ne présente que le point de départ et le point d’arrivée. Le chemin entre les deux n’est pas sans embuche et ne s’emprunte pas aveuglément.

Vous allez pouvoir économiser de l’argent au niveau du stockage car plus les disques sont volumineux plus le prix au gigaoctet est faible. Vous allez peut être même pouvoir gagner en redondance car vous aurez plusieurs serveurs. Vous allez économiser au niveau du réseau car vous aurez besoin de moins de ports réseau.

Les nouvelles machines que vous allez acheter vont être des monstres de puissance et donc théoriquement vous aurez plus de puissance et de rapidité. De plus, vous avez lu de nombreux articles sur la virtualisation qui vous ont démontré que les performances d’un OS virtualisé sont pratiquement identiques à celles d’un OS natif. Que de bonheur !

Au final, voici un bon nombre de clichés que nous rencontrons tous les jours autour de la virtualisation. Je vous donne rendez-vous pour le second épisode qui s’attachera à donner du réalisme à toutes ces promesses.

De la différenciation hyperviseur type 1 / type 2

tech-presentation-2A travers cet article, je souhaiterais exposer et argumenter mon point de vue sur les appellations d’hyperviseur qui fleurissent un peu partout sur Internet. Ceux qui suivent régulièrement ce blog doivent avoir une petite idée de mon avis sur cette appellation. Je vais essayer d’exposer mon point de vue de manière équilibrée et argumentée. Il s’agit donc ici d’un billet d’opinion.

Vous avez surement dû voir sur divers sites web l’appellation hyperviseur type 1 et hyperviseur type 2. Je ne connais pas l’origine des ces termes. Je soupçonne cependant fortement que ces deux termes soit d’origine marketing.

Note : Cet article a été publié sur le blog Orange Business Service Virtualisation le 3 Novembre 2009.

Qu’est ce qu’un hyperviseur ?

Tout d’abord, je vais m’attacher à exposer les différentes définitions de la notion d’hyperviseur. Wikipedia France nous donne la définition suivante.

En informatique, un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une machine physique en même temps.

Cette définition semble particulièrement large. Elle implique l’équivalence entre hyperviseur et application de virtualisation. Je définirais un « composant de virtualisation » en tant que n’importe quel composant applicatif permettant d’exécuter plusieurs systèmes d’exploitation sur une même machine physique. Il y a donc bien équivalence entre les deux définitions.

Qu’est ce qui définit techniquement un hyperviseur ?

Comme vous le savez, il existe de nombreuses techniques de virtualisation. Toutes ces techniques de virtualisation proposent une diversité assez large. Il me semble donc assez réducteur des les regrouper toutes sous le nom d’hyperviseur d’autant plus que l’appellation « composant de virtualisation » existe déjà.

La définition technique d’un hyperviseur est mieux illustrée à travers le fonctionnement de la paravirtualisation. Dans le cas de la paravirtualisation, l’hyperviseur est l’interface primaire et exclusive des ressources physiques principales. La notion d’hyperviseur se justifie par le fait que le noyau est historiquement le « superviseur ». Cette notion de « superviseur » est issue du mode « superviseur » des processeurs x86 car il s’agit du noyau qui va gérer les interruptions en mode superviseur. En toute logique, nous avons donc l’hyperviseur qui gère les superviseurs.

Dans le cas de la virtualisation de systèmes d’exploitation non modifiées, le « composant de virtualisation » se situe au dessus d’un système d’exploitation et donc d’un noyau. Nous avons donc une contradiction au niveau des appellations vu que l’hyperviseur va être géré par le « superviseur », à savoir, le noyau. Il y a donc une incohérence. Je vous remets, pour rappel, le schéma comparant paravirtualisation et virtualisation totale.

virtus

Quid des types d’hyperviseur

Afin de palier à cette contradiction, une différenciation a été faite et l’appellation « hyperviseur type 1 » et « hyperviseur type 2 » a vu le jour. Cette appellation ne répond cependant pas à la contradiction soulevée précédemment.

Pour rappel, un hyperviseur de « type 1 » est un hyperviseur s’exécutant directement sur la plateforme matérielle, comme dans le cas de la paravirtualisation. Un hyperviseur de « type 2 » est un hyperviseur s’exécutant par dessus un système d’exploitation invité.

Pour résumer cet article, je pense que l’appellation d’hyperviseur n’est pas adaptée aux solutions de virtualisation s’exécutant au dessus d’un système d’exploitation invité. Je pense que l’appellation « application de virtualisation » serait plus adaptée et correspondrait plus à la réalité. Je tiens également à soulever la question essentielle de cet article, peux-t’on considérer un couple système d’exploitation et application de virtualisation en tant qu’hyperviseur ? A partir de quel seuil un couple OS/application de virtualisation peut-il être considéré en tant qu’hyperviseur ?

Nouvelle classification des types de virtualisation

tech-presentation-2J’ai déjà eu l’occasion de proposer une classification des différents types de virtualisation lors d’un précédent article sur ce blog. Lors de ce précédent article, je m’étais attaché à classifier les solutions de virtualisation de systèmes d’exploitation. Je propose par le biais de cet article de re-préciser cette classification en y intégrant d’autres types de virtualisation et en reprenant en partie le précédent.

Tout d’abord, il sera essentiel de s’interroger sur ce que nous allons virtualiser car il est possible de virtualiser bon nombre de composants applicatifs. J’utiliserais le terme de composant applicatif pour désigner tout ce qui n’est pas matériel. Ce terme inclura donc les systèmes d’exploitation en globalité ou en partie aussi bien que les applications spécifiques. Ensuite, je proposerais un arbre de classification complété par rapport à la première version de cet article. Je rappellerais au passage les appellations correspondantes aux différents types de virtualisation.

Note : Cet article a été publié le 28 Octobre dans une version simplifiée sur le blog Virtualisation d’Orange Business ServiceS.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Que virtualise-t’on ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite.

Nous allons distinguer trois familles de virtualisation : réseaux, systèmes d’exploitation et processus. Ces trois types constitueront le premier étage de notre arbre de classification.

On virtualise comment ?

Nous avons donc effectué une première discrimination basée sur le composant applicatif que nous allons virtualiser afin d’établir le premier étage de notre arbre de classification. Nous allons ensuite établir le second étage de cet arbre.

Nous allons ensuite associer à chaque composant applicatif les différents types de virtualisation correspondants. En ce qui concerne les systèmes d’exploitation, nous ajouterons une distinction importante qui est la modification ou non du système d’exploitation invité. Un système d’exploitation invité est un système d’exploitation qui s’exécute par dessus une couche de virtualisation spécifique.

Voici donc l’arbre de classification que je propose :

schema_classification_small

Le premier type de virtualisation présent dans cet arbre est la virtualisation d’équipements réseaux. Il aurait été possible d’inclure la virtualisation de réseaux. Ceci a été exclu de cette classification car il ne s’agit que d’un mécanisme de commutation spécifique. Ce type de virtualisation permet de créer des environnements réseaux spécifiques et cloisonnés de bout en bout. Les solutions existantes dans ce domaine sont les produits Nexus de Cisco et le futur switch virtuel de Citrix.

Dans la catégorie des systèmes d’exploitation, nous avons choisi de distinguer les systèmes d’exploitation modifiées et non modifiées. Les modifications en question sont les modifications du noyau nécessaire à l’exécution du système d’exploitation par dessus une couche de virtualisation spécifique.

La virtualisation de système d’exploitation modifiés est la paravirtualisation. Ce terme a tendance à être utilisé de nombreuses manières différentes. La paravirtualisation est la virtualisation de systèmes d’exploitation dont le noyau a été modifié pour communiquer avec la couche de virtualisation au lieu de communiquer avec le matériel physique. Pour résumer, la système d’exploitation va avoir conscience d’être virtualisé et sera adapté à cet effet. L’ajout de simple drivers spécifique n’implique pas forcément paravirtualisation. Les solutions existantes dans ce domaine sont les produits XenServer de Citrix, xVM de Sun, XenSource voire Hyper-V de Microsoft. VMWare commence à se lancer dans cette technologie prudemment. Si vous souhaitez en savoir plus sur la paravirtualisation, je vous laisse consulter l’article sur la paravirtualisation.

En ce qui concerne les systèmes d’exploitation non-modifiés, nous distinguerons deux types de virtualisation : la virtualisation totale et la virtualisation matériel assistée. La virtualisation totale est la virtualisation « primitive » qui consiste à émuler le matériel physique ainsi que son comportement. Il s’agit de l’approche la plus couteuse mais la plus simple à mettre en oeuvre. La virtualisation matériel assisté est une extension du principe de virtualisation totale. Cette extension se matérialise par l’utilisation des extensions processeur spécifiques à la virtualisation (AMD-V et Intel-VT). Ces extensions permettent d’accélérer la virtualisation par différents mécanismes. Les solutions utilisant cette technologie sont VMWare, Virtualbox de Sun, Virtual PC de Microsoft, QEMU et bien d’autres.

Au niveau de la virtualisation de processus, nous retrouvons deux types de virtualisation : la virtualisation au niveau du système d’exploitation et la virtualisation d’application. La virtualisation au niveau du système d’exploitation consiste à faire croire à plusieurs jeux de processus qu’ils s’exécutent dans différents systèmes d’exploitation alors que ce n’est pas le cas. Les solutions utilisant cette technique sont les zones Solaris, les chroot Linux, les jails BSD, OpenVZ et bien d’autres. La virtualisation d’application consiste à livrer des applications non installées sur un poste par un serveur. Les solutions utilisant cette technique sont XenApp de Citrix ou VMWare Thinapp.

Au final, je pense que cette classification est plus complète que la précédente que j’avais eu l’occasion de présenter. Elle inclut notamment la virtualisation d’application et la virtualisation d’équipements réseaux. Cette classification reste une proposition et il est tout à fait possible de proposer une classification sous un autre angle.

Installation d’OpenSolaris 2009.06 sur Xen

solaris-logoDans un précédent billet, nous avons vu l‘installation de Xen ainsi que sa configuration réseau. Vous pouvez soit installer des domU Linux ce qui est particulièrement simple, voire magique, avec l’outil xen-tools. Mais étant donné que vous avez été convaincu par ma présentation de Solaris, vous allez vous lancer dans l’installation d’OpenSolaris sur votre plateforme de virtualisation Xen.

L’installation d’un domU OpenSolaris par dessus un dom0 OpenSolaris est particulièrement simple et je n’en parlerais pas ici. Nous allons nous intéresser à l’installation d’un domU OpenSolaris par dessus un dom0 Linux. Les raisons de ceci sont un plus grand challenge et la conservation des avantages d’un dom0 Linux. Cette installation n’est pas des plus simples et nécessite d’y passer un peu de temps. Nous supposerons que vous êtes en 64-bits car la quasi-totalité des plateformes s’exécutent aujourd’hui en 64-bits.

Préparation de l’installation

Pour pouvoir installer OpenSolaris, il va nous falloir OpenSolaris. Jusqu’ici rien de trop compliqué. Nous allons nous placer dans le répertoire /xen pour effectuer l’installation. Je vous laisse donc télécharger l’ISO d’OpenSolaris dans ce répertoire.

Nous allons avoir besoin de divers fichiers dans cet ISO, nous allons donc le monter en local.

cd /mnt && mkdir osol

mount -o loop /xen/osol-0906-x86.iso /mnt/osol

Ensuite, nous allons récupérer les fichiers dont nous allons avoir besoin. Ces fichiers sont un kernel minimaliste afin de pouvoir booter l’installation.

cp /mnt/osol/platform/i86xpv/kernel/amd64/unix /xen/

cp /mnt/osol/boot/x86.microroot /xen/

Nous devons ensuite créer le disque sur lequel le système d’exploitation va s’installer. Vous pouvez soit créer une partition LVM soit créer un image disque. Pour le LVM, je vous réfère à l’excellent tutoriel présent sur le site de Gayux. Pour créer une image disque, vous pourrez utiliser la commande dd comme suit. La commande suivante crée une image de 10Go.

dd if=/dev/zero of=/xen/disk.img bs=1024k count=1 seek=10000

Configuration du domU

Vous allez ensuite devoir paramétrer le domU. Les fichiers de configuration de domU se trouvent par défaut dans le répertoire /etc/xen. Vous pourrez y créer un fichier .cfg qui contiendra les informations suivantes. En ce qui concerne les pré-requis de l’installation, vous allez avoir besoin de 512Mo de RAM pour l’installation. Vous pourrez descendre en deçà par la suite mais l’installation nécessite autant de RAM étant donné qu’il est nécessaire d’exécuter Gnome. Vous devez donc créer le fichier de configuration suivant. J’ai choisi opensolaris.cfg.

name = « opensolaris-cest-trop-bien »
vcpus = 1
memory = 512
kernel = « /xen/unix »
ramdisk = « /xen/x86.microroot »
extra = « /platform/i86xpv/kernel/amd64/unix -B console=ttya,livemode=text »
disk = [‘file:/xen/osol-0906-x86.iso,6:cdrom,r’,’file:/xen/disk.img,0,w’]
vif = [ »]
on_shutdown = « destroy »
on_reboot = « destroy »
on_crash = « destroy »

Vous pouvez ensuite exécuter la VM que vous venez de créer avec la commande suivante :

xm create -c /etc/xen/opensolaris.cfg

Installation

Vous allez ensuite pouvoir démarrer l’installation via le mode ligne de commande jusqu’à ce que vous arriviez à un invite de commande standard. Vous allez pouvoir vous logguer via le compte jack et le mot de passe jack. Logique ? Non, je suis entièrement d’accord.

Nous allons donc ensuite devoir exécuter un serveur VNC afin de pouvoir faire l’installation en mode graphique. Je sais que ca vous chagrine de devoir faire une installation en mode graphique mais OpenSolaris ne fait pas d’installation en mode console. Ne vous inquiétez pas, vous allez pouvoir dégager Gnome dès l’installation finie. Avant de pouvoir activer VNC, il va vous falloir configurer votre interface réseau. Si vous êtes en DHCP, cela devrait fonctionner automatiquement. La procédure à suivre pour l’activation du serveur VNC est la suivante :

mkdir .vnc

cp .Xclients .vnc/xstartup

vncserver

Vous pouvez ensuite vous connecter en VNC directement à l’IP en question. Vous allez ensuite pouvoir faire l’installation via le mode graphique. Avant de redémarrer, vous allez devoir récupérer une petite info.

pfexec zdb -vvv rpool | grep bootfs

Vous allez récupérer une information du type « Bootfs = CHIFFRE« . Retenez bien ce numéro ou notez le sur un bout de papier ou tout autre surface.

Exécution

Il est temps de faire un petit résumé de ce que nous avons fait jusqu’à présent. Nous avons préparé l’installation afin de pouvoir exécuter notre installation d’OpenSolaris. Nous avons exécuter le domaine d’installation et mis en place un serveur VNC pour pouvoir y accéder en mode graphique. Dans ce mode graphique, nous avons fait les étapes d’installation. Il nous reste donc plus qu’à exécuter l’OS que nous venons d’installer. Pour se faire, nous allons devoir apporter quelques modifications à notre fichier de configuration.

name = « opensolaris-cest-trop-bien »
vcpus = 1
memory = 270
kernel = « /xen/unix »
ramdisk = « /xen/x86.microroot »

extra = ‘/platform/i86xpv/kernel/amd64/unix -B console=ttya,zfs-bootfs=rpool/CHIFFRE,bootpath= »/xpvd/xdf@0:a »‘
disk = [‘file:/xen/osol-0906-x86.iso,6:cdrom,r’,’file:/xen/disk.img,0,w’]
vif = [‘ip=xx.xx.xx.xx,mac=00:16:3E:FF:AB:AB’]
on_shutdown = « destroy »
on_reboot = « destroy »
on_crash = « destroy »

Vous allez ensuite pouvoir exécuter votre VM et profiter de votre nouvelle installation d’OpenSolaris !

Au final, cette installation est certes un peu fastidieuse mais permet tout de même d’installer OpenSolaris sur un dom0 Linux. Si vous avez des remarques par rapport à ce tutoriel, vous pouvez toujours me contacter via l’onglet prévu à cet effet. Amusez-vous bien sous Solaris !