Il existe deux hyperviseurs majeurs Open Source : KVM et Xen. Cet article fait une brève comparaison de l'historique de ces deux projets, présente leur architecture technique puis ce qui les différencie.

Xen

Xen est un hyperviseur distribué sous licence GPLv2. A l'origine développé à l'Université de Cambrige, la première version publique est disponible en 2003.

Xen et Citrix

L'entreprise fondée par le développeur principal pour soutenir le projet, XenSource Inc, est rachetée en 2007 par Citrix Systems. Citrix effectue alors un travail important de "packaging" et "branding" pour développer une offre commerciale autour de l'hyperviseur libre et gratuit.

Fin 2009 Citrix annonce que sa surcouche propriétaire sera désormais totalement Open Source et reverse le code développé dans le projet communautaire Xen Cloud Platform (XCP) dont la première version stable est sortie en mars 2011. Deux fonctionnalités avancées de l'API de Citrix ne sont pas libérées : la répartition automatique de charge et le failover automatique. Ces fonctionnalités sont disponibles dans l'édition payante de Xen : Citrix XenServer.

Actuellement les contributeurs principaux de l'hyperviseur Xen et de XCP sont employés par Citrix.

Architecture de Xen

Techniquement Xen est un hyperviseur "bare metal", aussi appelé hyperviseur de "type 1". Le code de Xen est exécuté juste au-dessus du matériel, avec un niveau de privilèges d'accès aux ressources système (CPU, IO, RAM) maximal. Xen implémente certaines fonctions qu'on retrouve dans tous les OS : un ordonnanceur, un gestionnaire d'interruptions, quelques drivers etc. La philosophie principale est d'avoir un minimum de code pour réduire le nombre de bugs/failles de sécurité et de limiter le code partagé entre les différentes machines virtuelles pour augmenter leur isolation réciproque. La plupart des facilités d'administration de l'hyperviseur sont accessibles à travers une machine virtuelle spécialement privilégiée instanciée tout de suite après le démarrage de l'hyperviseur. Cette machine virtuelle, appelée "domain 0" abrégé dom0, est un système d'exploitation complet (au choix Linux, BSD, Solaris etc...) dont le noyau est spécialement modifié pour communiquer avec l'hyperviseur sous-jacent. Le dom0 contrôle (démarre, arrête, surveille) les autres machines virtuelles non privilégiées (appelées "User domain" ou domU).

Les domU peuvent être paravirtualisés (ParaVirtualized - PV) ou matériellement virtualisés (Hardware-assisted Virtualized Machine – HVM). La paravirtualisation implique que le noyau de l'OS de la machine virtuelle doit être modifié afin de coopérer avec l'hyperviseur pour l'accès aux ressources physiques. En pratique lorsqu'une machine est paravirtualisée, c'est le dom0 qui effectue les opérations d'E/S au profit de la VM puis lui « retourne » les résultats. C'est pourquoi il faut toujours s'assurer que le dom0 possède suffisamment de mémoire vive et de ressource CPU pour opérer correctement en faveur des VM.

La virtualisation matérielle ne nécessite pas de modifications de l'OS invité car le CPU, au travers d'un jeu d'instructions spéciales (Intel VT-d ou AMD-V), fait croire au système invité (la VM) qu'il a un accès direct au matériel. Cependant, cela entraîne un surcoût de fonctionnement car certaines demandes d'accès aux ressources physiques effectués par la VM doivent être interceptés pour vérifier qu'elles n'affectent pas les autres VM.

Les performances des opérations d'E/S des VM paravirtualisées sont significativement meilleures que celles des VM HVM. Les machines virtuelles Windows, dont le noyau ne peut être modifié, sont nécessairement HVM. Cependant, pour améliorer les performances de ces VM, des drivers additionnels peuvent être installés après le système d'exploitation "de base", ces drivers étant spécialement optimisés pour être exécutés dans un contexte virtualisé. On parle alors de "PV on HVM" et les performances, comparées à la paravirtualisation, sont similaires.

Intégration de Xen et Linux

Bien qu'ayant une licence compatible avec celle du noyau Linux, ni l'hyperviseur Xen ni les modifications apportées au noyau Linux pour qu'il puisse jouer le rôle de dom0 (patch dom0) ne sont intégrés dans le noyau Linux officiel. La cause est principalement une question de stratégie d'intégration, la communauté Linux ne souhaitant intégrer que des patchs de taille modérée alors que le patch dom0 est développé par la communauté Xen comme un seul bout de code monolithique.

Cela rend la maintenance d'un serveur Xen parfois un peu complexe. Les distributions Linux doivent packager l'hyperviseur et une version du noyau Linux spécialement patchée pour le support de Xen, en parallèle. Seul SUSE et Debian supportent officiellement Xen, au contraire de Red Hat et Canonical.

