Introduction à la virtualisation : VM, hyperviseurs, premières VM

15 min

Par Stéphane Robert mis à jour le 15 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

La virtualisation fait tourner plusieurs machines virtuelles isolées sur un même serveur physique, chacune avec son propre noyau, son système et ses ressources. Cette page ouvre la formation Introduction à la virtualisation, le tronc commun à suivre avant tout hyperviseur. Elle s'adresse aux administrateurs système, DevOps et SRE débutants qui savent utiliser Linux en ligne de commande. En environ une heure de cours pour le cœur, elle vous fait expliquer ce qu'une VM partage avec son hôte, choisir un hyperviseur et un format de disque, puis suivre la checklist de création d'une première VM de type 2 sur votre poste. Elle débouche sur les formations d'exploitation KVM, Proxmox VE et Incus.

Ce que vous allez apprendre

Expliquer ce qu'est une machine virtuelle et ce qu'elle partage avec son hôte
Distinguer une VM d'un conteneur et d'une micro-VM, et savoir quand choisir l'une ou l'autre
Choisir entre un hyperviseur de type 1 et de type 2 selon le contexte
Choisir le format et l'allocation du disque d'une VM
Vérifier qu'une machine sait faire tourner des VM, puis suivre la checklist de création d'une première VM de type 2
Situer KubeVirt et les formations KVM, Proxmox VE et Incus qui prolongent celle-ci

Comment la formation est-elle organisée ?

La formation suit l'ordre des questions qu'on se pose, de « qu'est-ce qu'une VM ? » à « comment en créer une ? ». Un module de théorie courte, un module de première pratique, puis un module facultatif qui élargit à Kubernetes. Le programme détaillé, avec votre progression leçon par leçon, est sur la page Mon parcours.

Le tableau reprend les modules du parcours avec leurs leçons et leurs durées. Les durées sont celles du plan de formation.

Module	Ce que vous y faites	Durée des leçons
Comprendre	VM, types d'hyperviseur, isolation face aux conteneurs, disques virtuels	10, 10, 20 et 15 min
Premières VM sur son poste	Checklist de départ, création guidée et vérification d'une première VM de type 2	45 min
Des VM dans Kubernetes (facultatif)	KubeVirt : objets, installation sur un cluster de lab, création d'une VM	10, 5, 10 et 25 min

Comprendre

Le premier module pose le vocabulaire et les modèles mentaux qui resservent quelle que soit la plateforme retenue. Il commence par Qu'est-ce qu'une machine virtuelle ?, qui définit VM, hyperviseur et ressources partagées sans prérequis. Il compare ensuite les deux types d'hyperviseur dans Type 1 vs Type 2, puis place la VM face aux conteneurs et aux micro-VM dans Mutualisation et isolation, une leçon que la formation Cloud partage. Il se termine par le disque de la VM, avec RAW contre QCOW2 et l'allocation fine ou épaisse, qui décident des performances et de la place occupée.

Premières VM sur son poste

Ce module met la théorie en main. La leçon Créer une VM de type 2 donne la checklist de départ (image, processeur, mémoire, disque, réseau), vous guide dans l'assistant de création de VirtualBox, VMware Workstation ou Parallels, et dit comment vérifier que la VM fonctionne. Elle suppose un hyperviseur de type 2 déjà installé : la leçon crée une VM, elle n'installe pas l'outil. Le module reste volontairement court. Il guide la création d'une première VM, mais ne couvre pas encore la configuration fine d'un hyperviseur (réseau virtuel, snapshots, export OVA).

Des VM dans Kubernetes (facultatif)

Ce module facultatif suppose les bases de Kubernetes (pods, manifestes, kubectl) et se lit après le reste. Il montre comment faire tourner des machines virtuelles comme des ressources Kubernetes avec KubeVirt : ses objets, son installation sur un cluster de lab et la création d'une VM. Les VM y deviennent des objets décrits en YAML et pilotés avec kubectl, donc soumis au même RBAC et au même GitOps que le reste du cluster.

Qu'est-ce que la virtualisation et à quoi sert un hyperviseur ?

La virtualisation découpe les ressources d'un serveur physique (CPU, mémoire, disque, réseau) en ressources virtuelles attribuées à des machines indépendantes, sous le contrôle d'un composant appelé hyperviseur. Chaque machine virtuelle croit disposer d'un ordinateur complet : elle démarre son propre noyau, son propre système de fichiers et ses propres services.

L'hyperviseur arbitre l'accès au matériel réel. Sur un processeur moderne, il ne simule pas les instructions : il s'appuie sur des extensions matérielles de virtualisation, Intel VT-x ou AMD-V, qui laissent le code de la VM s'exécuter directement sur le processeur physique. C'est ce qui rend une VM presque aussi rapide qu'une machine réelle. Sans ces extensions, selon l'hyperviseur, la VM passe par l'émulation logicielle, nettement plus lente, ou ne démarre tout simplement pas.

