Dans les billets précédents, l’objectif avait été de proposer quelques ajustements vis à vis de la conférence sur la sécurité de la virtualisation lors de la Nuit de Hack. Ces articles s’étaient donc voulus plutôt rassurants cependant il est nécessaire de mitiger ce portrait. Les risques liés à la sécurité de la virtualisation existent bien. Affirmer le contraire serait au mieux une vulgaire erreur.

Nous allons aujourd’hui nous intéresser aux vulnérabilités qui ont déjà été trouvées dans des produits de virtualisation et leurs implications.

Xen

Nous allons premièrement nous intéresser au produit Xen open source. Le produit Citrix est un produit hybride s’inspirant largement du produit open source mais disposant de nombreuses modifications qui dépassent le périmètre de ce dernier. La conception de Xen se veut sécurisée par le biais, notamment, de l’utilisation des différents anneaux de protection système. Son histoire n’est cependant pas exempte de vulnérabilités.

La plus grosse vulnérabilité de Xen date de Septembre 2007. Il s’agissait d’une faille qui permettait à un domU d’exécuter des commandes dans le dom0 lors de l’utilisation de l’outil pygrub. L’outil pygrub permet à un domU de disposer d’un bootloader similaire à celui que l’on peut trouver sur une machine physique classique. Cette faille est extrêmement problématique dans la mesure où le dom0 est un domaine exceptionnellement sensible qui dispose de très nombreuses interactions directes avec le matériel et l’hyperviseur. Vous pourrez trouver plus d’informations sur cette faille sur l’OSVDB.

D’autres vulnérabilités ont été trouvées dans Xen permettant à un domU de sortir de son isolation. La plupart de ces failles nécessitent des conditions très particulières afin d’être exploitables ou ne permettent au mieux qu’un DoS local. La liste des failles est disponible sur l’OSVDB.

VMWare

Nous allons ensuite nous intéresser au produit VMWare. La liste des vulnérabilités pour ce produit est nettement plus longue avec un net pic en 2008. Le plus grand nombre de vulnérabilités s’explique surement en partie par la grande étendue des produits VMWare qui incluent aussi bien l’hyperviseur que tous les outils de gestion associés (Virtual Center, Service Console, …).

Parmi toutes ces vulnérabilités, on en recense 4 qui permettent une violation de l’isolation des machines virtuelles. Ces élévations de privilèges se font à travers les VMWare Tools quant il s’agit de machines virtuelles ou à travers les produits connexes à l’hyperviseurs.

Conclusion

Les produits de virtualisation ne sont clairement pas exempts de vulnérabilités quoi que l’on puisse dire. L’impact d’une vulnérabilité sur une plateforme de virtualisation sera largement plus important par rapport à une architecture classique. Il est cependant nécessaire de nuancer ces propos. De nombreuses mesures sont prises afin d’éviter que ces vulnérabilités puissent avoir un impact quelconque sur le reste de la plateforme. De plus jusqu’à présent, l’impact des failles de sécurité est relativement minime et leur fréquence plutôt faible. Il convient donc de rester vigilant aux évolutions des plateformes de virtualisation en matière de sécurité.

Pour en savoir plus, je vous conseille la présentation de Julien Raeis et Nicolas Collignon à ce sujet. Les deux tableaux récapitulatifs présents dans cet article sont extraits de cette présentation.

La sécurisation du stockage

La virtualisation n’ajoute pas de risque particulier à partir du moment où l’on suppose que l’attaquant dispose d’un accès physique aux données. Ce type d’exploit est donc uniquement inhérent au stockage sur disque.

Les réseaux de stockage en Fibrechannel n’ajoutent également pas de risque particulier. Seul les hyperviseurs ont accès aux supports de stockage distribués par le réseau de stockage. De plus, il est possible de gérer finement les accès aux différents supports de disque par les biais des techniques de « zoning ». Le zoning est une technique équivalente aux « Private VLAN » de Cisco dans le cas des réseaux Ethernet.

