| Les deux révisions précédentesRévision précédente | |
| wiki:virtualisation_et_emulation [2025/08/02 22:10] – [Émulateur de console de jeux] Thibault Seguin | wiki:virtualisation_et_emulation [2025/09/16 19:22] (Version actuelle) – [Virtualisation avec hyperviseurs et conteneurs] Thibault Seguin |
|---|
| Contrairement à l'**émulation** qui émule la totalité d'un ordinateur, un **hyperviseur** utilise les ressources de l'ordinateur hôte (ordinateur sur lequel est installé l'hyperviseur), en gros il utilise les composants internes de l'ordinateur hôte comme le processeur (CPU), la mémoire vive (RAM), la carte graphique (GPU), carte réseau, carte son,... Par contre, l'hyperviseur ne peut exécuter une **VM** (**machine virtuelle**) et **système d'exploitation invité** que si il se base sur la même architecture processeur que l'ordinateur hôte. C'est à dire que sur un ordinateur ayant un processeur **Intel** ou **AMD** ''64 bits'' (**x86**), l'hyperviseur ne peut virtualiser qu'un système d'exploitation invité (OS invité) ou VM basé sur l'Intel ou AMD ''64bits'' ou ''32bits'' (x86) alors qu'un émulateur peut émuler n'importe quel architecture de processeur. Un OS invité est totalement isolé de l'ordinateur et de l'OS Hôte et même des autres VM, si il y en a. C'est le principe de la **virtualisation** complète ! Une VM est un ordinateur virtualisé et l'OS invité est l'OS installé sur cette VM. | Contrairement à l'**émulation** qui émule la totalité d'un ordinateur, un **hyperviseur** utilise les ressources de l'ordinateur hôte (ordinateur sur lequel est installé l'hyperviseur), en gros il utilise les composants internes de l'ordinateur hôte comme le processeur (CPU), la mémoire vive (RAM), la carte graphique (GPU), carte réseau, carte son,... Par contre, l'hyperviseur ne peut exécuter une **VM** (**machine virtuelle**) et **système d'exploitation invité** que si il se base sur la même architecture processeur que l'ordinateur hôte. C'est à dire que sur un ordinateur ayant un processeur **Intel** ou **AMD** ''64 bits'' (**x86**), l'hyperviseur ne peut virtualiser qu'un système d'exploitation invité (OS invité) ou VM basé sur l'Intel ou AMD ''64bits'' ou ''32bits'' (x86) alors qu'un émulateur peut émuler n'importe quel architecture de processeur. Un OS invité est totalement isolé de l'ordinateur et de l'OS Hôte et même des autres VM, si il y en a. C'est le principe de la **virtualisation** complète ! Une VM est un ordinateur virtualisé et l'OS invité est l'OS installé sur cette VM. |
| |
| La **conteneurisation** à quelques similitudes avec l'appel système et commande Unix **chroot** mais en utilisant une //isolation// complète entre l'OS hôte et les autres conteneurs. Je vais prendre pour exemple les conteneurs **LXC**, les conteneurs ont une méthode de **virtualisation au niveau du système d'exploitation**, c'est à dire que les conteneurs peuvent virtualiser plusieurs **systèmes Linux** (n'importe quelle distribution Linux est virtualisable) sur un ordinateurs hôte qui comportent lui aussi un système Linux, pour cela les conteneurs utilisent le **noyau Linux** de l'OS hôte sur l'ordinateur hôte ce qui permet d'exécuter les logiciels d'un conteneur de façon pour ainsi dire //native//. Un conteneur n'a accès à aucune donnée de l'OS hôte et des autres conteneurs, l'//isolation// est parfaite, le seul OS qui peut accéder à toutes les données des conteneurs est l'OS Linux hôte (OS principal de l'ordinateur). À noter qu'un conteneur ne virtualise pas le //noyau// étant donné qu'il utilise le noyau Linux de l'hôte mais la totalité de l'**espace utilisateur**, c'est à dire tout ce qui compose un système Linux hormis le noyau. Il faut aussi préciser que contrairement à la virtualisation par hyperviseur on peut tout à fait virtualiser un conteneur Linux à processeur **ARM** sur un ordinateurs hôte avec un Linux à processeur x86 (Intel ou AMD). En définitive, les conteneurs sont parfaits pour avoir plusieurs //serveurs Web Linux// sur le même ordinateur par exemple ou avoir un conteneur Linux qui donne la possibilité d'avoir un //environnement de développement//, compilation sans interféré avec votre OS Linux principal, enfin vous avez une infinité de possibilités avec la virtualisation par conteneurs. | La **conteneurisation** à quelques similitudes avec l'appel système et commande Unix [[wiki:os:gnu_linux:tutos:admin:chroot]] mais en utilisant une //isolation// complète entre l'OS hôte et les autres conteneurs. Je vais prendre pour exemple les conteneurs **LXC**, les conteneurs ont une méthode de **virtualisation au niveau du système d'exploitation**, c'est à dire que les conteneurs peuvent virtualiser plusieurs **systèmes Linux** (n'importe quelle distribution Linux est virtualisable) sur un ordinateurs hôte qui comportent lui aussi un système Linux, pour cela les conteneurs utilisent le **noyau Linux** de l'OS hôte sur l'ordinateur hôte ce qui permet d'exécuter les logiciels d'un conteneur de façon pour ainsi dire //native//. Un conteneur n'a accès à aucune donnée de l'OS hôte et des autres conteneurs, l'//isolation// est parfaite, le seul OS qui peut accéder à toutes les données des conteneurs est l'OS Linux hôte (OS principal de l'ordinateur). À noter qu'un conteneur ne virtualise pas le //noyau// étant donné qu'il utilise le noyau Linux de l'hôte mais la totalité de l'**espace utilisateur**, c'est à dire tout ce qui compose un système Linux hormis le noyau. Il faut aussi préciser que contrairement à la virtualisation par hyperviseur on peut tout à fait virtualiser un conteneur Linux à processeur **ARM** sur un ordinateurs hôte avec un Linux à processeur x86 (Intel ou AMD). En définitive, les conteneurs sont parfaits pour avoir plusieurs //serveurs Web Linux// sur le même ordinateur par exemple ou avoir un conteneur Linux qui donne la possibilité d'avoir un //environnement de développement//, compilation sans interféré avec votre OS Linux principal, enfin vous avez une infinité de possibilités avec la virtualisation par conteneurs. |
| |
| ==== Hyperviseurs de type 2 ==== | ==== Hyperviseurs de type 2 ==== |