Les bénéfices tiennent en cinq points : un meilleur taux d'utilisation du matériel, l'isolation des charges, les snapshots pour revenir à un état antérieur, le clonage quasi instantané d'un modèle, et le pilotage par API qui rend tout cela automatisable avec Terraform ou Ansible.

Machine virtuelle ou conteneur : quelle différence ?

Une machine virtuelle embarque son propre noyau, un conteneur partage celui de l'hôte. Toute la différence de comportement découle de ce seul point : une VM accepte un autre système (Windows, un noyau différent) et offre une frontière d'isolation matérielle, mais elle démarre en dizaines de secondes ou plus ; un conteneur démarre en général en une seconde ou moins.

Les deux modèles cohabitent très bien. Le comparatif complet, avec les micro-VM qui visent le meilleur des deux, est dans la leçon Mutualisation et isolation, et le partage des ressources entre VM dans Qu'est-ce qu'une machine virtuelle ?.

Type 1 ou type 2 : quel hyperviseur choisir ?

Un hyperviseur de type 1 s'exécute directement sur le matériel, un hyperviseur de type 2 s'installe au-dessus d'un système d'exploitation déjà présent. Le type 1 (KVM, Proxmox VE, VMware ESXi) vise les serveurs, les clusters et la production ; le type 2 (VirtualBox) vise l'apprentissage, le développement et les tests sur un poste de travail.

Le cas de KVM revient souvent dans les discussions : c'est un module du noyau Linux, ce qui donne l'impression d'un type 2 installé sur un système. Il est pourtant souvent rangé en type 1, car le module transforme le noyau lui-même en hyperviseur. Ce classement fait débat, parce que Linux reste un système généraliste. La leçon Type 1 vs Type 2 détaille la comparaison, les hyperviseurs populaires et un guide de décision.

Comment vérifier que votre machine sait faire tourner des VM ?

La virtualisation matérielle se contrôle différemment selon le système de votre poste : une commande sur un hôte Linux, un onglet du Gestionnaire des tâches sous Windows. Le contrôle prend dix secondes et évite de perdre une heure sur une installation qui ne pouvait pas aboutir. Faites-le avant la première VM du module « Premières VM sur son poste ».

Sur un hôte Linux

Lancez le contrôle sur le système installé sur la machine, pas dans WSL2 ni dans une VM : dans une VM, la réponse 0 signifie seulement que la virtualisation imbriquée n'est pas exposée à l'invité. La commande suivante dit si le processeur expose VT-x (Intel) ou AMD-V (AMD).

# Le processeur expose-t-il VT-x (Intel) ou AMD-V (AMD) ?
grep -Ec '(vmx|svm)' /proc/cpuinfo

Un nombre supérieur à 0 confirme que l'extension est présente. Un 0 signifie soit un processeur sans extension de virtualisation, soit, bien plus souvent, une option désactivée dans le BIOS/UEFI sous un nom du genre « Intel Virtualization Technology » ou « SVM Mode ». Les contrôles propres à KVM (module kvm, périphérique /dev/kvm) ne concernent que cet hyperviseur : ils sont détaillés dans les concepts de KVM, et un hyperviseur de type 2 n'en a pas besoin.

Un piège guette ceux qui utilisent aussi KVM sur le même poste. Si VirtualBox refuse de démarrer une VM avec l'erreur VERR_VMX_IN_VMX_ROOT_MODE (Intel) ou VERR_SVM_IN_USE (AMD), les modules KVM sont chargés et occupent déjà VT-x ou AMD-V. Déchargez-les avec sudo modprobe -r kvm_intel (Intel) ou sudo modprobe -r kvm_amd (AMD). VirtualBox 7.2.2 et plus, sur un noyau 6.16 et plus, passe par les API de KVM pour acquérir VT-x (journal des changements de la 7.2.2) : à vérifier sur sa version, sans garantie.

Sur Windows et sur macOS

Sous Windows, ouvrez le Gestionnaire des tâches (Ctrl+Maj+Échap), onglet Performances, puis Processeur : la ligne Virtualisation doit afficher Activé. Si elle affiche « Désactivé », l'option se règle dans le BIOS/UEFI, comme indiqué plus haut. Si Hyper-V ou la sécurité basée sur la virtualisation (VBS) est active, VirtualBox fonctionne mais nettement plus lentement. Sous macOS, les Mac à puce Apple Silicon comme les Mac Intel récents prennent en charge la virtualisation nativement : il n'y a en principe aucune option à activer, mais la documentation de l'éditeur de votre hyperviseur fait foi pour votre modèle.

