Virtualisation : les solutions gratuites

Introduction

MAJ : Vous pouvez consulter notre nouveau comparatif de solutions gratuites de virtualisation, avec les tests des derniers hyperviseurs.

Si la virtualisation n’est pas un concept réellement nouveau – Popek et Goldberg ayant dès 1974 jeté les bases des développements futurs, force est de constater que les solutions de virtualisation se sont multipliées ces dernières années, la technologie et le matériel étant arrivés à un certain degré de maturité.

Nous nous sommes déjà intéressés l’an dernier à cette technologie en réalisant un tour d’horizon des solutions de virtualisation alors disponibles. Nous vous invitons d’ailleurs à lire notre précédent dossier afin de découvrir, ou de redécouvrir, le fonctionnement technique de la virtualisation. Aujourd’hui, nous allons plus particulièrement nous intéresser à trois solutions gratuites destinées au marché des serveurs : Microsoft Hyper-V Server 2008 R2 (SP1), VMWare vSphere Hypervisor (ESXi) 4.1 et Citrix XenServer 6.

Virtualisation et paravirtualisation : comment, pourquoi ?

L’idée principale du concept de virtualisation est d’exécuter un système d’exploitation dans une machine virtuelle, chaque machine physique – chaque serveur – étant capable de faire tourner un certain nombre de machines virtuelles.

Optimisation et réduction des coûts

En pratique, virtualiser les serveurs d’une entreprise permet d’utiliser de façon optimale les ressources matérielles, tout en mutualisant la consommation électrique et la maintenance. Cela permet également d’optimiser l’installation, le déploiement et la migration des machines, et de faciliter la mise en production des serveurs. La virtualisation permet enfin de faciliter le dimensionnement des serveurs, la puissance CPU, l’espace de stockage ou la quantité de mémoire vive pouvant être alloué dynamiquement entre les serveurs virtuels. En résumé, la virtualisation permet de faciliter le travail d’administration d’un parc de serveurs, tout en optimisant la gestion des ressources matérielles, et donc le coût.

Comme tout système d’exploitation, un OS serveur est en charge de gérer les ressources matérielles de l’ordinateur (CPU, mémoire vive, périphériques, etc.). Il s’attend donc à avoir seul la gestion de toutes les ressources matérielles de l’ordinateur, et à pouvoir dialoguer directement avec le CPU. Dans un environnement virtualisé, il va donc falloir faire croire à chaque OS fonctionnant en parallèle qu’il est le seul à être installé sur la machine. C’est le rôle de l’hyperviseur, un système d’exploitation très simple intégrant le programme de virtualisation ou VMM (Virtual Machine Monitor). Celui-ci va se charger de simuler autant de machines virtuelles que de systèmes d’exploitation.

Virtualisation, paravirtualisation ou émulation ?

Plusieurs types de virtualisation existent, chacun ayant ses propres avantages et inconvénients. Ainsi, il existe des solutions de virtualisation complète, l’hyperviseur se chargeant de créer un environnement virtuel complet en simulant du « faux » matériel. Le système d’exploitation invité n’aura alors accès qu’à ces ressources simulées, et non aux ressources matérielles réelles. Ce type de virtualisation est toutefois limité aux systèmes d’exploitation prévus pour la même architecture matérielle (x86, x64, ARM, …) que le processeur physique de la machine hôte.

Pour dépasser cette limite, il faut faire appel à l’émulation : l’hyperviseur créé alors un environnement virtuel complet, en allant jusqu’à simuler un microprocesseur qui peut alors avoir une architecture matérielle différente de celle du CPU hôte. Le principal inconvénient de ce type de solution est alors le niveau de performances, souvent médiocre.

La paravirtualisation est un autre type de solution de virtualisation. Ici, le système d’exploitation invité est conscient de s’exécuter dans un environnement virtualisé, ce qui nécessite bien entendu certaines modifications logicielles. En contrepartie, il devient capable d’interagir avec l’hyperviseur et de lui demander, le cas échéant, de transmettre directement les appels systèmes au matériel du serveur hôte. Les performances « virtuelles » sont alors théoriquement proches de celles qu’il serait possible d’atteindre avec le matériel réel.