Contrairement à ce qui a été présenté Samedi dernier, la connexion des équipements Fibrechannel au réseau Ethernet n’ouvre pas de faille supplémentaire. Il n’est pas possible d’utiliser cette interface pour accéder aux données transitant sur le réseau de stockage. L’interface Ethernet permet uniquement d’accéder aux informations de configuration du commutateur.

Supposons qu’il soit possible d’accéder aux données transitant sur le réseau Fibrechannel par le biais de cette interface Ethernet. Toute tentative de spoofing d’adresse MAC serait parfaitement inutile car les réseaux Fibrechannel n’utilisent pas d’adresses MAC mais des WWN qui n’ont rien à voir. Les protocoles de communication sont différents et ne sont pas compatibles.

Cette problématique est cependant intéressante dans le cas des réseaux iSCSI qui n’ont même pas été mentionnés. Il n’est absolument pas souhaitable que les LAN iSCSI soient routables vers d’autres réseaux. Il est même recommandé d’avoir des équipements uniquement dédiés aux fonctionnalités iSCSI dans la mesure du possible.

Récapitulons…

Les potentielles interfaces d’attaque vers les hyperviseurs sont très peu nombreuses. Dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, ces interfaces sont même inexistantes. Dans le cas des interfaces de paravirtualisation, leur utilisation est standardisée par le biais d’API mais la découverte de failles reste envisageable bien qu’aucune n’ait été trouvée à ce jour.

Les mécanismes de DoS sont régulés voire supprimés par les mécanismes classiques d’ordonnancement présents dans toutes les solutions de virtualisation.

Quels sont les risques ?

Les risques réels de sécurité inhérents aux plateformes de virtualisation se situent, d’une part, au niveau des interface de gestion. Les interfaces de gestion ne sont pas propres à la virtualisation mais leur utilisation dans ce cas particulier est généralisé.

L’accès aux interfaces de gestion doivent être sécurisés par les mécanismes réseau traditionnels ainsi que par le biais de méthodes d’authentification. Dans le cas d’une compromission de ces interfaces, les données et l’accès aux machines virtuelles reste indemne. Les interfaces ne disposent généralement pas d’accès particulier aux données, elles disposent uniquement d’une vue globale permettant la configuration des supports de stockage. En ce qui concerne l’accès aux VM, il reste protégé par les protections classiques telles que le couple login et mot de passe. Le passage dans des modes plus privilégiés attireraient inévitablement l’attention car cela nécessiterait des redémarrages non planifiés.

Conclusion

Traditionnellement, on considère qu’une technologie est sécurisée jusqu’à preuve du contraire. Il n’est pas utile de céder au sensationnalisme en décriant des potentielles failles qui n’ont pas été découvertes et qui n’ont jamais été exploitées (dans le cas de Xen).

Si nous suivons cette supposition traditionnelle, nous pouvons affirmer que la virtualisation est une technologie sécurisée. Comme toute technologie informatique, il est nécessaire d’être vigilant lors de son implémentation en suivant quelques règles de bon sens.

Pour revenir au sujet de la présentation effectué lors de la nuit du hack, j’ai été largement déçu par cette présentation aux conclusions au mieux hâtives et des nombreuses autres imprécisions que je n’ai pas évoqué ici.

Une présentation a particulièrement attiré mon attention mais pas pour de bonnes raisons. En fin de soirée avait lieu une conférence intitulé « Virtualisation et sécurité ». J’attendais donc avec impatience cette conférence. Autant dire que cela a été une grande déception. Le sujet était traité d’un point de vue beaucoup trop global mais, surtout, les informations soutenues étaient plus que discutables.

Je vais donc profiter de cette espace pour tenter d’éclaircir certains points par rapport à la sécurité de la virtualisation.

Classification

Avant de plonger dans l’étude à proprement dit de la sécurité dans la virtualisation, il est intéressant de se replonger dans la classification des solutions. Lors de la présentation, il avait été différencié les types de virtualisation suivants : « full virtualisation », « paravirtualisation » et « hyperviseurs ».

