Premiers pas sur Solaris ou OpenSolaris

solarisLors d’un précédent article, j’ai eu l’occasion de vous présenter dans les grandes lignes le système d’exploitation Solaris. Je vous ai fait une petite démonstration de tous les avantages que pouvait présenter un passage vers ce système d’exploitation. Entre temps, j’ai eu l’occasion de passer ma machine virtuelle Xen sous OpenSolaris en utilisant le processus évoqué précédemment. Je vais donc, à travers, cet article faire un petit retour d’expérience sur une première mise en place et utilisation d’OpenSolaris.

Solaris ou OpenSolaris ?

La première question que l’on se pose lorsqu’on souhaite passer à Solaris est « Dois-je choisir Solaris ou OpenSolaris ? ». Avant de pouvoir répondre à cette question, il va falloir distinguer les deux variantes. OpenSolaris n’est pas forcément beaucoup plus open source que Solaris étant donné que les deux variantes disposent plus ou moins des mêmes applications.

OpenSolaris est la version « communautaire » de Solaris. Pour faire une comparaison simpliste, OpenSolaris est à Solaris ce qu’est Debian Sid à Debian Lenny. De toute manière, les deux variantes sont disponibles gratuitement sur Internet. Une différence notable est que vous n’aurez les mises à jour de sécurité Solaris 10 que 6 mois après leur publication alors que vous aurez celles d’OpenSolaris immédiatement.

Si vous venez du monde Linux, je vous conseille fortement OpenSolaris car vous aurez plus de repères que dans Solaris.

L’installation

Je vous préviens d’entrée de jeu, OpenSolaris risque de vous décevoir à l’installation. En effet, il est nécessaire de passer par une interface graphique pour l’installer. Il faut donc 512 Mo de RAM au moins pour pouvoir l’installer. Je sais que cela va frustrer certaines personnes mais il semble un peu simpliste de s’arrêter à un tel détail. Si vous souhaitez effectuer l’installation sans interface graphique, vous pourrez toujours vous pencher sur Solaris. De toute manière, l’interface graphique est très simple à désactiver.

L’installation se déroule de manière tout à fait conventionnel avec le traditionnel « Suivant ». Je vous conseille fortement de choisir le système de fichier ZFS même si vous avez tout de même la possibilité de rester sur UFS (Unix File System). Je n’ai pas eu de difficulté particulière et je pense que vous ne devrez pas en avoir non plus.

Interface en ligne de commande

Lorsque vous avez démarré OpenSolaris, vous allez probablement supprimer le démarrage de l’interface graphique. Ceci se fait via le SMF de manière tout à fait simple. Pour lister les services, vous pourrez utiliser la commande svcs. Pour activer ou désactiver des services, vous pourrez ensuite utiliser svcadm disable/enable. Si vous cherchez les scripts init.d, il n’y en a que très peu et c’est normal. SMF remplace les scripts init.d rappellez-vous.

Vous risquez d’être assez vite frustré par le shell proposé par défaut. Le shell par défaut dans Solaris est csh. Si vous vouliez découvrir un shell utilisé par les dinosaures, vous trouverez votre bonheur. Sinon, je vous conseille de passer directement à bash en tapant la commande bash tout simplement. Vous pourrez également simplement installer zsh.

L’utilisation de vim est assez rudimentaire. Il va falloir retourner aux bases car bon nombres de raccourcis ne sont pas présents. Je ne me l’explique pas mais autant que vous soyez prévenus car c’est assez dissuasif.

Commandes qui sauvent la vie

Je vous ai déjà prévenu, lorsque vous passez à Solaris vous perdez tous les jolis automatismes que fournissent les distributions Linux standards. Le meilleur exemple est la commande halt qui disparait. Pour éteindre votre machine, il faudra forcer le run-level 0 via la commande init 0. Pour rebooter votre machine, il faudra forcer le run-level 6 via la commande init 6. Comme vous pouvez le constater, pour utiliser Solaris, il faut une connaissance approfondie d’Unix ou bien la volonté de l’acquérir.

Au final, je pense avoir fait un rapide retour d’expérience de la prise en main d’OpenSolaris/Solaris. Vous pouvez penser qu’il s’agit d’un Unix préhistorique étant donné des mécanismes assez compliqué mis en place. Vous avez cependant pas tord sur certains aspects mais vous avez totalement tord sur d’autres aspects. Je pense que les cotés « préhistoriques » sont composés par les nouveautés. Je pense également possible qu’il est possible de faire abstraction des ces problèmes et de s’adapter.

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.

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 !

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.