# Infrastructure - La virtualisation

<table id="bkmrk-difficult%C3%A9%2A-%3Cdescrip" style="border-collapse: collapse; width: 100%; height: 46.8px; border-width: 1px; border-style: hidden;"><colgroup><col style="width: 20%;"></col><col style="width: 80%;"></col></colgroup><tbody><tr style="height: 46.8px;"><td style="height: 46.8px; border: 1px groove rgb(52,73,94);">[![image.png](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/rAYintermediaire-png.png)](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/rAYintermediaire-png.png)  
</td><td style="height: 46.8px; border-width: 1px; background-color: rgb(236,202,250); vertical-align: top;">Difficulté : Intermédiaire

Notions : Hyperviseurs

</td></tr></tbody></table>

---


### <span style="color: rgb(52,73,94);">**<span style="text-decoration: underline;">I. Introduction</span>**</span>

La virtualisation est une technologie qui permet d'exécuter plusieurs systèmes d'exploitations et environnements isolés sur une même machine physique. Optimisant ainsi l'utilisation du matériel et améliorant la flexibilité et la 'scalabilité' des infrastructures informatiques.

Les hyperviseurs sont aujourd'hui devenu un élément essentiel des infrastructures informatiques.

En effet, traditionnellement dans l'informatique, un serveur est une machine physique où l'on va installer un système d'exploitation et des rôles ou des fonctionnalités pour fournir un service aux utilisateurs. Mais avec l'arrivée de la virtualisation, il est devenu possible de détacher les serveurs et services de l'aspect matériel.

Cela apporte certains avantages :

- Réduction des coûts 
    - Réduction des coûts liés au matériel.
    - Simplification de la maintenance et des déploiement.

- Flexibilité 
    - Les machines peuvent être rapidement déployées ou détruites pour suivre l'évolution du besoin.
    - Elles peuvent être clonées, déplacées sur d'autres matériels physiques ou sites distants.
    - On peut faire évoluer leur matériel afin d'ajuster leurs performances.
    - Création rapide d’environnements de tests ou de formation.

- Consolidation 
    - Les machines peuvent être regroupées sur un seul serveur.
    - Avec la haute disponibilité, amélioration de de la disponibilité des services.

<p class="callout info">**Info** : La virtualisation se démarque de l'émulation dans le fait qu'elle permet de faire fonctionner des machines complètes incluant l'OS et le matériel virtualisé associé, là où l'émulation reproduit logiciellement un matériel différent.</p>

---

### <span style="color: rgb(52,73,94);">**<span style="text-decoration: underline;">II. Les types d'hyperviseur</span>**</span>


#### **<span style="color: rgb(35,111,161);">2.1 Hyperviseurs de type 1</span>**

Les hyperviseur de type 1, aussi appelé <span style="color: rgb(132,63,161);">***Bare-metal***</span>, sont des hyperviseurs installés directement sur le matériel.

<div drawio-diagram="112"><img src="https://docs.labs404.fr/uploads/images/drawio/2026-07/drawing-1-1770129804-png.png" alt="drawing-1-1770129804.png"/></div>

*Par exemple : VMware ESXi, Hyper-V, Proxmox VE, Xen...*

Cela convient particulièrement à des infrastructures de production.

<table id="bkmrk-colonne-1-colonne-2-" style="width: 100.714%; height: 153.016px;"><colgroup><col style="width: 34.3266%;"></col><col style="width: 30.2741%;"></col><col style="width: 35.3993%;"></col></colgroup><tbody><tr style="height: 76.5px;"><td rowspan="2" style="border-style: none; background-color: rgb(191,237,210); height: 153.016px;">**Pours :**  
- Performances élevées
- Meilleure isolation
- Fiabilité pour la production
- Possibilité de paramétrer de la haute disponibilité

</td><td style="border-style: none; height: 76.5px;">  
</td><td rowspan="2" style="border-style: none; height: 153.016px; background-color: rgb(248,202,198);">**Contres :**  
- Plus coûteux (achats de licences).
- Nécessite du matériel spécifique aux performances élevées.
- Nécessite de solides compétences pour une bonne mise en oeuvre.