Un hyperviseur n’est pas un type de virtualisation mais une application qui peut effectuer de la virtualisation. Il est possible de les classifier selon deux catégories bien que cette division ne me plaise pas particulièrement.

La sécurisation de l’hyperviseur : DoS & DDoS

Lors de la présentation, le DoS (Denial of Service) et le DDoS (Distributed Denial of Service) ont été désignés comme des solutions simples et efficaces de neutraliser une plateforme de virtualisation.

Dans le cas de Xen, il est pratiquement impossible de communiquer avec l’hyperviseur. Il ne faut bien sur par confondre hyperviseur et domaine 0 (ou console de gestion dans le cas de VMWare). L’attaque DoS est donc difficile à imaginer dès le départ. L’interface de communication avec l’hyperviseur dont nous disposons est l’API des hypercalls, remplaçants des appels systèmes classiques dans le cas de la paravirtualisation.

L’utilisation des ces hypercalls est limitée par les algorithmes d’ordonnancement système ce qui empêche une utilisation abusive. Il s’agit du même mécanisme que celui utilisé pour le partage des ressources physiques. Le DoS semble donc impossible par ce biais.

Les outils d’administration sont également un potentiel point d’entrée supplémentaire. Ces outils ne sont accessibles qu’à partir du domaine 0 qui peut difficilement être considéré en tant que VM comme les autres. Un attaque DoS sur le domaine 0 rendrait les mêmes résultats qu’une attaque DoS sur les autres machines virtuelles étant donné les mécanismes d’ordonnancement.

La communication avec l’hyperviseur n’étant possible que par ces interfaces, il parait impossible d’y effectuer une attaque DoS capable d’atteindre toutes les machines virtuelles de la plateforme.

La sécurisation de l’hyperviseur : cloisonnement

Le cloisonnement des machines virtuelles est bien sûr une caractéristique élémentaire d’une plateforme de virtualisation. Contrairement à ce qui a été dit, l’hyperviseur n’a pas « la main » sur les machines virtuelles. Il a simplement la possibilité de les éteindre, de les démarrer ou de les mettre en pause. Ni plus, ni moins.

Le cloisonnement est géré par la restriction des accès mémoire. Les hyperviseurs ont été spécifiquement prévus afin d’éviter un débordement des accès vers la mémoire. Le seul vecteur d’exploitation de ce type de faille est les hypercalls dans le cas de Xen. A ce jour aucune faille connu permet d’accéder à des zones mémoires non autorisées.

De plus dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, les machines virtuelles ne disposent même pas d’interface spécifique avec l’hyperviseur ce qui rend pratiquement impraticable de ce type de vulnérabilité.

Les risques d’erreur de cloisonnement ne sont pas inexistants bien entendu cependant il ne faut pas perdre de vue qu’il s’agit de l’objectif même de la conception de l’hyperviseur et que les machines virtuelles disposent de très peu ou aucune interface de communication avec l’hyperviseur afin de l’induire en erreur.

Dans le prochain (et dernier épisode), nous étudierons les autres points abordés lors de la présentation et les risques réels associés à la virtualisation. Loin de moi l’idée de prêcher la sécurisation totale de la virtualisation, je pense cependant qu’il est très facile et réducteur d’agiter des menaces sans fondement pratique.

Petit historique

Vous savez peut être que Xen a été quelque peu obscurcit par l’introduction de KVM dans le noyau Linux. Cette inclusion de KVM a conduit des distributions telles que Red Hat et Ubuntu à supprimer Xen de leurs distributions ou de ne laisser qu’un support pour le moins minimal. A l’époque de ces faits, Xen n’était compatible qu’avec un ou deux noyaux Linux patchés par l’équipe de Xen. Cette époque est révolue car Xen a évolué vers les noyaux dits « Paravirt Ops » ce qui signifie que la compatibilité d’un noyau Linux avec Xen ne tient plus qu’à un module de ce même noyau.

