Name: Le Socle du Fer — Semaine 13 — Virtualisation Bare Metal
Author: Amine RAITI

RATIO

LE SOCLE DU FER · SUPPORT DE COURS · SEMAINE 13

◆◆◆

VIRTUALISATION
BARE METAL
Semaine 13 sur 26 · Bloc 5 — OS Bare Metal
10h théorie · 25h pratique

◆

◆ OBJECTIFS PÉDAGOGIQUES DE LA SEMAINE

1. Distinguer hyperviseur de type 1 et de type 2
2. Installer et configurer Proxmox VE (ou équivalent) sur métal nu
3. Créer, démarrer, arrêter et supprimer des machines virtuelles
4. Gérer les ressources virtuelles (CPU, RAM, disque) et comprendre leurs limites
5. Réaliser un snapshot et restaurer une VM

◆◆◆

⚠ AVERTISSEMENT — PÉRENNITÉ DES VERSIONS CITÉES

Ce support cite Proxmox VE comme hyperviseur de référence pour ce cours (open source, large adoption en 2026). Le formateur peut substituer tout autre hyperviseur de type 1 disponible dans l'environnement de formation — les concepts et objectifs restent identiques indépendamment de l'outil choisi.

◆

Amine RAITI · Architecte Infrastructure & SRE
Document public · CC BY-NC-SA 4.0 · AI Powered by Amine
Opération Dindon

RATIO

PLAN DE COURS · 10H

FIL CONDUCTEUR THÉORIQUE

◆

13.1 · Hyperviseurs type 1 vs type 22h

— Type 1 (bare metal) : s'installe directement sur le matériel, contrôle total des ressources physiques (lien avec S6 — le matériel vu en microinformatique devient une ressource virtuelle)
— Type 2 (hosted) : s'exécute dans un OS hôte, moins performant mais plus facile à installer
— Pourquoi la formation utilise le type 1 : c'est le modèle de production réel

13.2 · Concepts fondamentaux de la virtualisation3h

— Ressources virtuelles vs ressources physiques : vCPU, RAM virtuelle, disque virtuel (qcow2, vmdk)
— Notion de surengagement (overcommit) : allouer plus de ressources virtuelles que de ressources physiques disponibles, risques associés
— Réseau virtuel : bridges, VLANs sur un hyperviseur (lien anticipé avec le bloc réseau S17-S19)

13.3 · Snapshots et clones3h

— Snapshot : photo de l'état d'une VM à un instant T (disque + RAM optionnellement), utilité pour les tests et les mises à jour risquées
— Clone : copie complète d'une VM pour déploiement rapide d'une nouvelle instance
— Limites des snapshots : ne remplacent pas une sauvegarde hors de l'hyperviseur (lien direct avec les images disque de S7)

13.4 · Architecture d'un cluster d'hyperviseurs2h

— Introduction conceptuelle du cluster (plusieurs hôtes physiques partageant un pool de ressources)
— Notion de migration à chaud (live migration) — sera pratiqué en S14
— Stockage partagé comme prérequis de la haute disponibilité (lien anticipé avec S14)

RATIO

TP1 · INSTALLATION DE L'HYPERVISEUR ET PREMIÈRES VMs · 12H

Matériel : machine physique dédiée (ou le serveur assemblé en S6), image ISO Proxmox VE (version stable disponible), clé USB amorçable, connexion réseau.

(2h) Installation de Proxmox VE sur métal nu : partitionnement, configuration réseau de l'hyperviseur, accès à l'interface web.

(2h) Exploration de l'interface web : nœud, stockage, réseau, création d'un pool de stockage local.

(4h) Création d'une première VM Linux (en utilisant l'ISO déjà maîtrisée en S8) : allocation de ressources, installation du système, démarrage et vérification.

(2h) Création d'une seconde VM avec des ressources différentes (moins de RAM, moins de vCPU), comparaison des performances observées avec la première.

(2h) Réalisation d'un snapshot de la première VM, modification volontaire du système (suppression d'un fichier important), restauration depuis le snapshot, vérification.

CORRIGÉ TP1

Vérification post-installation de l'hyperviseur : l'interface web doit être accessible depuis un poste client via l'adresse IP configurée pendant l'installation, sur le port par défaut. Le nœud doit apparaître comme opérationnel dans le tableau de bord.

Vérification de la restauration depuis snapshot : le fichier supprimé doit être de nouveau présent après restauration — c'est la démonstration concrète que le snapshot a bien capturé l'état antérieur à la suppression. Insister sur la différence avec une sauvegarde externe : si l'hyperviseur lui-même est en panne, le snapshot devient inaccessible.

RATIO

TP2 · GESTION DES RESSOURCES ET RÉSEAU VIRTUEL · 13H

Matériel : hyperviseur configuré au TP1, les deux VMs créées.

(3h) Modification à chaud des ressources d'une VM (ajout de RAM et de vCPU sans redémarrage si supporté par l'hyperviseur), observation de l'effet côté système invité.

(3h) Configuration du réseau virtuel : création d'un bridge réseau dédié, connexion des deux VMs sur ce bridge, test de communication entre les VMs (ping, transfert de fichier).

(4h) Exercice de surengagement contrôlé : configurer les deux VMs avec une RAM totale légèrement supérieure à la RAM physique disponible, observer le comportement de l'hyperviseur et des VMs sous charge (outil de stress test simple).

(3h) Clone d'une VM, démarrage du clone, vérification que les deux instances fonctionnent indépendamment.

CORRIGÉ TP2

Résultat attendu du surengagement : avec un surengagement léger (10-20% au-delà de la RAM physique), l'hyperviseur utilise la mémoire ballooning ou le swap pour gérer la demande — les VMs fonctionnent mais avec une dégradation de performance mesurable. Avec un surengagement excessif, le risque de crash des VMs augmente fortement.

Vérification du clone : les deux instances doivent avoir des identifiants différents (IP si DHCP, hostname si reconfigurés) — un clone non reconfigurés peut créer des conflits réseau, point important à souligner.

◆ FICHE DE SYNTHÈSE — AUTO-ÉVALUATION SEMAINE 13

1. Je sais distinguer hyperviseur de type 1 et de type 2.

2. Je sais installer Proxmox VE (ou équivalent) sur métal nu.

3. Je sais créer et gérer une VM (démarrage, arrêt, suppression).

4. Je comprends la notion de surengagement et ses risques.

5. Je sais réaliser et restaurer un snapshot.

6. Je comprends pourquoi un snapshot ne remplace pas une sauvegarde externe.

7. Je sais configurer un bridge réseau et faire communiquer deux VMs.

8. Je sais cloner une VM.