Archive for March, 2013

quelques différences d’architecture entre Hyperviseur

Wednesday, March 13th, 2013

Dans cet article je vais tenter d’expliquer les différence entre les hyperviseurs les plus courant du marché, en l’occurence VMWare ESX, hyper-v et Xen.

Premier point à savoir, les 3 sont ce que l’on appel des “bare metal” hypervisor, c’est à dire qu’ils n’ont besoin d’aucun OS pour fonctionner (par comparaison le classique VMWare Player lui à besoin de windows ou linux). Malgré tout on verra que ce n’est pas aussi simple.

Autre élément, Xen et Hyper-V sont aussi ce que l’on appel de “paravirtualiseur”, ce qui veut dire qu’ils peuvent faire tourner des invités modifié, utilisant des APIs dédiés dans le but d’amélioré les performances de virtualisation (cela permet par exemple d’utiliser des processeurs qui n’ont pas de jeux d’instructions dédié à la dite virtualisation comme “vt-x” ). Dans le cas de Xen on parle de mode PV ou HVM (Hardware Assisted Virtualization)

la ou les différences apparaisse c’est sur la mise en œuvre de ce fameux “bare-metal”.

Dans le cas d’Hyper-v, on va avoir un noyau qui va crée une première partition (ou invité, dom0 en langage Xen) dans lequel on va retrouver tous les drivers et en l’occurrence ce sera un windows bien sûr. Dans le cas de VMware on va également trouver un noyau (le vmkernel), c’est également lui qui va charger les driver, mais cette fois ils vont se retrouver dans une zone utilisateur dédié et sans privilège. Dans Xen, on va retrouver le comportement d’Hyper-V : l’hyperviseur va crée un premier invité le fameux dom0) dans lequel les drivers seront chargés, par contre à la différence d’hyper-v l’OS n’est pas imposé même si en pratique c’est en majorité du Linux. En pratique, quelle différence cela fait-il ? Et bien se qui peux se passer, c’est que votre partition principale plante pour une raison quelconque. Dans ce cas, vous perdez toutes communication avec le monde extérieur, dans le cas de VMware ce sont des processus séparés, donc tout n’est pas perdu…D’ailleurs pour palier à ce problème, les utilisateurs avancé de Xen crée de plus en plus de invités dédié à chaque driver, on se rapproche ainsi du comportement de VMware avec un avantage supplémentaire dans ce cas : si un invité-driver plante on peut le relancer facilement, voir faire des mise a jours des drivers en live (si, si ça marche ! )

 compare

Dans la serie de différences, due à ce comportement on va trouver aussi un autre point. Ce que l’on peux qualifier d”’”administrative OS”, ce qui représente plus ou moins le moyen que l’on a d’interagir/configurer le noyau de l’hyperviseur. Comme on a pus le constater avec Hyper-v, ce moyen passe par la partition première qui est aussi un OS complet… On voit tout suite ici ce que cela peut impliquer en terme de sécurité d’autant plus que l’on peut y installer n’importe quelle application sans restriction.  Du coté de Xen c’est un peu le même combat, on l’a vus précédement, cependant son coté OS indépendant limite un peu plus ce mauvais point. Du coté de ESX, le point d’entré est une console intégré dans sa propre partition complètement indépendante (au passage pour la petite hisoire, un ESX utilise un boot loader de type redhat, mais dans le processus d’init du kernel RHEL il charge son code en mémoire, puis switch dans celui-ci, crée une première machine virtuel et y place toute la partie bootstrap ainsi que sa console, yep !), il ne reste donc d’accessible que les commandes d’administration (un peu à la manière d’un switch ou d’un busybox)

voila vous en savez un peu plus, pour mieux comprendre ce qui se passe.