La version Xen 4.0 est particulièrement intéressante car il s’agit de la première version qui fonctionne par défaut avec les noyaux Paravirt Ops. L’installation de versions antérieures vous assurera la douleur de devoir éventuellement passer vers une version supérieure à la 4.0 lorsque vous voudrez mettre à jour vos noyaux Linux.

Installation

Nous pouvons désormais passer aux choses sérieuses. Nous allons effectuer une installation à partir des sources car il n’existe pas encore de paquets. Et puis de toute façon, une petite compilation ne vous fait pas peur !

Nous allons tout d’abord récupérer l’archive sur le site de Xen et on la dézippe :

wget http://bits.xensource.com/oss-xen/release/4.0.0/xen-4.0.0.tar.gz

tar zxvf xen-4.0.0.tar.gz

Nous allons ensuite installer tous les pré-requis et ils sont nombreux.

apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial build-essential make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev iasl libbz2-dev e2fslibs-dev git-core uuid-dev gcc-multilib

Passons désormais à la compilation. Si vous avez une machine dotée de plusieurs cœurs / processeurs, n’hésitez surtout pas à utiliser l’option -jX où X est le nombre de cœurs que vous avez. Cette option permet de répartir la compilation sur tous les cœurs et ainsi de la finir plus rapidement. J’avais un BiQuad Core, donc ce sera 8 pour cet exemple.

make -j8 xen

make -j8 tools

make -j8 stubdom

Ensuite, on installe tout ca.

make -j8 install-xen

make -j8 install-tools

make -j8 stubdom

Grâce à toutes ces commandes, nous avons installé Xen ainsi que tous les outils associés. Il nous manque plus que le noyau Linux pour les domaines. A partir de là, vous pouvez soit créer votre propre noyau soit utiliser un noyau proposé par Xen. J’ai choisi de faire cela car c’était plus simple, plus rapide et plus pratique.

On va donc exécuter la commande qui va nous permettre de récupérer et de compiler le noyau qui va bien pour notre installation de Xen.

make -j8 world

Pour installer le noyau que vous avons compilé, il ne manque qu’à exécuter la commande suivante. On crée au passage l’initrd qui va bien.

make install

mkinitramfs -o /boot/initrd-2.6.31.13.img 2.6.31.13

Vous devez ensuite modifier Grub afin qu’il s’adapte à Xen. La configuration suivante fonctionne sur l’hyperviseur que j’ai eu l’occasion d’installer. Il faut adapter le root en fonction de votre serveur. Ici, il s’agissait d’un contrôleur RAID HP.

title           Xen 4.0.0 / Debian GNU/Linux, kernel 2.6.31.13
root            (hd0,1)
kernel          /boot/xen-4.0.0.gz
module          /boot/vmlinuz-2.6.31.13 root=/dev/cciss/c0d0p2 ro console=tty0
module          /boot/initrd-2.6.31.13.img

Vous pouvez ensuite rebooter sur votre nouvelle installation de Xen 4.0 avec votre noyau Paravirt Ops. Si vous souhaitez modifier des options à la compilation du noyau, il faut se placer dans le bon répertoire et activer les bons paramètres dans le menu.

cd build-linux-2.6-pvops_x86_64

make menuconfig

Il faut activer le support TUN/TAP si vous souhaitez exécuter des domaines HVM ainsi que le support du 802.1Q si vous souhaitez placer vos domaines sur différents VLAN. Ces deux options ne sont pas activées par défaut.

Au final, j’espère que ce tutoriel vous sera utile et que j’ai été clair. Le passage vers les noyaux en Paravirt Ops est une évolution majeure dans l’histoire de Xen et permettra une adoption nettement plus large.

Nous distinguerons trois types de nuages. Le premier type, également le premier à être apparu sous la dénomination « cloud », est le nuage public. Le second type est le nuage privé. Le dernier type est un mélange des deux, c’est à dire, un nuage privé-public.

Le nuage public

La dénomination de « cloud computing » est arrivée en même temps que les grands nuages publics. Ces grands systèmes informatiques ont été rendus viables grâce à une forte automatisation et une grande efficacité des couches de virtualisation.