</td></tr><tr style="height: 76.5156px;"><td style="border-style: none; height: 76.5156px;">  
</td></tr></tbody></table>

#### **<span style="color: rgb(35,111,161);">2.2 Hyperviseurs de type 2</span>**

Les hyperviseur de type 2, aussi appelé <span style="color: rgb(132,63,161);">***Hyperviseur hébergés***</span>, sont des hyperviseurs installés comme un logiciel ou un service par dessus un système hôte existant.

<div drawio-diagram="113"><img src="https://docs.labs404.fr/uploads/images/drawio/2026-07/drawing-1-1770202249-png.png" alt="drawing-1-1770202249.png"/></div>

*Par exemple : VMware workstation, VirtualBox, Parallels...*

Cela convient particulièrement à des environnements de développement, tests ou prototypage.

<table id="bkmrk-pours-%3A-simple-%C3%A0-ins" style="width: 100.714%; height: 154px;"><colgroup><col style="width: 34.3266%;"></col><col style="width: 30.2741%;"></col><col style="width: 35.3993%;"></col></colgroup><tbody><tr style="height: 77.5px;"><td rowspan="2" style="border-style: none; background-color: rgb(191,237,210); height: 154px;">**Pours :**  
- Simple à installer
- Simple à prendre en main
- Idéal sur poste de travail

</td><td style="border-style: none; height: 77.5px;">  
</td><td rowspan="2" style="border-style: none; height: 154px; background-color: rgb(248,202,198);">**Contres :**  
- Moins d'isolation par rapport au système hôte.
- Moins performant.
- Moins fiables.
- Fonctionnalités réduites.

</td></tr><tr style="height: 76.5px;"><td style="border-style: none; height: 76.5px;">  
</td></tr></tbody></table>

#### **<span style="color: rgb(35,111,161);">2.3 Choisir son hyperviseur</span>**

En définitive, le choix de l'hyperviseur dépend avant tout de son usage de destination.

Si l'objectif est de monter une infrastructure de production avec une bonne redondance, choisir le type 1.

Sinon, si l'objectif est de disposer d’environnements de tests à des fins de développement ou de prototypage de solutions, privilégier un type 2.

<div class="b_rd_tfil-ajaxCompleted" id="bkmrk-vmware-esxi%3A-industr"><div><div><div class="rd_tb_cnt_wp"><div class="rd_tb_cnt">Le choix de la solution dépendra ensuite du budget et des fonctionnalités recherchées.</div></div></div></div></div>---

### <span style="color: rgb(52,73,94);">**<span style="text-decoration: underline;">III. Architecture de plateforme virtualisée</span>**</span>


Une architecture de plateforme virtualisée s'articule autour des composantes traitées ci-dessous. Chaque composante aura son rôle et son importance dans certains aspects de la performance ou compatibilité de l'infrastructure.


#### **<span style="color: rgb(35,111,161);">3.1 Matériel de l'hôte physique</span>**

Il s'agit de l'hôte en tant que machine physique sur lequel sera installé l'hyperviseur. Comme toute machine physique, il s'agit d'un serveur matériel avec son hardware.

Le matériel choisi pour le(s) hôte(s) physique(s) influera directement les performances et capacités de l'infrastructure.

Les points à prendre en comptes sont évidement :

- Le ou les CPU et leur nombre de cœurs
- la RAM
- Le type de stockage (HDD, SSD, hybride, tearing, ...)
- La bande passante des cartes réseaux.

<p class="callout info">**Info** : Il est également primordial que la machine choisie dispose des capacité de virtualisation (intel-VT ou AMD-VT).</p>

#### **<span style="color: rgb(35,111,161);">3.2 L'hyperviseur</span>**

L'hyperviseur est le gestionnaire des machines virtuelles. Il permet leur création, manipulation, paramétrage et est également en charge de l'allocation et le suivi des ressources pour les machines virtuelles.

Comme évoqué plus haut, le choix du type de celui-ci dépendra de l'usage.

Le choix du produit quand à lui devra être guidé par les contraintes budgétaires, de performances, mais également les éventuels aspects contractuels.

<details id="bkmrk-comparatif-hypervise"><summary>Comparatif hyperviseurs</summary>

