Hyper-V ou VMWare : quel hyperviseur choisir ?

A travers ce poste, je vais essayer d’apporter une réponse objective à la question « Quel hyperviseur choisir ? » Toujours basé sur mon expérience.

Je vais avouer que je ne serais peut-être pas très objectif ayant tout de même une préférence pour Hyper-V.

Ayant régulièrement à faire aux deux systèmes d’exploitation, je trouve que l’utilisation quotidienne du produit Microsoft est plus pratique.

Dans 75% du temps, je suis face à des ESX en Essential et je trouve le niveau de fonctionnalité très limité par rapport aux prix de la licence.

Je vais essayer d’expliquer cela par des cas concrets comparant les deux hyperviseurs :

Déplacement des fichiers d’une machine virtuelle :

Vmware

Appel d’un client qui me demande d’augmenter le volume d’un disque.

Pas de soucis, je me connecte à son infrastructure pour augmenter son vmdk.

Problème : la lun est quasiment pleine, je me dis pas soucis, je déplace le stockage de la VM sur une autre LUN et je fais l’augmentation du disque.

Je me lance donc dans la manipulation et au moment de valider, message de VMWare qui m’informe que la machine doit être éteinte.

J’informe le client que je vais devoir stopper la machine pour la manipulation, impossible à faire en pleine journée !

Hyper-V

Dans mon ancienne entreprise, j’ai dû monter un cluster Hyper-V et n’ayant pas le budget initiale pour la baie de stockage, j’ai utilisé pendant 6 mois un NAS pour présenter les volumes.

Six mois passent et je reçois ma baie, je la configure et je présente les volumes aux clusters.

Je vais dans l’interface de gestion du cluster Hyper-V et je me lance dans le déplacement des VMs du NAS au SAN à chaud en pleine journée sans que personne ne se rendent compte de rien.

Migration sur un nouveau serveur

Je vais prendre sur ce point deux cas concrets également.

Vmware

Un client souhaite changer l’ensemble de son cluster (2 serveurs + san) par du matériel neuf toujours dans la même configuration.

Les deux clusters sont sous licences Essential, déplacement à chaud on oublie ! L’ancienne baie étant en iSCSI avec 8TO à faire passer sur la nouvelle baie cela aurait été très long.

Contrainte imposée par le client : pas de coupure de VM pendant les heures de travail.

Deux options s’offrent à nous :

Solution 1 : je mets des licences ++ qui m’autorise le déplacement à chaud du stockage sur les deux clusters.

Solution 2 : on utilise son logiciel de sauvegarde (Veeam) pour faire des réplications des VMs sur le nouveau cluster.

On a opté pour la seconde solution qui nous permet également un Roll-back en cas de soucis.

Hyper-V

Même situation que le cas précédent à une différence l’infrastructure n’est pas en cluster, juste deux serveurs en standalone.

J’ai pu faire le déplacement à chaud des VMs en utilisant l’utilitaire de déplacement des machines virtuelles dans la console Hyper-V.

La seule contrainte a été de joindre les deux hyperviseurs au domaine Windows.

Gestion des cartes réseaux

Sur cette partie je vais prendre l’exemple d’un client en particulier, la méthode de gestion des VLAN peut vite devenir compliqué sur Vmware.

Le client dispose d’un cluster de 4 noeuds,  historiquement celui-ci a été monté avec deux serveurs, il a donc fait le choix de ne pas utiliser les vswitchs distribués.

Lors d’une intervention sur site, il me demande d’ajouter un vlan à son firewall qui va faire office de DMZ. Pour tester le bon fonctionnement, il me demande également d’ajouter ce vlan sur le cluster et c’est là que la partie fastidieuse commence, j’ai dû ajouter à la main sur les 4 ESXi le groupe de port.

Cette même manipulation sur Hyper-V aurait pris moins d’une minute en déclarant le vlan directement dans les paramètres de la VM et aurait suivi la machine sur tous les nœuds du cluster.

Mise en cluster

Là encore je ne vais pas être très tendre avec Vmware, la mise en cluster d’un ESXi en soit n’a rien de compliqué, je trouve juste les prérequis du vCenter très gourmand.

De plus l’appliance n’est pas très véloce et très stable (crash régulier du navigateur).

Là encore un cluster Hyper-V n’a pas besoin 8GB de Ram et de 120GO d’espace disque…

Administration

Là encore, je ne vais pas défendre Vmware sur les points suivant :

  • Interface web instable aussi bien en Java qu’en HTML5 (finalement le client Windows fonctionnait bien).
  • Trop d’option, si on ne connait pas où sont les options, on peut vite prendre 10 minutes pour faire une action qui en prend 5.
  • Interface de connexion au vm inutilisable :
    • pas de clavier Azerty
    • contrôler un Windows sans les vmtools faut jouer du raccourci clavier.

Un avantage de vmware est la gestion des ova et la possibilité de faire des templates.

D’un point de vue totalement personnel, je trouve les templates gadgets, à moins d’être OVH et de faire 100 VMs par jours, je n’en vois pas l’intérêt.

Prix

Si vous êtes dans un environnement full linux, je conçois l’achat de vmware (des vrais linuxien utiliseront KVM).

Dans un environnement où vous avez des VM Windows, je ne vois pas l’intérêt de vmware sachant que lors de l’achat de l’OS vous achetez également Hyper-V.

Conclusion

Pour en revenir au sujet de base, quel hyperviseur choisir ? Je ne vais pas avoir une réponse absolue sauf si vous avez besoin du vsan la seul vmware peut vous l’offrir(Depuis Windows 2016 il est impossible de faire de l’hyperconvengence).

La réponse est peut-être là, ai-je besoin de fonctionnalité avancé ? Dans 90% des cas, Hyper-V couvre l’ensemble des besoins en virtualisation et propose plus d’options que le bundle essential de vmware. Il est toujours possible d’acquérir SCVMM qui apporte le même niveau d’option que le vCenter.



Laisser un commentaire