Cependant, depuis la version 2.6.36 du noyau Linux sortie en octobre 2010, un effort est fait pour intégrer "upstream" le support de Xen. L'intégration devrait se terminer autour de la version 2.6.41 (début 2012) et ainsi un noyau Linux non modifié pourra être utilisé en tant que dom0 et domU (indifféremment PV ou HVM).

L'hyperviseur Xen, initialisé après le bootloader (grub ou lilo) mais avant tout système d'exploitation (dom0), n'est pas et ne sera probablement jamais intégré au noyau Linux officiel. L'hyperviseur est indépendant des OS qu'il exécute et la communauté Linux supporte déjà une autre technologie de virtualisation.

KVM

KVM pour Kernel Virtual Machine est une autre technologie de virtualisation Open Source et est distribuée sous licence GPLv2 ou LGPL. A l'origine fork de l'émulateur QEMU, les deux projets sont régulièrement synchronisés et la partie spécifique à KVM se concentre sur l'accélération matérielle des VM (profitant des jeux d'instructions des CPU) et sur l'intégration dans le noyau Linux. Le module noyau KVM est disponible nativement dans le noyau Linux depuis février 2007.

KVM et Red Hat

En septembre 2008, Red Hat rachète la société israélienne Qumranet à l'origine de KVM et annonce que sa prochaine génération de Enterprise Linux (version 6, sortie en novembre 2010) supportera uniquement KVM. Ainsi Red Hat est le principal supporter et contributeur de KVM et de son API d'administration, elle aussi sous licence Open Source.

Architecture de KVM

L'architecture de KVM est très différente de celle de Xen. KVM est disponible sous forme de module Linux, intégré au noyau Linux. Le processus de démarrage du serveur hôte n'est pas modifié par la présence de KVM et une machine virtuelle se résume à un processus Linux comme un autre. On peut comparer KVM à Virtualbox ou VMWare Workstation (hyperviseur de "type 2"), à ceci près que, bien que l'administration de l'hyperviseur se fait depuis "l'espace utilisateur" (user-land), la machine virtuelle elle-même tourne en espace noyau (kernel-land).

KVM ne supporte pas la paravirtualisation donc nécessite une CPU avec le support de la virtualisation matérielle. Pour obtenir des performances d'E/S satisfaisantes pour les VM HVM, KVM profite de l'intégration native des pilotes VirtIO (Virtual IO) dans le noyau Linux depuis la version 2.6.25 (avril 2008). Ces pilotes sont optimisés pour un contexte de virtualisation (PV on HVM). On profite ainsi de la facilité de la virtualisation complète (inutile de modifier le système invité) avec les performances de la paravirtualisation. Évidemment comme les drivers VirtIO ne sont pas intégrés d'office dans Microsoft Windows, ainsi comme c'est le cas pour Xen, il faudra les mettre en place a posteriori d'une installation d'une VM Windows.

Bien qu'il existe des implémentations de KVM pour *BSD, KVM est d'abord développé pour Linux. Toutes les distributions majeures de GNU/Linux supportent KVM.

Brève comparaison entre KVM et Xen

Les deux hyperviseurs offrent aujourd'hui le même niveau de fonctionnalité et de stabilité. Si l'approche ambitieuse de Xen, à savoir tout développer en partant de rien et ne pas reposer sur le noyau Linux lui a longtemps conféré un avantage en terme de performances et d'isolation entre VM et donc de sécurité, ces avantages sont désormais historiques. Le support croissant de KVM dans les distributions GNU/Linux (parfois au dépend de Xen, plus délicat à packager) en est l'illustration. Cependant l'intégration complète du patch Xen dom0 au sein du noyau Linux est à surveiller car il pourrait contribuer à (re)démocratiser Xen.

La collaboration du projet KVM (et de Red Hat) avec la communauté du noyau Linux semble bénéfiques pour les deux parties. En effet, plusieurs fonctionnalités récemment implémentées dans le noyau Linux sont déjà directement mise à profit par KVM. Les deux principales d'entres elles sont Linux Kernel Samepage Merging (KSM) un démon de déduplication de pages mémoire, très utile dans un contexte de surallocation de RAM (consolidation agressive) et le support des Transparent Huge Pages qui limite la fragmentation de la RAM. Enfin, avec KVM, l'ordonnanceur du système hôte voit chaque VM comme un simple processus Linux. Il est donc possible, bien que que non trivial, de profiter des "cgroups" Linux pour faire notamment de "l'IO throttling".

En conclusion, KVM offre de solides arguments face au vénérable Xen. Apres avoir rattrapé son retard, le rythme rapide auquel il évolue et sa capacité à tirer rapidement partie des nouvelles fonctionnalités du noyau Linux devrait valider son titre d'hyperviseur Open Source de référence.