Dans ce type de nuage, chaque client se voit attribuer plus ou moins aléatoirement une machine virtuelle dans laquelle il pourra faire ce qu’il souhaite. Ces machines virtuelles sont soumises aux contraintes définies par l’hébergeur en fonction de ses conditions générales de vente. Chaque machine virtuelle est sensée être l’égale d’une autre et le client n’a que très peu d’amplitude pour la construction d’une véritable architecture.

Les nuages publics existant aujourd’hui ont essentiellement vocation à être des plateformes d’hébergement grand public à la manière d’OVH sur le marché des serveurs dédiés. Pour que cette comparaison soit valable, il est nécessaire d’exclure la diversification des offres d’OVH avec notamment la possibilité d’obtenir un firewall Cisco ASA. Il est peu probable qu’il soit possible d’insérer un Cisco ASA dans un grand nuage public.

La présence de l’open source dans les nuages public est très forte, surtout à travers de Xen. Amazon, Gandi, 1&1 et Rackspace sont tous basés sur Xen. Le marché des grand nuages public a peu de chance de voir une réelle présence de VMWare à cause de sa tarification. Je vous laisse imaginer le prix d’un cloud public VMWare…

Le nuage privé

Les nuages privés sont clairement orientés vers les entreprises. Il parait particulièrement improbable de voir une quelconque entreprise confier la totalité de ses données et de l’infrastructure informatique à une nébuleuse telle qu’Amazon.

Il me semble que la notion de nuage privé est quasiment équivalente à la notion de plateforme de virtualisation interne à une société. Dans ce type de nuage, la notion de « cloud computing » semble floue et la distinction avec une plateforme de virtualisation semble mince voire inexistante.

L’open source a un rôle à jouer sur ce type de nuages mais l’état actuel des choses ne le facilite pas. L’automatisation d’une plateforme Xen ou KVM nécessite un travail de développement conséquent même si des outils tels que le Xen Cloud Platform vont dans le bon sens. VMWare est désormais très présent sur le marché avec ses produits d’administration et d’automatisation VSphere et Virtual Center.

Le nuage privé-public

Le nuage privé-public est un nuage privé inséré dans une plateforme public. Ce type d’offre est encore relativement rare car le concept est plutôt récent.

Cette notion semble relativement équivalente à la notion de nuage privé placé dans le cadre d’une offre d’infogérance. Bien que les offres placées sous la dénomination « nuage privé-public » sont rares, les plateformes de virtualisation infogérées sont monnaie courante aujourd’hui.

Au final, je pense avoir fait le tour des différentes configurations de « cloud computing » que l’on peut retrouver aujourd’hui. Je pense également que toutes ces offres ne sont pas réellement révolutionnaires contrairement à ce que bon nombre de commerciaux souhaiteraient nous faire croire.

A défaut de réussir à définir conceptuellement le cloud computing, nous allons essayer de le définir technologiquement. Cet exercice devrait être largement plus simple que le précédent car les ressources abondent sur ce plan. Comme vous vous en doutez déjà, il existe de nombreux types d’infrastructures physiques et applicatives placées sous la dénomination de cloud computing. Nous essayerons de faire une sélection des technologies réccurentes.

La virtualisation

Lorsqu’est évoqué la notion de cloud computing, la notion de virtualisation n’est pas bien loin. La montée en popularité du cloud computing coïncide largement avec la monte en popularité des plate-formes de virtualisation. Bien qu’il existe de nombreux types de virtualisation, la virtualisation de systèmes d’exploitation est la plus fréquente, de loin. Nous pouvons affirmer de manière relativement sûre que la base essentielle du cloud computing est la virtualisation de systèmes d’exploitation.

La virtualisation de système d’exploitation n’est cependant pas un phénomène récent. Les premières applications de VMWare datent de 1998. L’amélioration des processeurs x86 n’est certainement pas étranger à ce phénomène avec la multiplication et la densification des coeurs de calcul. La montée du cloud computing est sans aucun doute liée avec la montée en puissance des applications d’automatisation des plate-formes de virtualisation. Cette automatisation permet une flexibilité exceptionnelle et une réactivité dans l’évolution du cloud.

