L'hyperviseur de type 1 ou hyperviseur natif, est, contrairement au type 2, installé directement sur le matériel, sans OS intermédiaire.
Cela signifie qu’avec un hyperviseur de type 1, les ressources de l’hôte sont directement gérées par l’hyperviseur et non plus par l’OS qui disparaît ou est relégué au statut de VM.
Ce principe est très clair dès lors qu’on installe ESXi (l’hyperviseur de VMWare vSphere), qui, vous le verrez, efface complètement votre système d’exploitation et vos données avant de les remplacer.
Reprenons notre schéma de l’arbre, et voyez comme un hyperviseur de type 1 simplifie les choses par rapport à son homologue de type 2 :
Ici, la machine hôte est dédiée à la création de VM et ne sait faire plus que cela.
Si ce type d’hyperviseur s’utilise dans un contexte complètement différent de l’hyperviseur de type 2, cela vient principalement de ses performances bien supérieures, rendues possibles car :
d’une part, l’hyperviseur a un accès direct aux ressources (sans passer par un OS) ;
d’autre part, la totalité des ressources est dédiée aux VM.
Les hyperviseurs de type 1 sont utilisés en entreprise pour plusieurs raisons, comme par exemple :
réduire les coûts matériels et de maintenance ;
optimiser les ressources physiques ;
répartir la charge dynamiquement ;
permettre la haute disponibilité des serveurs ;
créer des VM de préproduction pour les tester en environnement réel avant de les mettre en production.
Comparez les différents hyperviseurs de type 1
Il est très difficile de comparer les différents hyperviseurs de type 1 car étant des solutions pour entreprises, ils sont commercialisés avec différents niveaux de licences, de fonctionnalités et de prix.
Ajoutez à cela qu’il est assez rare, en tant que professionnel de l’informatique, de devoir choisir parmi ces solutions, tout simplement car :
lorsque vous arriverez dans une entreprise, une solution de virtualisation sera déjà en place, et c’est donc celle-ci que vous utiliserez ;
les choix se font plus souvent sur des critères politiques que technologiques. Si votre entreprise a déjà signé des contrats chez certains fournisseurs qui sont en partenariat de près ou de loin avec un des professionnels de la virtualisation, il est très probable que c’est cette solution qui soit choisie.
Cependant, il peut être intéressant de connaître les tendances du marché afin d’avoir une idée des clients cibles de chacun des grands acteurs de la virtualisation.
Hyperviseur | ESXi | Hyper-V | KVM | Xen |
Noms des solutions commerciales | vSphere | Hyper-V |
|
|
Clients majoritaires | Grandes entreprises | Moyennes et grandes entreprises | Entreprises de cloud public | Entreprises de cloud public |
Arguments de vente | Leader du marché, fiabilité, innovation | Scalabilité Flexibilité Performant avec les VM Windows En forte progression | Très modulable Open source En forte progression | Open source Leader des acteurs du cloud |
Exemples de clients |
|
|
|
|
Part de marché (en 2018) | 64 % | 17 % | 19 % incluant KVM et Xen | 19 % incluant KVM et Xen |
En termes de prix, il est difficile de les comparer étant donné les différents niveaux de licence ; mais si l’on se base sur des niveaux de services équivalents, sur des déploiements typiques d’entreprise, vSphere est sans aucun doute le plus cher, suivi de près par Hyper-V.
Pourquoi cette confusion ?
Avec ESXi c’est simple, il n’y a tout bonnement plus d’OS, car ESXi le remplace. Donc pas de confusion.
Avec Hyper-V, cela est moins évident car vous installez dans un premier temps Windows et ensuite Hyper-V. On est donc tenté de se dire qu’Hyper-V est installé en tant qu’application par-dessus l’OS et qu’il n’a donc pas la main sur les ressources de la machine hôte. Or, c’est faux, car lorsque vous installez Hyper-V, le système est modifié en profondeur et votre OS Windows devient alors une VM de manière complètement transparente pour l’utilisateur.
Xen utilise le même principe : votre OS principal devient une VM.
Pour KVM, c’est un peu différent. Le module KVM installé sur un système Linux va modifier le noyau Linux pour pouvoir accéder directement aux ressources matérielles. Il y a donc plusieurs façons d’implémenter l’accès direct aux ressources de la machine hôte sans avoir forcément à supprimer complètement l’OS, comme le fait ESXi.
En résumé : le besoin détermine le type d’hyperviseur
Contexte | Exemples de cas métiers | Hyperviseur | Profil des utilisateurs de l’hyperviseur |
En entreprise ou pour un usage personnel |
| type 2 | Profils multiples :
|
En entreprise, dans des architectures en production |
| type 1 | Profils orientés réseau :
|