Aller au contenu principal

Hyperviseurs

Un hyperviseur est un logiciel, un micrologiciel ou un composant matériel qui crée et gère des machines virtuelles (VMs) sur un serveur physique. Il agit comme une couche d'abstraction entre le matériel et les systèmes d'exploitation invités, permettant à plusieurs environnements isolés de coexister sur une même machine.

Le terme "hyperviseur" vient du mot "superviseur" : là où un système d'exploitation supervise les applications, l'hyperviseur supervise les systèmes d'exploitation eux-mêmes. On parle aussi de VMM (Virtual Machine Monitor).

Rôle dans la virtualisation​

L'hyperviseur remplit plusieurs fonctions essentielles :

  • Partitionnement des ressources : il divise le CPU, la mémoire, le stockage et le réseau du serveur physique entre les machines virtuelles.
  • Isolation : chaque VM fonctionne dans un espace cloisonné. Un plantage ou une faille de sécurité dans une VM n'affecte pas les autres.
  • Abstraction matérielle : les VMs voient du matériel virtualisé standardisé, indépendamment du matériel physique sous-jacent. Cela permet de migrer une VM d'un serveur à un autre sans reconfiguration.
  • Gestion du cycle de vie : création, démarrage, arrêt, snapshot, migration à chaud des machines virtuelles.

Sans hyperviseur, chaque application nécessiterait un serveur physique dédié, avec un taux d'utilisation moyen de 10 à 15 %. La virtualisation permet d'atteindre des taux d'utilisation de 60 à 80 %, réduisant le nombre de serveurs nécessaires et donc les coûts d'infrastructure.

Type 1 vs Type 2 : les deux catégories d'hyperviseurs​

Hyperviseur de Type 1 (bare-metal)​

L'hyperviseur de Type 1 s'installe directement sur le matériel du serveur, sans système d'exploitation hôte intermédiaire. Il a un accès direct au CPU, à la mémoire et aux périphériques.

Caractéristiques :

  • Performances quasi-natives (overhead de 1 à 5 % selon la charge de travail)
  • Accès direct aux instructions de virtualisation du processeur (Intel VT-x, AMD-V)
  • Adapté à la production et aux environnements critiques
  • Nécessite du matériel serveur dédié

Exemples :

  • KVM (Kernel-based Virtual Machine) : module intégré au noyau Linux depuis 2007. Chaque VM est un processus Linux standard, ce qui permet de bénéficier de l'ordonnanceur et de la gestion mémoire du noyau.
  • VMware ESXi : hyperviseur propriétaire de VMware (Broadcom depuis 2023). Longtemps la référence dans l'entreprise, il impose un modèle de licence par CPU.
  • Microsoft Hyper-V : intégré à Windows Server. Disponible aussi en version autonome (Hyper-V Server), bien que Microsoft ait arrêté cette édition gratuite en 2021.
  • Xen : hyperviseur open source utilisé notamment par AWS pour ses premières générations d'instances EC2. Aujourd'hui moins répandu au profit de KVM.

Hyperviseur de Type 2 (hosted)​

L'hyperviseur de Type 2 s'installe comme une application au-dessus d'un système d'exploitation existant (Windows, macOS, Linux). Il dépend de l'OS hôte pour accéder au matériel.