<table><thead><tr><th>Hyperviseur</th><th>Type</th><th>Fonctionnalités clés</th><th>Fourchette budgétaire (indicative)</th><th>Mode de licensing</th></tr></thead><tbody><tr><td>**VMware ESXi / vSphere**</td><td>Type 1</td><td>Haute disponibilité (HA), vMotion, DRS, snapshots avancés, gestion centralisée via vCenter, très mature</td><td>**Moyen à très élevé** selon l’édition (Essentials → Enterprise Plus)</td><td>Licence par **CPU** + options (vCenter, fonctionnalités avancées)</td></tr><tr><td>**Microsoft Hyper‑V**</td><td>Type 1</td><td>Intégration Windows Server, Live Migration, Replica, clustering, snapshots, gestion via SCVMM</td><td>**Faible à moyen** (inclus dans Windows Server)</td><td>Licence **Windows Server** (Standard ou Datacenter), par **cœur CPU**</td></tr><tr><td>**Proxmox VE**</td><td>Type 1</td><td>KVM + LXC, clustering simple, snapshots, backup intégré, interface web complète, Ceph intégré</td><td>**Très faible** (open‑source, support payant optionnel)</td><td>Gratuit (AGPL) + **abonnement support** optionnel</td></tr><tr><td>**XCP‑ng**</td><td>Type 1</td><td>Basé sur Xen, live migration, snapshots, gestion via Xen Orchestra, cluster</td><td>**Très faible à faible**</td><td>Gratuit (open‑source) + **support commercial** via Vates</td></tr><tr><td>**Oracle VM VirtualBox**</td><td>Type 2</td><td>Multi‑OS, snapshots, portable, idéal labo/test, large compatibilité</td><td>**Gratuit**</td><td>Gratuit (GPL + extension pack sous licence Oracle)</td></tr><tr><td>**VMware Workstation / Fusion**</td><td>Type 2</td><td>Environnements de test, snapshots, clonage, réseau virtuel avancé</td><td>**Faible** (licence unique)</td><td>Licence **poste utilisateur**</td></tr><tr><td>**KVM (Linux)**</td><td>Type 1 (intégré OS)</td><td>Très performant, supporté par la plupart des distributions, snapshots, live migration via libvirt/virt‑manager</td><td>**Gratuit**</td><td>Inclus dans Linux (GPL), support via distributions</td></tr></tbody></table>

*source : copilot, basé sur une liste de sources et de critères définies dans le prompt.*

</details>#### **<span style="color: rgb(35,111,161);">3.3 Les machines virtuelles</span>**

Les machines virtuelles sont les machines hébergées sur l'hyperviseur. Comme toute machine, elles disposent d'un matériel avec ses caractéristiques, sauf que celui-ci n'est pas physique mais plutôt logiciel. Aussi, chaque machine se voit allouée des ressources définies comme suit :