Quelle solution de virtualisation open source choisir ?

Le choix se fait sur le contexte d'exploitation, pas sur les performances brutes : les quatre familles ci-dessous reposent toutes sur les mêmes extensions matérielles. Le tableau situe chacune par rapport au besoin qu'elle sert le mieux.

Famille	Solutions	Quand la choisir
Type 1 bare-metal	KVM/libvirt, Proxmox VE	Serveurs et clusters de production
Conteneurs système et VM	Incus	Infrastructure légère, cloud privé, homelab
VM dans Kubernetes	KubeVirt, Harvester	Plateformes cloud native qui unifient VM et conteneurs
Type 2 (poste de travail)	VirtualBox	Apprendre, tester, développer sur son poste

Ces familles ne s'excluent pas. L'erreur classique consiste à choisir l'outil d'abord et à découvrir ensuite qu'il ne couvre pas le besoin réel : partez des concepts, identifiez la contrainte dominante (production, poste de travail, cluster existant), et l'outil se déduit. Pour la plupart des administrateurs, ce choix reste ouvert tant que le tronc commun n'est pas acquis.

Et après : quelle formation d'exploitation suivre ?

Une fois le tronc commun acquis, trois formations d'exploitation prennent le relais, selon la plateforme que vous voulez opérer. Aucune n'est un prérequis des autres.

KVM et libvirt : l'hyperviseur intégré au noyau Linux, piloté par virsh. On l'apprend pour comprendre ce qui se passe sous le capot et pour automatiser finement avec Terraform ou Ansible.
Proxmox VE : une plateforme clé en main bâtie sur KVM et LXC, avec interface web, cluster, sauvegarde et gestion des permissions. C'est le plus court chemin vers une console complète sans tout assembler à la main.
Incus : une seule CLI et une seule API pour des conteneurs système et de vraies VM, du serveur isolé au cluster et au cloud privé.

Autour de ces formations, la section garde des guides de référence, comme SUSE Harvester, la plateforme hyperconvergée bâtie sur KubeVirt, ou le simulateur vcsim, qui permet de tester des scripts VMware sans licence ni matériel.

Pourquoi choisir un hyperviseur open source en 2026 ?

Parce que l'open source supprime le coût de licence, garantit la réversibilité et laisse la donnée sous votre contrôle. Le marché de la virtualisation a été fortement bousculé ces deux dernières années : hausses tarifaires, fin de certaines licences perpétuelles et changements de politique de distribution ont poussé beaucoup d'équipes à réévaluer leur socle.

La réversibilité compte autant que le prix : un format de disque ouvert comme QCOW2 ou RAW s'importe et s'exporte sans outil propriétaire, ce qui rend une sortie possible à tout moment. La souveraineté, enfin, tient au fait que la plateforme tourne sur votre matériel, avec un code auditable. Le point décisif d'une transition réussie reste la capacité à reprendre l'existant : c'est ce que permet, par exemple, l'import des VM VMware dans Proxmox VE.

À qui s'adresse cette formation ?

Elle est conçue pour les administrateurs système, DevOps et SRE qui vont monter, reprendre ou simplement comprendre une plateforme de virtualisation. Aucune connaissance d'un hyperviseur n'est requise : le tronc commun les présente tous.

Le seul prérequis est la formation Linux : savoir ouvrir un terminal, lancer des commandes et lire leur sortie suffit. Le module facultatif demande en plus les bases de Kubernetes. Pour le module de première pratique, prévoyez un poste qui expose la virtualisation matérielle (voir le contrôle ci-dessus) et un hyperviseur de type 2 déjà installé, sans quoi la VM ne démarrerait pas ou resterait extrêmement lente.

À retenir

Une VM embarque son noyau, un conteneur partage celui de l'hôte : c'est la différence structurante, celle qui commande l'isolation, le poids et le temps de démarrage.
Type 1 (bare-metal) pour la production, type 2 pour apprendre et développer sur son poste ; KVM est souvent rangé en type 1 malgré son intégration au noyau Linux, un classement qui fait débat.
Sur un hôte Linux, grep -Ec '(vmx|svm)' /proc/cpuinfo renvoie 0 quand la virtualisation matérielle est absente ou désactivée dans le BIOS/UEFI ; sous Windows, le Gestionnaire des tâches l'indique.
Le format de disque (RAW ou QCOW2, fin ou épais) décide des performances et de la place occupée.
Le module KubeVirt est facultatif et suppose les bases de Kubernetes.
Après le tronc commun, KVM, Proxmox VE et Incus sont les trois formations d'exploitation, au choix selon la plateforme visée.