Les trois solutions gratuites que nous avons choisi de tester, à savoir Microsoft Hyper-V Server 2008 R2, VMWare vSphere Hypervisor (ESXi) 4.1.0 et Citrix XenServer 6, font justement partie des hyperviseurs capables de prendre en charge la paravirtualisation, sous certaines conditions.

Configurations de test

Remercions au passage Dell qui a mis à notre disposition du matériel adapté aux tests que nous souhaitions réaliser : un serveur Dell PowerEdge R310 sous Windows 2008 R2 qui va nous servir de station d’administration, un Dell PowerEdge R610 sous Windows 2003 servant de serveur Active Directory, un autre Dell PowerEdge R610 qui va héberger les différents hyperviseurs et une baie de stockage iSCSI EqualLogic PS6000, avec 8 To d’espace de stockage.

Microsoft Hyper-V Server 2008 R2 (SP1)

MAJ : Vous pouvez également consulter notre nouveau comparatif de solutions de virtualisation, avec le test d’Hyper-V 2012.

Microsoft est arrivé un peu tard sur le marché de la virtualisation pour serveurs, ce qui ne l’a pas empêché de rapidement proposer une solution viable baptisée Hyper-V. A l’origine uniquement disponible en tant que rôle dans Windows Server 2008 (la version finale a été publiée sur Windows Update en juin 2008), Hyper-V a par la suite été proposé (dès octobre 2008) en version stand-alone et gratuite, puis mis à jour en version R2 en septembre 2009.

Hyper-V Server 2008 R2 est plus ou moins une version Core de Windows Server 2008 R2 avec toutes les fonctionnalités d’Hyper-V activées, les autres rôles de Windows Server étant désactivés. Il n’y a donc pas d’interface graphique à proprement parler, et tout se passe en ligne de commande. La version R2 a au passage apporté l’intégration de Windows Powershell v2.

Pré-requis à l’installation

Au niveau des ressources matérielles nécessaires pour installer et faire fonctionner l’hyperviseur, Hyper-V Server 2008 R2 demande un (ou plusieurs) processeurs compatibles x64 prenant en charge VT-x ou AMD-V, 1 Go de mémoire vive au minimum pour fonctionner, ainsi que 8 Go d’espace de stockage.

La solution de Microsoft prend en charge les systèmes avec 8 processeurs physiques au maximum (64 CPU logiques) et jusqu’à 1 To de mémoire vive. Jusqu’à 384 machines virtuelles peuvent fonctionner sur une seule et unique machine physique, chaque VM ayant droit à un maximum de 4 processeurs virtuels x86 ou x64 et 64 Go de mémoire virtuelle.

Fonctionnalités

Les principales fonctionnalités d’Hyper-V Server 2008 R2 mises en avant par Microsoft sont le Core Parking qui permet de mettre en veille certains cœurs CPU inutilisés lorsque le nombre de VM ou leur charge diminue, la Live Migration (migration de VM entre deux hosts, sans interruption de services) ou encore le Live Backup (sauvegarde des VM sans interruption, grâce aux Volume Shadow Services). Le SP1 d’Hyper-V Server 2008 R2 apporte par ailleurs l’allocation dynamique de la mémoire en fonction de la charge, et Remote FX, un système qui autorise une expérience utilisateur identique à l’utilisation d’un ordinateur physique.

Hyper-V Server 2008 R2 fonctionne avec des unités logiques d’isolation, baptisées partitions, dans lesquelles s’exécutent les différents systèmes d’exploitation invités. Chaque partition enfant n’a accès qu’à une vue virtuelle des ressources matérielles, microprocesseur(s) compris.