- Vcpu et Vcore ( un nombre de socket et de cœurs de CPU que la machine pourra exploiter)
- Mémoire virtuelle (une quantité de RAM maximum allouée à la machine)
- Disques virtuels ( souvent sous la forme de fichiers .vmdk, .vhdx, etc.. ; C'est l'espace disque maximal qui sera alloué à la machine)
- Carte réseau virtuelle ( une interface réseau pour la connectivité, souvent la gestion des adresses MAC est gérée par l'hyperviseur)

#### **<span style="color: rgb(35,111,161);">3.4 Les outils de gestion</span>**

Afin de gérer le ou les hyperviseur(s) la plupart des solutions intègrent des outils de gestion. Souvent sous la forme d'appliances ou de machines dédiées, ils sont généralement accessibles via une interface web et permettent la configuration du cluster, des hôtes et la gestion des machines virtuelles.

On pourra citer par exemple VMware Vcenter, ProxmoxVE, Hyper-V manager, etc...

[![image.png](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/Wv4image-png.png)](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/Wv4image-png.png)

#### **<span style="color: rgb(35,111,161);">3.5 Notions de cluster</span>**

Par nature, les machines virtuelles sont donc dé-corrélées du matériel physiques sur lequel elles s'appuient et son donc 'portables'.

On peut ainsi les déplacer d'un hôte à un autre. Cela ouvre la voie à une notion de cluster.

Un cluster est un groupement d'hôtes gérés par un manager qui vont donc pouvoir travailler ensemble afin de se répartir les machines virtuelles. Ce qui permet ainsi :

- La haute disponibilité ( les machines peuvent être répliquées et disponibles sur plusieurs hôtes)
- La migration à chaud ( les machines peuvent être déplacées d'un hôte à un autre sans forcement les éteindre)
- La répartition de charge ( il est possible de répartir les VM afin d'optimiser la consommation de ressources )

---

### <span style="color: rgb(52,73,94);">**<span style="text-decoration: underline;">IV. Allocation et gestion des ressources</span>**</span>

La gestion des ressources et l'un des aspects les plus importants de la virtualisation.

Une VM ne possède pas réellement ses propres composants matériels. Elle reçoit une portion des ressources de l'hôte physique et l'hyperviseur doit en permanence arbitrer entre les besoin de l'ensemble des VM.


Lors de l'allocation de ressources à une VM, il y a plusieurs facteurs à prendre en compte.

#### <span style="color: rgb(35,111,161);">**4.1 Le CPU**</span>

Sur une VM, il est possible d'allouer de la puissance de calcul en ajoutant des Vcpu et des Vcore.

 Un vCPU correspond à un thread logique que l’hyperviseur peut planifier. Un vCore est une manière de présenter ces vCPU à la VM.

En définitive, il est possible d'allouer plus de Vcpu ou Vcore au VM que ce qui est réellement présent sur la machine. Cela est possible car l'hyperviseur sais répartir la charge des instruction sur son matériel physique et que toutes les VM ne sont pas tout le temps à 100% de leur utilisation CPU. Cela s'appelle l'<span style="color: rgb(132,63,161);">***Overcommit CPU***</span>.

*Exemple : un hôte à 64Go de RAM / 16cores, on provisionne 8VM à 4 Vcpu. Il y a overcommit. Cela ne posera pas de problème à moins que la charge sur les machine soit à 100% sur chacune d'elles sur une longue période.*

<p class="callout warning">**Attention** : Contrairement à ce que l'on peut penser, il n'est pas forcement bon d'allouer plus de Vcpu que réellement nécessaire. En effet, cela peut mener à une situation ou une VM attends d'exécuter des instructions, mais l'hyperviseur n'a pas de CPU disponibles car déjà alloués aux autre machines. Cela créée donc des tentions sur le CPU et des contentions entre VM. Ce phénomène s'appelle le '<span style="color: rgb(132,63,161);">***CPU Ready***</span>'.</p>

<table id="bkmrk-un-cpu-ready-%C3%A9lev%C3%A9-i" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 50%;"></col><col style="width: 50%;"></col></colgroup><tbody><tr><td>Un CPU Ready élevé indique :

- surcharge CPU de l’hôte
- trop de vCPU attribués
- VM surdimensionnées
- contention entre VM

</td><td>Ordres de grandeur :

- &lt; 5 % : normal
- 5–10 % : surveiller
- 10 % : impact visible (latence, lenteur)
- 20 % : problème sérieux

</td></tr></tbody></table>

*Exemple : Une VM avec 8 cœurs sur un host 4 cœurs --&gt; CPU Ready élevé garanti !*

Il est donc important de bien dimensionner les VM pour n'attribuer que le nombre de Vcore nécessaire à son fonctionnement.

#### **<span style="color: rgb(35,111,161);">4.2 La mémoire</span>**

La Mémoire est **LA** ressource critique lorsque l'on parle de virtualisation. En effet, c'est le point sur lequel il est le moins possible de faire de compromis car les services qui sont lancés sur une VM vont consommer une certaine quantité de mémoire au minimum, puis des parts par utilisateurs utilisant le service.

Les hyperviseur vont ensuite utiliser plusieurs mécaniques pour en partager et en optimiser l'usage.

Comme pour le CPU, il est possible d'allouer plus de ressource mémoire que disponible sur l'hôte. Cela s'appelle l'<span style="color: rgb(132,63,161);">***Overcommit mémoire***</span>.

L'hyperviseur va ensuite se reposer sur plusieurs mécaniques. Dont :

- *<span style="text-decoration: underline;">**Le ballooning**</span>*

Lors de l'installation des pilotes de l'hyperviseur sur les systèmes invités, un driver appelé 'balloon' a été installé. Le 'ballon' dans les VM est une portion de la mémoire qui peut être récupérée par l'hyperviseur pour être affectée de manière 'scalable' à d'autres VM.

En cas de tension sur l'hyperviseur, celui-ci 'gonfle' le ballon qui prends la forme d'un processus réservant de la RAM sur la VM invitée. Cette RAM n'est alors plus utilisable par la VM car elle la juge déjà utilisée par ce processus. L'hyperviseur réaffecte donc cette plage de RAM réservée à une autre VM qui en a besoin.

Dès que la tension est libérée, le ballon est 'dégonflé' et la RAM réservée est rendue à la VM.

<p class="callout info">**Info** : Bien que le ballooning ne soit pas un problème en soi, il deviens problématique dès lors que les VM impactées n'ont plus assez de ressources mémoire pour fonctionner normalement. Cela cause du swapping et donc des lenteurs.</p>

- *<span style="text-decoration: underline;">**La compression**</span>*

L'hyperviseur est capable de compresser certaines pages mémoire peu utilisées pour économiser de la mémoire.

- *<span style="text-decoration: underline;">**Swapping hyperviseur**</span>*

Tout comme n'importe quelle machine, en cas de sur utilisation de la mémoire, l'hyperviseur est également capable de swap. C'est à dire qu'il va commencer à écrire des pages mémoires sur le disque. Au vu de la dégradation de performances que cela implique, c'est une situation à éviter.

#### **<span style="color: rgb(35,111,161);">4.3 Le stockage</span>**

Le choix du stockage est important et doit être déterminé par les fonctionnalités souhaitées.

Un stockage local en SSD est rapide et offre d’excellentes performances. La sécurité peut en être améliorée avec du RAID.

<p class="callout warning">**Attention** : Le RAID permet une sécurité locale mais ne permet pas de faire de la <span style="color: rgb(132,63,161);">***haute disponibilité***</span>.</p>

Pour cela, il faudra opter pour un stockage mutualisé de type NAS ou SAN, ce qui rendra les VM visibles depuis l'ensemble des nœuds du cluster et permettra une bascule rapide en cas de coupure ou maintenance d'un hôte.

Cela permettra aussi d'activer des fonctions d'optimisation de charge et de consommation électrique, ainsi que des règles de répartition des VM.

*Exemple : 2 actives directory redondants ne doivent pas se trouver en même temps sur un même nœud.*

Si la solution du stockage partagée est privilégiée, il faudra également prendre en compte la liaison réseau avec les hôtes. En effet la bande passante de celle-ci impactera grandement les performances en lecture/Ecriture sur les volumes.

Il est préférable également d'opter pour des cartes réseaux dédiées et optimisées pour cet usage comme les cartes Melanox

[![image.png](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/Ra2image-png.png)](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/Ra2image-png.png)

En effet, en plus de leur excellentes capacité réseaux, celles-ci intègrent un cache dédié pour le stockage et l'écriture de blocs.

Les transactions sur le stockage se mesure en IOpS (Input/Output per Second). C'est cet indicateur qu'il faut vérifier pour mesurer la performance du stockage.

---

## <span style="text-decoration: underline;"><span style="color: rgb(52,73,94); text-decoration: underline;">**V. Les fonctionnalités avancées**</span></span>

<span style="color: rgb(52,73,94);">Comme vu plus haut, dans la logique de la virtualisation, les VM ne sont plus directement corrélées au matériel. Cette couche d'abstraction implique que la VM soit vue par l'hyperviseur comme simplement un processus et un ensemble de fichiers.</span>

<span style="color: rgb(52,73,94);">Cela ouvre la porte a beaucoup de fonctionnalités intéressantes et qui sont devenue clés de la gestion des machines virtuelles au sein d'une architecture d'entreprise.</span>

#### **<span style="color: rgb(35,111,161);">5.1 Les snapshots</span>**

Un <span style="color: rgb(132,63,161);">***snapshot***</span> ou 'cliché instantané', est un point de restauration d'une machine à un instant T.

Lors d'une prise de snapshot, le fichier de disque actuel de la VM est figé, un nouveau fichier de disque est créé. Celui-ci contient le Delta depuis le dernier snapshot.

<div drawio-diagram="116"><img src="https://docs.labs404.fr/uploads/images/drawio/2026-07/drawing-1-1771933507-png.png" alt="drawing-1-1771933507.png"/></div>

Il sera ensuite possible de faire des modifications, puis de revenir en quelques minutes à cet état précédent. Annulant ainsi tout ce qui est survenu depuis.

<div drawio-diagram="117"><img src="https://docs.labs404.fr/uploads/images/drawio/2026-07/drawing-1-1771933872-png.png" alt="drawing-1-1771933872.png"/></div>

Ou de valider cet état comme définitif et de supprimer les snapshots. Auquel cas, les fichiers du snapshot sont supprimés et les fichiers de disques sont fusionnés.

<div drawio-diagram="118"><img src="https://docs.labs404.fr/uploads/images/drawio/2026-07/drawing-1-1771937738-png.png" alt="drawing-1-1771937738.png"/></div>

C'est particulièrement utile pour sécuriser ponctuellement une opération comme une mise à jour, un changement de version ou un test quelconque.

Il est également possible de faire un snapshot, tester un scénario, refaire un snapshot, revenir sur l'original, tester un autre scénario, refaire un snapshot, etc... les snapshots seront ainsi géré en arborescence.

<div drawio-diagram="119"><img src="https://docs.labs404.fr/uploads/images/drawio/2026-07/drawing-1-1771938081-png.png" alt="drawing-1-1771938081.png"/></div>

Lors de l'effacement des snapshots, ceux utilisés seront fusionnés, les autres seront détruits. Cette opération s'appelle la '<span style="color: rgb(132,63,161);">***consolidation***</span>'.

<p class="callout warning">**Attention** : Les snapshots ne sont pas des sauvegardes. Si cela est utile pour un usage ponctuel, il n'est pas recommandé de les empiler et encore moins de les conserver de façon durable.</p>

#### **<span style="color: rgb(35,111,161);">5.2 Live migration</span>**

Une '<span style="color: rgb(132,63,161);">***Live migration***</span>' ou migration à chaud est le fait de déplacer une VM d'un hyperviseur ou d'un nœud d'une ferme à un autre, sans forcément avoir besoin d'éteindre cette machine et donc sans interrompre le service.

<div drawio-diagram="120"><img src="https://docs.labs404.fr/uploads/images/drawio/2026-07/drawing-1-1771938531-png.png" alt="drawing-1-1771938531.png"/></div>

Selon le type de migration, l'hyperviseur fait tout d'abord une copie du fichier descriptif de la VM, puis copie les disques et enfin le fichier mémoire. Dès lors que l'état de la VM est synchronisée sur le nœud source et le nœud de destination, la VM source est coupée et ses fichiers sont détruits.

Dans le cadre de l'utilisation d'un stockage partagé, c'est plus simple dans la mesure ou il suffit juste de transférer les fichiers mémoires.

Le déplacement peut être un déplacement sur une autre puissance de calcul, sur un autre stockage voire les deux.

#### **<span style="color: rgb(35,111,161);">5.3 High availability &amp; Fault Tolerance</span>**

La <span style="color: rgb(132,63,161);">***haute disponibilité***</span> et la <span style="color: rgb(132,63,161);">***Tolérance à la panne***</span>, sont des mécanismes qui exploitent la capacité de transfert d'une machine d'un hôte à un autre pour permettre automatiquement, en cas de coupure d'un nœud ou d'une VM, d'en reprendre l'exécution depuis un autre nœud.

<div drawio-diagram="121"><img src="https://docs.labs404.fr/uploads/images/drawio/2026-07/drawing-1-1771938653-png.png" alt="drawing-1-1771938653.png"/></div>

#### **<span style="color: rgb(35,111,161);">5.4 Load balancing, fencing</span>**

Partant de ce même principe et afin de fiabiliser celui-ci, il est possible de définir des ensembles de règles afin d'éviter que deux machines portant le même rôle dans un but de haute disponibilité se retrouvent au même moment sur le même hôte physique.

Ou inversement, pour des raisons d'économie d'énergie, de regrouper les machines virtuelles sur un même hôte physique afin d'optimiser le rendement énergétique.

#### **<span style="color: rgb(35,111,161);">5.5 Templates et clônes</span>**

La dernière fonctionnalité intéressante est de pouvoir, grâce au snapshots et au fait que les machines soient des ensembles de fichiers, est de pouvoir installer une machine, la préparer et la transformer en '<span style="color: rgb(132,63,161);">***template***</span>' ou modèle.

Cela permet ensuite de repartir de ce modèle afin de faire des déploiement en masse et de standardiser la production. Ce qui représente également un gain de temps non négligeable, car ce qui a été fait une fois pour le template, n'a plus à être refait par la suite.

A partir de ce template, il sera possible de déployer des clones. Il y a deux façons de créer un <span style="color: rgb(132,63,161);">***clone***</span> :

- Clone lié (la nouvelle machine se base sur les fichiers de l'ancienne et seul le delta est créé)
- Clone intégral (la machine est entièrement recréée à partir du modèle)

La création d'un clone lié à l'avantage d'être immédiate mais l'inconvénient de dépendre des disques des templates pour fonctionner (un peu à la manière des snapshots). En cas de corruption de celui-ci, l'ensemble des clones liées seront rendus inopérants.

La création d'un clone intégral prends plus de temps et de place sur le disque. C'est en effet une nouvelle machine intégralement créée, mais totalement indépendante.

En résumé, les clones liés sont pratique pour faire des tests rapides, mais pour de la production, il faut privilégier les clones intégraux.

#### **<span style="color: rgb(35,111,161);">5.6 Thin provisioning</span>**

Le <span style="color: rgb(132,63,161);">***thin provisionning***</span>, ou provisionnement dynamique, permet de n'allouer à une machine virtuelle que l'espace disque qu'elle va occuper. La taille définie sur le disque agit ici plus comme une 'limite totale d'espace disponible' que comme une réservation stricte de l'espace disque.

Cette fonctionnalité est très pratique pour des tests et pour optimiser l'espace disque disponible. Mais cela est fortement déconseillé dans un environnement de production car elle entraîne un risque de sur-provisionnement.

En effet, l'espace disque côté hyperviseur est perçu comme libre. Mais si les machines consomment toutes la capacité de leur disque au maximum, la capacité maximale de l'espace de stockage peut être dépassée, ce qui conduit au remplissage à 100% de celui-ci et potentiellement à une corruption des données.

*Exemple : 10 VM de 100Go en thin provisioning sur un datastore de 500Go --&gt; Si les VM se mettent à utiliser tout le stockage, risque de corruption et de perte de données.*

---

## <span style="text-decoration: underline;"><span style="color: rgb(52,73,94); text-decoration: underline;">**VI. Virtualisation du stockage**</span></span>

- Datastores
- SAN / NAS / iSCSI / NFS
- vSAN / Ceph / stockage distribué
- Impact des performances disque sur les VM

<div id="bkmrk--50">  
</div>## **VII. Virtualisation réseau**

- vSwitch / vNIC
- VLAN, trunking, tagging
- Distributed Virtual Switch
- SDN (Software Defined Networking) : principes de base

<div id="bkmrk--51">  
</div>## **VIII. Sécurité dans un environnement virtualisé**

- Isolation des VM
- Risques spécifiques (VM escape, snapshots oubliés, sprawl)
- Sécurisation de l’hyperviseur
- Gestion des accès et rôles (RBAC)
- Chiffrement des VM / disques / migrations

<div id="bkmrk--52">  
</div>## **IX. Administration et bonnes pratiques**

- Planification des ressources
- Monitoring (CPU ready, IOPS, latence, mémoire)
- Sauvegarde des VM (image‑level, agent‑based)
- Gestion du cycle de vie des VM
- Documentation et gouvernance

<div id="bkmrk--53">  
</div>## **X. Virtualisation et Cloud**

- Virtualisation vs Cloud
- IaaS, PaaS, SaaS
- Conteneurs et orchestrateurs (Docker, Kubernetes)
- Notion de virtualisation “cloud-native”