Caractéristiques :

  • Plus simple à installer (comme n'importe quel logiciel)
  • Overhead plus important (l'OS hôte consomme des ressources)
  • Adapté au développement, aux tests et à l'apprentissage
  • Ne convient pas à la production à grande échelle

Exemples :

  • VirtualBox (Oracle) : gratuit, multiplateforme, largement utilisé pour le développement local.
  • VMware Workstation (Windows/Linux) et VMware Fusion (macOS) : solutions payantes avec des fonctionnalités avancées (snapshots chaînés, réseaux virtuels complexes).
  • Parallels Desktop (macOS) : optimisé pour exécuter Windows sur Mac, y compris sur les puces Apple Silicon.
  • QEMU seul (sans KVM) : fonctionne en mode émulation pure, sans accélération matérielle. Utile pour émuler des architectures différentes (ex. : exécuter du ARM sur x86).

Résumé Type 1 vs Type 2​

CritèreType 1 (bare-metal)Type 2 (hosted)
InstallationDirectement sur le matérielSur un OS existant
PerformancesQuasi-natives (< 5 % overhead)Overhead notable (5-15 %)
Usage principalProduction, data centersDéveloppement, tests
ExemplesKVM, ESXi, Hyper-V, XenVirtualBox, VMware Workstation
SécuritéSurface d'attaque réduiteDépend de la sécurité de l'OS hôte

En production et dans le cloud, seuls les hyperviseurs de Type 1 sont utilisés. Tous les fournisseurs cloud majeurs reposent sur KVM (Google Cloud, AWS depuis 2017 avec Nitro, Oracle Cloud) ou sur des variantes propriétaires dérivées de KVM.

Comparaison des hyperviseurs de Type 1​

Le tableau ci-dessous compare les quatre hyperviseurs de Type 1 les plus répandus en 2024-2025.

CritèreKVMProxmox VEVMware ESXiMicrosoft Hyper-V
LicenceOpen source (GPL v2)Open source (AGPL v3)Propriétaire (Broadcom)Inclus avec Windows Server
CoûtGratuitGratuit (support payant en option)Licence par CPU, à partir de ~5 000 $/an par socketInclus dans la licence Windows Server (~1 000-6 000 $/an)
Base techniqueModule du noyau LinuxKVM + QEMU + LXC + interface webVMkernel propriétaireHyperviseur Microsoft
Overhead CPU< 2 %< 2 % (c'est KVM dessous)2-5 %5-10 %
Interface d'administrationCLI (virsh, virt-manager)Interface web intégréevSphere Client (payant séparément)Hyper-V Manager, SCVMM
ConteneursNon (via Podman/Docker en VM)Oui (LXC natif)NonNon (via Windows Containers)
Stockage distribuéVia Ceph, GlusterFS, etc.Ceph intégrévSAN (licence additionnelle)Storage Spaces Direct (S2D)
Migration à chaudOuiOuiOui (vMotion, licence additionnelle)Oui
APIlibvirt (REST/SDK)REST API complètevSphere API (SDK propriétaire)PowerShell, WMI
CommunautéTrès large (noyau Linux)Active (~100 000 installations)En déclin depuis le rachat BroadcomLiée à l'écosystème Microsoft
Vendor lock-inAucunAucun (données standard)Fort (formats VMDK, vSphere requis)Moyen (lié à Windows Server)

Points de vigilance sur VMware ESXi​

Depuis le rachat de VMware par Broadcom fin 2023, l'écosystème VMware a subi des changements majeurs :

  • Fin du free tier : ESXi gratuit (version standalone) n'est plus disponible depuis février 2024.
  • Passage aux abonnements : les licences perpétuelles ont été remplacées par des abonnements annuels, avec des augmentations de prix rapportées entre 200 % et 1 200 % selon les configurations.
  • Simplification forcée : la gamme de produits a été réduite à deux offres (VCF et vSphere Foundation), obligeant certains clients à payer pour des fonctionnalités qu'ils n'utilisent pas.
  • Fin du programme partenaires : de nombreux partenaires historiques ont été écartés du nouveau programme.

Ces changements ont accéléré la migration de nombreuses entreprises vers des solutions open source comme Proxmox VE et KVM.

Pourquoi France Nuage a choisi KVM et Proxmox VE​

France Nuage utilise Proxmox VE comme couche de gestion, s'appuyant sur KVM comme hyperviseur. Ce choix repose sur cinq piliers.

Pas de vendor lock-in​

Avec KVM et Proxmox, les données des clients sont stockées dans des formats ouverts et standardisés (QCOW2, raw). Un client peut à tout moment :

  • Exporter ses images disque et les réimporter sur n'importe quel autre hyperviseur KVM
  • Migrer vers un autre fournisseur cloud utilisant KVM
  • Monter sa propre infrastructure on-premise avec Proxmox

Cette réversibilité est un principe fondamental de la souveraineté numérique : le client reste propriétaire de ses données et de ses workloads, sans dépendance à un éditeur.

Souveraineté logicielle​

KVM fait partie du noyau Linux, le projet open source le plus audité et le plus transparent au monde. Le code source est public, vérifiable, et ne contient pas de backdoor. Aucune entreprise étrangère ne peut décider unilatéralement de modifier les conditions d'utilisation, d'augmenter les prix ou d'arrêter le produit.

Proxmox VE est développé par Proxmox Server Solutions GmbH, une entreprise autrichienne (UE). Le code est sous licence AGPL v3, garantissant que toute modification reste open source.

Performances natives​

KVM étant intégré directement dans le noyau Linux, il bénéficie des mêmes optimisations que le noyau lui-même :

  • Utilisation native des extensions de virtualisation matérielle (Intel VT-x/VT-d, AMD-V/Vi)
  • Overhead CPU mesuré en dessous de 2 % sur des charges de travail réelles
  • Accès direct aux fonctionnalités d'I/O passthrough (SR-IOV) pour les performances réseau et GPU
  • Gestion mémoire avec KSM (Kernel Same-page Merging) et les huge pages

Gestion simplifiée avec Proxmox​

Proxmox VE apporte une couche d'administration au-dessus de KVM qui rend les opérations quotidiennes accessibles :

  • Interface web complète pour créer, configurer et monitorer les VMs
  • Gestion intégrée du stockage distribué Ceph
  • Support natif des conteneurs LXC pour les charges légères
  • Système de backup intégré (Proxmox Backup Server)
  • Clustering et haute disponibilité sans logiciel tiers

Communauté et pérennité​

KVM est maintenu par des centaines de contributeurs, dont les ingénieurs de Red Hat, Intel, Google, IBM et AMD. Il est utilisé en production par les plus grands fournisseurs cloud au monde. Sa pérennité ne dépend pas d'une seule entreprise.

Proxmox compte plus de 100 000 installations dans le monde et une communauté active de contributeurs et d'utilisateurs.

Cas d'usage : quel hyperviseur choisir ?​

Le choix d'un hyperviseur dépend du contexte. Voici les recommandations par cas d'usage.

Développement et tests​

Recommandation : VirtualBox ou VMware Workstation (Type 2)

Pour un développeur qui a besoin de tester son application sur différents OS ou de reproduire un environnement de production localement, un hyperviseur de Type 2 est le plus simple. VirtualBox est gratuit et suffisant pour la plupart des besoins. VMware Workstation offre de meilleures performances et des fonctionnalités avancées pour les cas plus exigeants.

Production web et applications métier​

Recommandation : KVM/Proxmox VE ou cloud public basé sur KVM

Pour héberger des applications en production, un hyperviseur de Type 1 est indispensable. KVM avec Proxmox offre le meilleur rapport fonctionnalités/coût : performances natives, haute disponibilité, stockage distribué Ceph, le tout sans licence. C'est le choix retenu par France Nuage.

Cloud privé d'entreprise​

Recommandation : Proxmox VE (remplacement de VMware)

Pour les entreprises qui gèrent leur propre data center, Proxmox VE est aujourd'hui l'alternative la plus mature à VMware vSphere. L'interface web, la gestion du clustering, le stockage Ceph intégré et le support commercial optionnel en font une solution de production éprouvée. La migration depuis VMware est facilitée par les outils d'import de VMs au format VMDK.

Edge computing et sites distants​

Recommandation : KVM/Proxmox VE en cluster réduit

Pour les déploiements en bordure de réseau (usines, magasins, antennes), Proxmox peut fonctionner en cluster de 2 à 3 noeuds avec un stockage local répliqué. Sa légèreté et l'absence de licence en font un choix adapté aux déploiements distribués à grande échelle.

Environnement exclusivement Microsoft​

Recommandation : Hyper-V

Si l'ensemble de l'infrastructure repose sur Windows Server et Active Directory, Hyper-V est le choix le plus cohérent. Il est inclus dans la licence Windows Server et s'intègre nativement avec System Center et Azure Arc.

France Nuage : architecture hyperviseur​

Les hyperviseurs sont les serveurs physiques qui exécutent vos machines virtuelles sur France Nuage.

Vue d'ensemble​

France Nuage utilise Proxmox VE comme hyperviseur principal. Proxmox est une solution de virtualisation open source basée sur :

  • KVM (Kernel-based Virtual Machine) pour la virtualisation matérielle
  • QEMU pour l'émulation matérielle
  • LXC pour les conteneurs Linux

Architecture​

Abstraction​

Le Control Plane utilise une abstraction pour communiquer avec les hyperviseurs :

hypervisor_connector (trait abstrait)
    └── hypervisor_connector_proxmox (implémentation Proxmox)
    └── hypervisor_connector_resolver (résolution dynamique)

Cette architecture permet :

  • D'ajouter de nouveaux types d'hyperviseurs sans modifier le code existant
  • De tester l'intégration avec des mocks
  • De basculer entre hyperviseurs selon les besoins

Gestion des hyperviseurs​

  • Enregistrement : Ajouter un nouveau cluster Proxmox au Control Plane
  • Détachement : Retirer un hyperviseur du Control Plane
  • Monitoring : Surveiller l'état de santé des hyperviseurs

Opérations sur les instances​

L'hyperviseur exécute les opérations demandées par le Control Plane :

OpérationDescription
CloneCréer une instance à partir d'un template
StartDémarrer une instance
StopArrêter une instance
DeleteSupprimer une instance

Haute disponibilité​

Les clusters Proxmox sont configurés pour la haute disponibilité :

  • Stockage partagé Ceph : Les disques des VMs sont répliqués
  • Migration à chaud : Les VMs peuvent être déplacées entre noeuds sans interruption
  • Fencing : Isolation automatique des noeuds défaillants

Questions fréquentes​

Quelle est la différence entre KVM et Proxmox VE ?​

KVM est le composant de virtualisation intégré au noyau Linux. Il fournit la capacité de créer et d'exécuter des machines virtuelles, mais son interface native est en ligne de commande (virsh). Proxmox VE est une distribution Linux complète qui intègre KVM, QEMU, LXC et une interface web d'administration. Dit simplement : KVM est le moteur, Proxmox est le tableau de bord.

Est-il possible de migrer des VMs VMware vers KVM/Proxmox ?​

Oui. Les images disque au format VMDK (VMware) peuvent être converties au format QCOW2 (KVM) avec l'outil qemu-img convert. Proxmox inclut aussi un assistant d'import qui simplifie cette opération. Les métadonnées de la VM (CPU, mémoire, réseau) doivent être reconfigurées manuellement, mais les données sur disque sont préservées intégralement.

KVM est-il adapté aux charges de travail exigeantes (bases de données, IA) ?​

Oui. KVM supporte l'I/O passthrough (SR-IOV) pour fournir un accès direct aux cartes réseau et aux GPU, ce qui est indispensable pour les charges de travail IA et le calcul haute performance. Les benchmarks montrent des performances indiscernables du bare-metal pour les workloads CPU-intensifs, et un overhead inférieur à 3 % pour les I/O disque avec virtio.

Pourquoi les grands cloud providers utilisent-ils tous KVM ?​

Google Cloud utilise KVM depuis ses débuts. AWS a migré de Xen vers KVM (via son hyperviseur Nitro) en 2017. Oracle Cloud Infrastructure utilise KVM. La raison est technique : KVM fait partie du noyau Linux, ce qui signifie qu'il bénéficie automatiquement de chaque amélioration du noyau (ordonnanceur, gestion mémoire, pilotes matériels, correctifs de sécurité). Aucun hyperviseur propriétaire ne peut suivre le rythme de développement du noyau Linux, qui reçoit des contributions de milliers d'ingénieurs chaque année.

Prochaines étapes​