L’hyperviseur est donc capable d’intercepter les interruptions du processeur pour les rediriger vers la ou les partitions adéquates. Hyper-V utilise au passage l’accélération matérielle proposée par les processeurs d’Intel et d’AMD en matière de virtualisation (Intel VT-x et AMD-V, ainsi que EPT et NPT pour la translation d’adresses mémoire entre les différents espaces d’adressage virtuels). Les appels à un périphérique virtuel réalisés par les partitions enfants sont quant à eux redirigés via le VMBus vers le périphérique réel.

Microsoft Hyper-V Server 2008 R2 (SP1) – suite

Installation et configuration

L’installation d’Hyper-V Server 2008 R2 s’effectue en mode graphique, à l’image de celle de Windows 2008 Server R2. Après le choix du langage et la validation du CLUF, nous avons droit à la copie et la décompression des fichiers, puis à l’installation des fonctionnalités et des mises à jour.

Après un redémarrage, le système nous demande enfin de définir le mot de passe d’administration. La configuration d’Hyper-V se déroule en revanche entièrement en ligne de commande, avec en particulier la configuration réseau (IP des cartes réseaux, DNS, …). Détail important : Hyper-V Server 2008 demande obligatoirement à joindre un domaine Active Directory.

Stockage des VM

Les machines virtuelles vont être stockées sur le SAN EqualLogic, il convient donc de configurer dans un premier temps celui-ci. Nous allons utiliser pour cela notre station d’administration, toute la partie configuration étant effectuée via un simple navigateur Internet. Nous avons donc créé sur notre SAN un volume de 384 Go qui servira à héberger les VM.

Du côté de l’hyperviseur, il va falloir lancer l’outil de configuration de l’Initiateur iSCSI (via la commande iscsicpl). Les services Microsoft iSCSI ne sont par défaut par lancés, mais l’outil nous propose de lancer le service et de le configurer pour qu’il se lance automatiquement. Il suffit ensuite d’aller se connecter sur la cible que l’on vient de créer, puis de créer et formater une partition NTFS sur le volume iSCSI (via la commande diskpart), et enfin lui attribuer une lettre (S par exemple).

Conversion P2V et création VM

S’il est possible de créer directement un serveur virtuel, on peut également choisir de convertir un serveur physique en machine virtuelle. On va donc pour cela utiliser un petit outil gratuit baptisé Disk2VHD que l’on va installer sur le serveur physique à convertir et qui va se charger de convertir la machine physique en une image VHD.

On notera au passage que System Center Virtual Machine Manager (SCVMM) 2008 R2, l’outil Microsoft dédié à l’administration des machines virtuelles et des hyperviseurs Hyper-V, permet également de convertir une machine physique en machine virtuelle. Mais cette solution est payante…

La création d’une nouvelle VM se déroule sur la station d’administration, en utilisation la console Server Manager. Le rôle Hyper-V doit donc être installé sur le système qui va servir à l’administration d’Hyper-V Server 2008 R2, et une ou plusieurs interfaces « Virtual Network » doivent être définies. On en profite pour configurer l’emplacement de stockage des machines virtuelles.

Il est ensuite possible de se connecter à distance à l’hyperviseur afin de créer la nouvelle machine virtuelle. On n’oubliera pas de définir la quantité de mémoire vive virtuelle et le nombre de vCPU, de régler les paramètres réseau et d’indiquer qu’il faut utiliser le fichier VHD précédemment créé. Il ne restera alors plus qu’à lancer cette machine virtuelle et à installer les outils d’intégration (Integration Services). Ce sont eux qui permettent d’utiliser la paravirtualisation…

VMWare vSphere Hypervisor (ESXi) 4.1.0

MAJ : Vous pouvez également consulter notre nouveau comparatif de solutions de virtualisation, avec le test de vSphere Hypervisor 5.1.

VMWare est présent sur le marché de la virtualisation depuis de nombreuses années, la première version d’ESX Server datant de 2001. Une version gratuite d’ESX, VMWare vSphere Hypervisor (ESXi), est également proposée depuis quelques années. Certaines des fonctionnalités d’ESX – rebaptisé vSphere depuis la version 4.0 – ne sont toutefois pas disponibles dans ESXi.