La place de l’open source

Alors que l’on pourrait croire que l’acteur le plus populaire dans ce domaine est VMWare, la réalité ne confirme pas cette intuition. L’open source joue un rôle essentiel dans le domaine du cloud computing à travers l’hyperviseur Xen. Le cloud publique d’Amazon est basé sur le projet Xen tout comme l’offre de serveur virtuel privé de Gandi. Cette adoption massive peut probablement s’expliquer par la nature open source de l’hyperviseur ayant permis le développement des outils d’automatisation mais aussi par la faible perte de performance. Bien que le projet KVM ait été intégré dans le noyau Linux et choisi par différentes distributions, ceci signifie en aucun cas la fin du projet Xen.

Dans le cas du déploiement de grands clouds publiques, l’utilisation des plate-formes de virtualisation propriétaires telles que VMWare ou Hyper-V ne semblent pas viables financièrement. Les licences VMWare sont exceptionnellement coûteuses, de même pour les licences Windows 2008 Server. Un grand cloud public basé sur ces technologies rendrait l’offre particulièrement peu compétitive. De plus, l’hébergeur dépendrait totalement de l’éditeur pour les fonctionnalités qu’il peut implémenter et n’aura que peu de marge pour innover. L’utilisation des outils propriétaires peut être viable financièrement dans le cadre de clouds privés de taille modeste bien que la gratuité de XenServer de Citrix ne facilite pas l’adoption.

La mise en réseau du stockage

Tandis que les deux premières technologies sont visibles par les utilisateurs des clouds, le troisième l’est nettement moins. Traditionnellement, les unités de stockage de masse sont connectées directement sur les serveurs. Concrètement, cela se traduit par la connexion des disques dur directement sur le bus ATA ou SCSI de chaque serveur. Cette forme de stockage a comme avantage d’être particulièrement simple mais a comme désavantage d’être très peu flexible.

La mise en réseau des éléments de stockage à travers le SAN (Storage Area Network) a permis de s’affranchir de nombreuses contraintes. Cette flexibilité exceptionnelle a permis aux clouds de pouvoir s’automatiser rapidement avec notament l’utilisation des techniques de snapshots ou de déduplication. De plus, le réseau de stockage a permis d’augmenter massivement les performances des IO permettant de pouvoir centraliser les données. Cette centralisation a rendu possible les techniques de migration automatique à chaud et de répartition de charge dynamique entre différents hyerviseurs.

Au final, les technologies du cloud computing sont plus simples à cibler que le concept global. J’aurais l’occasion d’évoquer et de traiter les réseaux de stockage en détail ultérieurement. Ces trois technologies sont des technologies « centrales » autour desquelles peuvent en orbiter de nombreuses autres.

Si vous n’êtes pas familier avec le vocabulaire spécifique à Xen, je vous renvois vers l’article traitant de la terminologie Xen. Si vous ne connaissez pas bien le projet Xen, je vous renvois vers la présentation de ce projet.

Domaine non privilégié : domU

Les domaines non privilégiés sont communément appelés « domU » (U comme unprivileged). Les domU sont l’équivalent des systèmes d’exploitation invités sur les plateformes de virtualisation classiques. Concrètement, ce sont les machines virtuelles qui s’exécuteront sur votre plateforme Xen. Ces systèmes d’exploitation s’installent une fois que vous avez un hyperviseur et un dom0 fonctionnel. Il existe de nombreux outils vous permettant d’installer des domU de manière plus ou moins simple et rapide.

Comme vous le savez surement, Xen est capable de faire de la paravirtualisation mais aussi de la virtualisation matérielle assistée. A chacun de ces types de virtualisation correspond un type de domaine non privilégié. Les domU de paravirtualisation sont appelés « domU standards » et les domU de virtualisation matérielle assistée sont appelés « domU HVM ». L’acronyme HVM signifie « Hardware-Assisted Virtual Machine ».

