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.

Nouveau livre sur Xen

J’ai déjà eu l’occasion de vous parler de deux livres que j’ai lu sur Xen. Je viens de tomber sur un nouveau livre qui vient d’être publié. Il n’est pour l’instant disponible qu’en anglais. Si vous n’êtes pas anglophone, il faudra donc soit se mettre à l’anglais soit attendre la traduction française.

xen_big

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.

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 !

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.

La paravirtualisation

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

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

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

virtus

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

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

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

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