Pré-requis à l’installation

ESXi 4.1 demande un (ou plusieurs) processeur(s) compatible(s) x64 et un minimum de 2 Go de mémoire vive pour fonctionner. Il prend en charge un maximum de 1 To de mémoire vive physique et jusqu’à 64 cores. Jusqu’à 256 vCPU peuvent être créés, chaque VM pouvant avoir accès à un maximum de 255 Go de mémoire vive virtuelle.

La principale difficulté réside dans la compatibilité matérielle, en particulier au niveau des contrôleurs réseau et de stockage. Il convient donc avant tout de bien vérifier sur le Guide de Compatibilité Matérielle (HCG) si le serveur hôte et ses composants sont aptes à accueillir ESXi 4.1. Dans notre cas, aucun problème : le matériel que Dell nous a confié est parfaitement pris en charge par ESXi 4.1.

Fonctionnalités

Tout comme vSphere 4.0 (la solution de virtualisation payante de VMWare), VMWare ESXi repose sur le microkernel vmkernel. C’est ce dernier qui accède directement au processeur et à la mémoire de la machine hôte, utilisant au passage un mécanisme SBE (Scan-Before-Execution) pour prendre en charge certaines instructions critiques, privilégiées et/ou spéciales. Les autres ressources matérielles sont prises en charge par des modules additionnels.

L’un des avantages d’ESXi réside dans sa légèreté : l’hyperviseur occupe en effet moins de 200 Mo d’espace disque. ESXi est toutefois – et c’est logique – moins complet vSphere. Ainsi, on doit se contenter d’une console d’administration minimaliste (avec un shell destiné au support technique) en lieu et place d’un véritable environnement Linux. L’accès à l’hyperviseur via une liaison série est impossible, et le support SNMP n’est possible que sous certaines conditions.

VMWare vSphere Hypervisor (ESXi) 4.1.0 – suite

Installation et configuration

L’installation d’ESXi 4.1 se déroule entièrement en ligne de commande, à la manière de certaines distributions Linux. Relativement rapide, l’installation se termine par la définition du mot de passe root, et la configuration réseau.

Mis à part la configuration réseau et certaines opérations basiques, toutes les opérations d’administration s’effectuent à distance via une console d’administration, baptisée vSphere Client, à installer sur un poste. Très complète, cette console permet de configurer l’hyperviseur, de créer, modifier et supprimer des machines virtuelles, d’accéder aux différents logs et de surveiller des paramètres comme l’occupation CPU et mémoire, les temps d’accès et les débits. C’est également grâce à cette console d’administration que nous allons pouvoir mettre en place des réseaux virtuels (dédiés au stockage, à l’administration, …) grâce à plusieurs vSwitch.

Stockage des VM

Comme avec Hyper-V Server 2008 R2, les machines virtuelles vont être stockées sur notre SAN EqualLogic, dans un volume de stockage dédié. Du côté d’ESXi, il faut dans un premier temps activer l’initiateur iSCSI (désactivé par défaut), pointer le bon volume, puis formater le volume. ESXi 4.1 utilise un système de fichiers propriétaire baptisé VMFS (Virtual Machine File System), ici dans sa version 3. Jusqu’à 64 serveurs ESX(i) peuvent lire et écrire simultanément sur un même système de fichiers VMFS, les fichiers de chaque machine virtuelle étant bien entendu verrouillés.

Conversion P2V et création VM

Pour convertir une machine physique en machine virtuelle, VMWare propose un logiciel dédié, vCenter Converter, à installer sur le serveur à convertir. L’opération est extrêmement simple à réaliser puisqu’il suffit de se laisser guider par l’interface.