domU de paravirtualisation : domU standard

Nous allons tout d’abord nous intéresser aux domU dits « standards ». Les domU de paravirtualisation sont considérés standards car il s’agit des premiers domU qui ont été disponibles pour Xen et les seuls jusqu’à la version 3.0. Ceci s’explique par le fait que la paravirtualisation est la raison d’être du projet Xen et ce qui en a fait un projet inédit.

Du fait qu’il s’agisse de domU de paravirtualisation, il est nécessaire que l’OS de chaque domU standard ait été adapté pour l’hyperviseur Xen. Ceci se fait par le biais d’API spécifiques supportant les hypercalls. De très nombreux systèmes d’exploitation peuvent être placés en tant que domU par dessus Xen. Tous les Linux sont compatibles ainsi que certains BSD et OpenSolaris.

domU de virtualisation matérielle assistée : domU HVM

Lorsqu’un système d’exploitation n’a pas été adapté pour Xen, il est nécessaire de recourir à une technique de virtualisation plus classique. Il s’agit bien évidemment de la virtualisation matérielle assistée. Ce type de domU permet à Xen de supporter la quasi totalité des systèmes d’exploitation existants pour l’architecture x86.

Le module utilisé par Xen pour effectuer les opérations de virtualisation matérielle assistée est le module QEMU. La contre partie des domU HVM est une perte de performances plus importante que dans le cas d’un domU standard. Ceci s’explique par le fait qu’il est nécessaire d’effectuer beaucoup plus d’opérations d’émulation.

Rôle des domU et délégation de périphériques

Les domU n’ont pas de rôle spécifique au niveau de la plateforme de virtualisation. Ils servent juste à exécuter les diverses applications qui sont contenues dans leurs systèmes d’exploitation. Il ne leur est accordé, par défaut, aucun privilège au niveau des ressources physiques. L’hyperviseur leur attribue une partie des ressources dynamiquement et les domU les utilisent ou pas en fonction de leurs besoins.

De plus, il est tout de même possible d’accorder quelques priviléges spécifiques aux domU. Ces privilèges spécifiques se matérialisent par la délégation de périphériques. Par exemple, il est possible de donner accès exclusif à un port USB ou PCI à un domU. Ceci va lui permettre de pouvoir utiliser un composant physique comme il le souhaite. Il y a eu des exemples de cartes graphiques déléguées à un domU permettant de jouer à un jeu 3D dans le domU. Notons tout de même que la délégation de périphérique à un domU restreint totalement sa mobilité entre plusieurs hyperviseurs ce qui peut être handicapant.

Au final, cette article présente les spécificités des domU. J’espère avoir été clair et compréhensible. Si ce n’est pas le cas, vous avez toujours la possibilité de laisser un commentaire pour me le signaler. En ce qui concerne la suite des événements, je suis encore indécis sur les sujets que je vais traiter. Cela devrait varier en fonction de mon prochain emploi. De toute manière, je souhaiterais parler plus des réseaux de stockage et du stockage en général.

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.

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.

J’ai déjà eu l’occasion de feuilleter des livres de cette série. Ils sont plutôt bien faits. Si vous souhaitez vous le procurer, il va falloir passer par le site américain d’Amazon. Il faudra bien évidemment payer les frais de port à partir des Etats-Unis en attendant qu’il soit disponible en France. Vous pourrez vous le procurer sur le site français d’Amazon afin d’éviter de payer les frais de ports.

Le contenu semble assez large mais reste pratique. Il couvre des aspects particulièrement spécifique de Xen à savoir l’installation des domaines Solaris et NetBSD. Il parle également de la mise en place de QoS réseau sur Xen qui est un sujet qui m’intéresse particulièrement et qui est peu traité sur Internet.

Je vais envisager l’achat de ce livre qui semble particulièrement intéressant dès que mes finances le permettront. Je vous en ferait surement un petit compte rendu par la suite.

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 !