Introduction à la paravirtualisation avec Xen

Salut ! Aujourd'hui on va parler de paravirtualisation, et en particulier de l'hyperviseur Xen.
Qu'est ce que la para-virtualisation ? Qu'est ce qui rends Xen différent d'autres hyperviseurs ?
Nous allons en avoir un petit apercu.

Qu'est ce que la para-virtualisation ?

D'abord, qu'est ce que la virtualisation ? Si vous ne savez pas, c'est le fait de faire tourner différentes machines virtuelles sur une seule machine physique, avec chacun leur propre système ou environnement.
Dans un environnement de virtualisation standard, on va chercher à émuler une machine physique, c'est à dire créer un ordinateur virtuel complet, avec bus PCI, cartes réseaux, etc...
Le problème est qu'historiquement c'était une solution assez lourde: l'émulation peut prendre beaucoup de ressources. Aujourd'hui il faut savoir que du côté processeur, ce n'est plus un problème: grâce aux technologies de virtualisation, c'est géré au niveau matériel et la perte est négligeable. Il reste cependant la question des entrées/sorties.
Contrairement à émuler un ordinateur complet et de faire tourner un système dessus, comme dans une solution VMware, HyperV ou KVM classique, la paravirtualisation va chercher à faire fonctionner le système d'exploitation client "main dans la main" avec celui de l'hôte. Celà permet d'accéder aux ressources plus rapidement sans passer par la surcouche de l'émulation matérielle.

Et Xen dans tout ça ?

Xen est un hyperviseur qui est devenu pendant un temps assez populaire car il implémente justement ce type de virtualisation, par contraste à la virtualisation complète. C'est donc plus léger que d'émuler du hardware.
Il a depuis été étendu pour intégrer la virtualisation complète, et les techniques de para-virutalisation partielles, proposant aujourd'hui l'éventail complet des modes de virtualisation, comme expliqué sur cette image du Wiki Xen.
C'est un hyperviseur, donc un noyau qui tourne en dessous du noyau Linux habituel.

D'accord, comment j'utilise ça ?

Une fois le paquet xen-hypervisor (sous Debian/Ubuntu) installé, et la configuration du bootloader régenerée, Grub donnera l'option de booter sous le contrôle de l'hyperviseur Xen.
C'est (presque) transparent: en ayant un noyau compatible, le système boot comme d'habitude, mais ce coup ci, il est paravirtualisé ! On appelle alors le système Linux principal le dom0 : domaine zéro, qui peut contrôler Xen.
En installant les paquets xen-tools on peut alors utiliser diverses commandes: xentop, un affichage à la top affichant les différents domaines, xl dmesg affiche le log de l'hyperviseur.

Génial! Je tourne sous Xen. Et maintenant ?

Le plus simple pour manager des domaines est d'utiliser Libvirtd comme surcouche. Si vous avez déjà utilisé KVM, vous connaissez surement !

• Installer les paquets libvirtd, puis virt-manager et ssh-x11-askpass pour l'interface graphique
• Lancer libvirtd: sudo service libvirtd start
• Lancer virt-manager et ajouter une connection a localhost par SSH en root, en indiquant Xen comme type d'hyperviseur
• Double cliquer dessus pour se connecter
• On a accès a la liste des VM et la création de nouvelles VMs !

Attention, dans le mode para-virtualisé, on ne peut pas booter des ISO et faire l'installation comme d'habitude avec des VMs : il faut une image compatible.
La solution la plus simple est d'utiliser xen-tools, un paquet qui permet de créer des images directement utilisable sous Xen de la distro choisie !
Un exemple pratique, installons une Ubuntu, vous pouvez surement deviner les options, ici j'utilise un VG LVM comme cible pour les disques:

root@eri ~ # xen-create-image --bridge=brint --hostname=test.firanet.fr --passwd --output=/root --size=20G --memory=2G --swap=2G --pygrub --vcpus=2 --arch=amd64 --dhcp --dist=trusty --lvm=mainlvm

Pour l'utiliser sous Libvirt, il faut ensuite la convertir au format XML de Libvirt:
root@eri ~ # virsh -c xen:/// domxml-from-native xen-xm test.firanet.fr.cfg > test.firanet.fr.xml
Puis on peut l'importer :

root@eri ~ # virsh create test.firanet.fr.xml
Domain test.firanet.fr created from test.firanet.fr.xml

Il est alors possible de le démarrer par virsh ou virt-manager.
A noter que comme c'est de la paravirtu, il n'y a pas de graphique: il faut accéder à la console (tty) via xl console (ou simplement utiliser ssh).

C'est cool tout ça, ou est le piège?

Bien qu'on puisse penser que la Paravirtualisation soit plus rapide car beaucoup plus légère, il y a un petit couac lorsqu'on tourne en 64-bits.
Il faut savoir qu'un OS classique en fonctionnement ségmente la mémoire en deux grandes zones : une pour les programmes utilisateurs, et une pour la mémoire du noyau.
Lorsqu'on utilise un hyperviseur type Xen, il y a besoin d'une troisième zone pour la mémoire de l'Hyperviseur.
Malheuresement, la ou sur un système x86 32-bits on trouvait des fonctions de segmentation mémoire plus avancée, elles ont été retirées dans les architectures 64-bits car jugées non-utilisées.
Le résultat est qu'il n'y a plus que deux niveaux, et le troisième doit être implémenter par l'hyperviseur. Pour passer de l'espace utilisateur à noyau, il faut alors sauter par l'espace Xen et faire un changement de contexte, ce qui trash le cache du CPU et augmente énormément la latence. Sur des workloads avec un taux d'I/O important on peut aller jusqu'a 25% de pertes.

Mais c'est nul ! Pourquoi tu me parles de ça alors ?

Xen propose deux moyens de contourner ce problème: le premier est de faire de la virtualisation classique, avec des drivers paravirtualisés.
On émule alors la grande partie du matériel, mais les timers, accès aux disques et réseaux sont eux accélérés par un protocole spécifique: c'est le mode PVHVM.
On retrouve ce genre de fonctionnement sous KVM ou Virtualbox avec les "Guest Additions", ou VMware avec les drivers paravirtualisés.
L'autre méthode est plus novatrice: il s'agit de faire fonctionner un système paravirtualisé, en laissant à la charge du matériel la segmentation mémoire grace aux extensions de virtualisation matérielles. C'est le mode PVH (je vous invite a reprendre cette image)
Les résultats sont assez concluants, bien que le système soit encore en phase de développement.

Génial, c'est pour quand ?

Le mode PVH est inclu a partir de la version 4.4 de Xen qui est déjà disponnible sous certaines distributions.
Pour réduire encore plus la latence sur le réseau par exemple il faut aussi faire tourner le dom0 en PVH, ce qui n'est possible que depuis la version 4.5.

Conclusion ?

Xen a tendance à être assez oublié ces derniers temps, au faveur de soit la facilité d'une virtualisation complète (KVM, VMware), ou des plus récemment plébicités containers (Docker, LXC, Jails).
La para-virtualisation est cependant une alternative assez intéressante sur laquelle il mérite de garder un oeil, bien qu'elle ne soit pour l'instant limitée qu'aux systèmes UNIX avec Xen.