On se connecte donc à l’hyperviseur ESXi, on attribue un nom à la machine virtuelle de destination, on spécifie la banque de données de destination et on défini certaines options comme la quantité de mémoire virtuelle et le nombre de vCPU à allouer à la future VM, ou bien le nombre de contrôleurs réseaux. Il est même possible de modifier certains paramètres du système d’exploitation invité, comme les services automatiquement lancés. La conversion débute ensuite, et ne dure que quelques minutes. La machine virtuelle est alors automatiquement créée dans ESXi, et apparait dans vSphere Client. Il ne reste plus qu’à la démarrer et à installer les VMWare Tools…

Citrix XenServer 6

MAJ : Vous pouvez également consulter notre nouveau comparatif de solutions de virtualisation, avec le test de XenServer 6.1.

Citrix XenServer (Free) est une plateforme de virtualisation gratuite, basée sur l’hyperviseur open-source Xen. Si l’hyperviseur Xen existe depuis de nombreuses années (la version 1.0 date d’octobre 2003), le rachat de XenSource par Citrix ne date que de 2007. Quatre versions de XenServer existent : la version Free et les éditions Advanced, Enterprise et Platinum. Bien entendu, certaines fonctionnalités des versions payantes sont absentes de la version gratuite…

Pré-requis à l’installation

XenServer demande un processeur x86-64 pour fonctionner, cadencé à 1,5 GHz au minimum. Citrix recommande toutefois un (ou plusieurs) processeur cadencé à 2 GHz ou plus, et si possible multi-core. De plus, un processeur supportant les technologies Intel VT ou AMD-V est nécessaire pour faire tourner un système Windows dans une machine virtuelle.

La solution de Citrix demande par ailleurs un minimum de 2 Go de mémoire, et supporte jusqu’à 1 To de mémoire physique et jusqu’à 64 processeurs logiques.

Fonctionnalités

Contrairement à VMWare qui fait principalement appel à un système de « translation binaire » (via le mécanisme Scan-Before-Execution), XenServer combine virtualisation matérielle et paravirtualisation. Ainsi, lorsque le système d’exploitation invité ne peut pas être totalement paravirtualisé (c’est par exemple le cas des différents Windows), l’hyperviseur fait appel aux technologies de virtualisation matérielle Intel VT ou AMD-V.

Les interactions entre les machines virtuelles et le matériel sont gérées par le domaine de contrôle « Domain 0 », lui-même une machine virtuelle dotée de privilèges spéciaux. Hébergeant une instance optimisée de Linux, « Domain 0 » s’appuie sur les pilotes standards open source de Linux, offrant ainsi une compatibilité matérielle très étendue.

Citrix XenServer 6 – suite

Installation et configuration

L’installation de XenServer est relativement rapide, Citrix parlant de « 10 minutes pour passer à Xen ». Tout se déroule en ligne de commande, dans un style qui n’est pas sans rappeler l’installation de certaines distributions Linux. Une fois l’installation terminée, nous avons accès à une console permettant de configurer certains paramètres (en particulier au niveau du réseau).

L’interface d’administration, baptisée XenCenter, s’installe quant à elle sur n’importe quel poste Windows. Celle-ci donne accès à un certain nombre de réglages concernant l’hyperviseur. Il est également possible de créer, modifier, migrer et supprimer des machines virtuelles, ainsi que d’accéder à un certain nombre de logs et de surveiller des paramètres comme l’occupation CPU et mémoire, les temps d’accès et les débits.

Stockage des VM

XenServer est particulièrement souple au niveau du stockage des VM puisqu’il n’impose pas son propre système de fichiers sur des systèmes de stockage mais s’appuie plus directement sur les fonctionnalités de stockage natives. Nous avons donc ici aussi créé un volume de stockage dédié sur notre SAN iSCSI afin d’y stocker les machines virtuelles.

Conversion P2V et création VM

