Architecture XEN

Pour avoir une vu globale nous allons utiliser l’image de Wikipédia.

XEN est logiciel qui permet de virtualiser des machines, c’est-à-dire utiliser différents systèmes d’exploitations sur un système, ce qui est pas possible de base. Il faut passer par un logiciel tiers pour y arriver. Xen est plus qu’un simple logiciel, c’est tous un système à lui seul. Il est open source, tout le monde peux participer au développement de ce logiciel si vous être intéressé pour participer, vous pouvez consulter cet article, c’est un bon début, allez voir, je vous attends.

URL : https://sysblog.informatique.univ-paris-diderot.fr/2019/03/21/comment-participer-au-projet-xen/

Xen est un logiciel de para virtualisation par HAL. Pour plus d’information sur les différents types de virtualisation. Vous pouvez consulter cette article :
https://sysblog.informatique.univ-paris-diderot.fr/2019/03/21/virtualisation-quesako/

L’introduction est à présent terminer, si vous être toujours, accrochez vos ceinture nous allons tous droits au cœurs de XEN. Voici un plan si vous vous perdez :

Nous allons voir la partie hôte de l’architecture de XEN :

Les deux schémas ci-dessus sont équivalent.
* Matériel = Host HW,
* XEN = L’hyperviseur,
* VM0 , VM1 = la patrie Linux NetBSD etc …

Xen interagie directement avec le matériel, soit le processeur la mémoire, le réseau, le stockage et plein d’autre périphérique. Il agit comme une interface pour le matériel ( principe de fonctionnement du HAL ).

Une VM sous XEN n’a pas connaissance du matériel de la machine, il a connaissance que de l’interface de l’hyperviseur. La machine ne peut pas interagir comme il veut avec le système physique. Ceci rajoute une protection et une isolation des VM.

Le logiciel de contrôle XEN, est installé sur la VM Dm0 (ou VM hôte ). Chaque VM est isolé des autres VMs, a part le Dom0 personne n’est occurrent de c’est voisins sur la machine. Il ne connaisse que les ressources qui leur on été alloué. Nous allons rentrée dans les détails par la suite.

L’hyperviseur implémente différente partie d’un système d’exploitation pour permettre une virtualisation efficace.

Comme :

• Le scheduler (ordonnanceur de processus)
• la MMU  (Gestion de la mémoire). Appelé sur la figure 1, le logiciel XEN.

La différence entre les deux schéma , la figure 1 et une chouche abstraitre c’est à dire comment l’utilisateur voie le système, et sur la figure 2 une simplification du système, qui permet d’avoir une vue d’ensemble.

Pour en savoir plus :

• Ordonnanceur de processus : https://fr.wikipedia.org/wiki/Ordonnancement_dans_les_syst%C3%A8mes_d%27exploitatio

• MMU : https://fr.wikipedia.org/wiki/Unit%C3%A9_de_gestion_m%C3%A9moire

Le dom0:

L’os qui contrôle l’hyperviseur, est le Dom0.  On peut dire en quelque sorte que c’est l’os principal ou os hôte. Il reste ne fonctionne pas comme un hyperviseur de type 2, c’est à dire qu’il n’a pas le contrôle total, mais il en a consciences et peux le configurer.

Tout les systèmes ne peuvent pas êtres dom0 il faut être compatible, les os compatible sont les grosses distributions Linux, comme Ubuntu, Fedora, Redhat, Cent OS … pour en savoir plus sur les OS compatibles :https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

Il peut lancer 2 types de virtualisation :

• On peut lancer une virtualisation depuis l’os hôte, par exemple avec virtualbox ou un émulateur, ce qui va permettre isolé le système du hardware. QEMU est par exemple intégré à XEN.
• On peut aussi directement la brancher sur hyperviseur XEN et ainsi

Nous allons voir par la suite , les spécification du Dom0. Elle gère la mémoire, le boot, le nombre de CPU. La console est sur le Dom0, elle permet de gérer les différentes configurations machine virtuelle.

Fonctionnement de la mémoire :

Comme expliquer sur la figure le “ballon driver” va redonner la mémoire autre VM. Le dom0 à la charge de définir les plages mémoires.

Il commence par lancer l’Os hôte la VM 0 qui va attribuer la mémoire, au fur et à mesure. Le système hôte possède une des pages.

Pour le paging de la mémoire. C’est un fonctionnement similiaire mmu de linux. L’hypervisor est le seul à connaitre l’ensemble des adresses physique. Il va générer la mémoire virtuelle des ordre OS. Chaque os aura l’impression de posséder la totalité de la mémoire.

L’hyperviseur peux aussi swaper les page sur le disk, et gérer les pagination des différent OS. Ce type de mapping confère une proteection et une illusion de la continuité de la mémoire virtuelle.

I/O devices :

Tout les composants qui demande des I/O ont un accès à l’hyperviseur.

Xen implémente un système de composant virtuelle qui utilise un buffeur en anneaux. Voir la figure ci-dessus. Le buffeur en anneau pré-alloue les différentes les descripteur. Cet implémentation à un pointeur de lecture et un autre pour la partie écriture.
En gris foncé sur le schéma on trouve les descripteurs qui on été alloué et en gris claire sont ceux qui n’ont pas encore été alloué. L’avantage de ce système permet de ne jamais dépasser un certain nombre de descripteur. Ce système pertmet donc d’avoir un buffer de même taille afin d’améliorer les performances de l’ensemble du système et éviter les problèmes de buffer overflow.

La gestion des CPU :

. . .

Par défaut il choisi les CPU physiques et il va attribué des cpu virtuelle que l’on appèle vCPU. Il y a différent de configuration, possible. Il est laissé au choix de l’administrateur de les configuré comme il le shouaite. Les processeur physique peuvent être partagé par différente VM.

Par exemple sur la figure, on peut voir 4 CPU physique en vert, Xen en virtualise 8. Il va attribuer aux VM par la suite. Dans la figure se sont les processus violet et orange. Le système hôte et quant à lui en bleu. Xen permet donc de configurer efficacement les processus.

.

.

.

Le processus de boot :

Dans un Linux classique le boot est dans un dossier à part et va lancer le firmware, le bootloader généralement GRUB2 ( processus d’amorçage ) puis le kernel. Vous pouvez consulter des articles sur ce site pour en avoir plus détail.

Sur Xen, le fonctionnement est différent. Il y a un Hvm Loader qui est contenue dans le Dom0. Il va lancer le firmware qui est propre au Dom0. Puis il va lancer le grub de la machine émuler, et son noyau (kernel) qui lancera à son tour le système.

Conclusion :

Pour conclure, nous avons que XEN propose une HAL pour ces machine virtuelle. Il fait croire à la machine qu’il existe seulement la mémoire, les CPU ou encore une implémentation des buffers particulière accessible à l’os Toute l’intelligence de ce logiciel se concentre sur cette partie, les VMs n’ont aucun moyen de savoir quel autre VM tourne en même temps sur la machine. Elle ne connaisse pas le hardware exacte, seul la VM hôte et l’hyperviseur on une connaissance de ce hardware.

Dans le domaine de la virtualisation XEN , propose une véritable alternative de part la rechecher de protection et de performance et de son implémentation efficace d’un HAL.