Citrix fournit une application dédiée, baptisée XenConvert, pour convertir un serveur physique en machine virtuelle. Il suffit pour cela d’installer cette application sur le serveur en question puis de se laisser guider. XenConvert se charge tout seul d’ajouter la MV au serveur XenServer. Il ne restera plus qu’à configurer les paramètres de la machine virtuelle avec XenCenter, avant de lancer celle-ci. L’installation des outils Xen sur l’OS client permettra entre autres le monitoring sous XenCenter de l’occupation mémoire et CPU…

IOmeter : IOPS (accès aléatoires)

Comparer les performances de plusieurs hyperviseurs entre eux n’est pas une tâche facile. Nous avons donc choisi d’analyser le comportement et les performances des machines virtuelles à l’aide d’un ensemble de benchs synthétiques, l’objectif étant d’essayer de mesurer les différents points critiques d’un serveur, en particulier les débits et IOPS en lecture et en écriture avec des accès séquentiels et aléatoires (depuis et vers notre SAN), et les performances des vCPU.

Pour cela, nous avons installé sur un Dell PowerEdge R610 Windows Server 2003 en tant que serveur de fichiers, un rôle que l’on trouve aujourd’hui encore dans de nombreuses PME. Ce serveur physique a ensuite été converti en machine virtuelle sur les trois hyperviseurs testés.

Les performances en lecture aléatoire des différents hyperviseurs se tiennent dans un mouchoir de poche, et ce quel que soit la taille des blocs (de 4Ko à 4Mo). Les performances du serveur physique sont logiquement (très) légèrement au dessus de tout le monde (+2% par rapport à ESXi en moyenne, +4% par rapport à Hyper-v et +6% environ par rapport à XenServer).

En écriture aléatoire en revanche, les performances du serveur physique sont inférieures – de 13% à 16% en moyenne – à celles des machines virtuelles, en particulier avec des blocs de 128 Ko ou moins. On peut raisonnablement supposer que les trois hyperviseurs mettent en place un tampon ou un cache supplémentaire lorsque les machine virtuelles réalisent des opérations d’écriture disque. Notons au passage la petite faiblesse de XenServer avec des blocs de 8Ko…

IOmeter : IOPS (accès séquentiels)

En accès séquentiel, les choses sont un peu plus claires : le serveur physique est sans surprise le plus rapide avec un peu plus de 6700 IOPS en lecture et 3800 IOPS en écriture, suivi par vSphere Hypervisor (12% plus lent que le serveur physique en lecture, 8% en écriture) et Hyper-V (respectivement -16% et -10%). Plus lent de 23% en lecture et de 17% en écriture (en moyenne) que le serveur physique, XenServer ferme la marche. Dans l’absolu, les machines virtuelles affichent tout de même des performances honorables.

Avec des blocs de 128 Ko et plus, les différences entre le serveur physique et les trois hyperviseurs sont en revanche quasi-nulles.

ATTO : Débits

Les débits atteignables en lecture et en écriture montrent ici aussi des différences entre les machines virtuelles, selon l’hyperviseur utilisé. Ainsi, si la machine physique affiche les performances les plus élevées (120 Mo/s en écriture, le réseau Gigabit étant à priori le goulot d’étranglement), on note que XenServer (avec des débits inférieurs de 26% en lecture et 17% en écriture à ceux du serveur physique) semble un cran en dessous des solutions de Microsoft (-18% en lecture, -13% en écriture) et de VMWare (-12% en lecture, -9% en écriture), lesquelles se tiennent dans un mouchoir de poche.

SuperPI, Sandra

La machine virtuelle sous Hyper-V a de manière surprenante purement et simplement refusé de lancer SuperPI Mod. Le serveur physique est encore une fois le plus rapide, mais cette fois-ci c’est la solution de Citrix qui s’en rapproche le plus. ESXi ferme la marche, avec un retard de 2m30 sur le serveur physique.

Sous Sandra Lite, quel que soit le test (sauf en bande passante mémoire), on remarque encore une fois que le serveur physique est le plus rapide. Les machines virtuelles sous Hyper-V et XenServer sont plus ou moins aussi rapides, tandis que la machine virtuelle sous ESXi est la plus « lente », même si les différences entre les trois hyperviseurs sont minimes.

Occupation mémoire

La gestion de la mémoire vive – une ressource qui peut rapidement se montrer très importante sur un serveur – est l’un des points cruciaux d’un hyperviseur. Et c’est justement ici que l’on va trouver des différences entre Hyper-V R2 SP1, vSphere Hypervisor 4.1 et XenServer 6.

Allocation dynamique de la mémoire

Il est ainsi possible d’allouer dynamiquement la mémoire vive (grâce à une technique appelée « ballooning », où un « ballon » se gonfle et se dégonfle dans la mémoire virtuelle de chaque VM, permettant ainsi de “recycler” la mémoire inutilisée) avec les solutions de VMWare et de Microsoft, bien que la prise en charge de cette fonctionnalité par Hyper-V R2 ne soit apparue que très récemment (avec le SP1). VMWare permet même d’ajouter de la mémoire virtuelle et des vCPU à une machine virtuelle en fonctionnement… Citrix a en revanche choisi de réserver cette fonctionnalité aux versions payantes de XenServer.

ESXi 4.1, Hyper-V R2 et XenServer se comportent également différemment lorsqu’il s’agit d’attribuer la mémoire vive aux machines virtuelles. Si les deux premiers allouent la mémoire en fonction des besoins des machines virtuelles, XenServer réserve d’office la quantité de mémoire définie dans les paramètres de chaque VM.

En conséquence, s’il est possible avec ESXi et Hyper-V de configurer et de lancer plusieurs VM avec une quantité totale de mémoire virtuelle supérieure à la quantité de mémoire physique réellement présente dans le serveur, XenServer (Free) refusera purement et simplement de lancer une VM s’il n’y a plus assez de mémoire disponible, et ce même si les VM déjà lancées n’utilisent pas toute la mémoire qui leur est allouée.

Page Sharing

VMWare ESXi est par ailleurs capable de concaténer ensemble des pages mémoires identiques des machines virtuelles, en une seule instance physique. En d’autres termes, le Page Sharing permet de partager une seule page mémoire physique entre plusieurs machines virtuelles, ce qui réduit d’autant la consommation de mémoire physique.

Cette méthode d’optimisation de l’utilisation de la mémoire est particulièrement efficace dès lors que les OS invités sont identiques.

Conclusion

Nous l’avons vu, si les hyperviseurs gratuits de Microsoft, VMWare et Citrix permettent de mettre en place un environnement virtualisé viable en entreprise, certaines limitations et absence de prise en charge – comme l’allocation dynamique de la mémoire avec XenServer, ou bien la tolérance de fautes, la migration à chaud des VM et du stockage ou encore les fonctions de haute disponibilité chez VMWare – peuvent parfois s’avérer gênantes. De plus, seuls les hyperviseurs sont gratuits : il ne faut pas oublier que l’administration de telles solutions peut parfois demander des compétences et connaissances spécifiques, qui ont un coût.

La gestion et l’administration des hyperviseurs et des serveurs virtuels est d’ailleurs l’aspect le plus important à retenir lorsqu’il s’agit de choisir entre une solution gratuite et une autre, payante. Les solutions gratuites montrent en effet rapidement leurs limites lorsqu’il s’agit d’administrer, de migrer et de déployer un grand nombre de machines virtuelles, sur un nombre conséquent d’hyperviseurs.

En résumé, s’il s’agit de virtualiser quelques serveurs dans une PME, une solution gratuite suffira largement. Pour une petite structure, nous nous tournerions plutôt vers vSphere Hypervisor 4.1 (si vous disposez de matériel certifié et/ou supporté) en raison du module d’administration très complet et des performances globales de l’hyperviseur. Hyper-V R2 n’est pas non plus une mauvaise solution… Si, en revanche, il s’agit de virtualiser un parc important de plusieurs dizaines ou centaines de serveurs, il devient plus raisonnable de se tourner vers l’une des solutions payantes que proposent les trois éditeurs.