traduction

Xen vs XenServer vs KVM vs Proxmox

Traduction d'un post au sujet de Xen, XenServer, KVM et Proxmox VE par Olivier Lambert de la société Vates

technonagib

11 juin 2022 • 9 min de lecture

Je vous partage ce post très intéressant de Olivier Lambert (CEO et co-fondateur de Vates, créateur de Xen Orchestra et XCP-ng) sur le forum de Lawrence Systems. On y apprend pas mal de choses :

Le fonctionnement de Xen,
Comment Amazon s'est basé sur Xen pour monter son cloud avec AWS,
Le rachat de XenSource par Citrix, l'arrivée de KVm et son rachat par Red Hat,
Les différences entre Xen et KVM,

Bref, un pur régal à lire.

Bonne lecture!!!!

Xen vs XenServer

l'hyperviseur est juste "Xen", pas "XenServer". XenServer est la plateforme complète créée par Citrix, et la source du fork qui a donné XCP-ng.

Pour être encore plus précis, il s'appelle Xen Project, car Citrix n'a pas voulu donner le nom de la marque Xen à un projet hébergé par la Fondation Linux (pour éviter toute confusion commerciale). Ce projet est un véritable projet open source GPLv2, avec des contributions de Citrix, Arm (beaucoup ! voir la note ci-dessous), Suse, AWS et ainsi de suite. Il y a également de grands noms dans la liste de diffusion de pré-divulgation (les membres peuvent être vus ici : Xen Security Problem Response Process - Xen Project 6 BTW la politique de sécurité du projet Xen est l'une des meilleures que je connaisse dans tout le monde informatique). Ces utilisateurs sont en général de grands utilisateurs de Xen puisqu'ils DOIVENT corriger certains problèmes avant qu'ils ne soient rendus publics, ce qui donne une vision intéressante.

Pourquoi Arm et Xen ? Dans le monde de l'automobile, Xen est parfaitement adapté : vous pouvez "partitionner" le matériel de manière statique, par exemple une carte mère, avec plusieurs CPU affectés à différentes VM. Par exemple, une VM pour le divertissement, l'autre pour l'ECU/actifs critiques. Sans risques de sécurité ni fuite de données de la mémoire puisque la mémoire est vraiment isolée et que Xen la contrôle.

Et pour ajouter plus de complexité, Citrix a renommé XenServer en Citrix Hypervisor, mais c'est exactement la même chose.

En amont et en aval

C'est également une question que je rencontre souvent chez les personnes qui n'ont pas une connaissance approfondie du projet Xen et de Citrix. Le projet Xen est l'amont, comme l'API appelée XAPI. Ces projets sont hébergés par la fondation Linux. Tout le monde contribue à Xen comme je l'ai dit juste avant.

Citrix Hypervisor/XenServer est l'aval de ces projets. XCP-ng est également un aval au même niveau que Citrix Hypervisor. Il y a donc un amont pour l'hyperviseur (projet Xen) et deux aval (XenServer et XCP-ng). Donc non, XCP-ng n'est PAS l'aval de XenServer.

Xen chez AWS

Note : Je ne travaille pas chez AWS, c'est tout ce que j'ai recueilli après des années de conversations diverses avec différentes personnes autour du monde de Xen et AWS.

C'est simple : AWS est devenu le premier fournisseur de Cloud public grâce au projet Xen. C'est un fait. Puisqu'il s'agit d'une licence GPLv2, vous pouvez modifier le code sans contribuer à l'amont, puisqu'en tant que fournisseur de nuages, vous ne livrez pas réellement le logiciel. AWS a beaucoup fait cela, car ils voulaient protéger leur avantage concurrentiel dans l'espace de virtualisation pour leur service de Cloud. Ils ont également construit leur propre paquet d'outils, qui n'est pas du tout public ou open source.

Quoi qu'il en soit, à un moment donné, AWS a réalisé qu'elle avait le pouvoir de construire sa propre pile, du matériel au logiciel. Ils ont pratiquement inventé le concept de "DPU" (Data Processing Unit) et, grâce à leur grande expérience de l'exécution de Xen à l'échelle de millions de machines, ont décidé d'expérimenter les choses à partir de zéro : construire leur propre matériel dédié pour en tirer le meilleur parti, avec une pile logicielle personnalisée par-dessus.

Il est amusant de constater que l'écriture d'un hyperviseur n'est pas si difficile si vous savez sur quel matériel il fonctionnera. Ce qui rend Xen relativement complexe, c'est le fait qu'il peut fonctionner sur la plupart des plateformes x86 du monde. Croyez-moi, c'est vraiment DIFFICILE. Le matériel est bogué comme l'enfer, et vous devez constamment corriger divers bugs, du matériel lui-même ou du BIOS/UEFI ou du fimrware. C'est un cauchemar. Linux est aussi plein de solutions de contournement.

Mais avec cette opportunité d'obtenir votre propre matériel, AWS est parti d'une page blanche. Nitro, leur hyperviseur, n'est pas votre KVM habituel. C'est une version très réduite au minimum, avec un code probablement plus spécifique que le code KVM existant, pour gérer leurs accélérateurs matériels dédiés. Je pense que leur conception est vraiment géniale, mais ne vous attendez pas à trouver cela dans votre distro avec votre matériel habituel. C'est pourquoi vous ne pouvez pas dire que "AWS est passé à KVM", ce n'est tout simplement pas vrai.

Ce n'est pas vrai non plus parce qu'ils ne vont pas remplacer toutes leurs instances par Nitro. La plupart de leur flotte fonctionne probablement encore sous Xen, parce que c'est là, c'est sûr et c'est compatible avec toutes les machines qu'ils peuvent s'offrir sur le marché. AWS a donc simplement ajouté une nouvelle solution dans sa pile, elle ne l'a PAS remplacée.

Le succès de KVM

Le succès de KVM est indéniable. Il y a de multiples raisons à cela : certaines sont techniques (mais cela a un coût, voir ci-dessous), d'autres sont dues aux principaux acteurs.

L'origine

Xen ayant été le premier hyperviseur Open Source, il aurait pu être l'unique acteur dans ce domaine. Mais ce n'est pas le cas aujourd'hui, puisque vous pouvez voir de nombreux déploiements de KVM dans le monde entier. Mais pourquoi KVM existe-t-il ?

Parce que lorsque Citrix a acquis Xen Source Inc. (vers 2007), tout le monde a eu peur. Citrix n'a pas une grande expérience de l'Open Source, puisque son activité principale est le bureau virtuel et la collaboration avec Microsoft. Imaginez que vous soyez RedHat à cette époque : vous êtes les champions du noyau Linux, et voilà qu'un hyperviseur fabriqué par Citrix s'impose partout. Alors vous réagissez et vous créez KVM, un module au-dessus du noyau Linux (parce que vous le connaissez très bien) pour faire de la virtualisation. Ainsi, vous ne dépendez pas de Citrix qui fait n'importe quoi avec un logiciel fraîchement acquis.

De plus, comme vous êtes Redhat, vous faites pression pour cela partout. Après tout, vous êtes le numéro 1 de l'Open Source et de Linux. Vous l'intégrez donc dans votre produit pour qu'il soit plus facile à utiliser dans le contexte de la virtualisation des serveurs. De l'autre côté, Citrix ne se préoccupe pas du marché de la virtualisation des serveurs, bien qu'elle ait un excellent produit appelé XenServer. Parce que n'oubliez pas que Citrix ne se soucie pas du marché de la virtualisation des serveurs, ils sont tous dans le marché de la virtualisation des ordinateurs de bureau (plus de marges/$$$$ et aussi leur activité principale après tout).

C'est là que KVM a commencé à obtenir plus de traction.

Aspects techniques

L'autre raison est d'ordre technique. Depuis qu'il est intégré/poussé par RedHat, les gens ont commencé à compter sur lui, mais aussi à y contribuer. D'un point de vue technique, KVM est beaucoup plus permissif que Xen. Vous pouvez donc faire des choses amusantes relativement rapidement, comme virtio et autres. Cependant, cela se fait au prix d'une isolation moindre en raison d'un modèle/architecture moins " isolé " que Xen, qui est un " vrai type 1 ". La conception de Xen est plus proche de ESXi, KVM est plus "open bar". Mais cet aspect a également fait partie de son succès : simplicité vs sécurité, en termes d'adoption et de développement. Je ne dis pas que KVM n'est pas du tout sécurisé. Il s'agit d'une conception différente, qui est intrinsèquement moins sûre. L'un est-il meilleur que l'autre ? Difficile à dire, il n'y a pas de solution miracle.

À mon avis, ce n'est pas ce qui compte en fin de compte. Ce qui compte, c'est l'intégration et un produit facile à utiliser. "Nous" avons un avantage sur les aspects de sécurité avec XCP-ng, mais nous avons plus de travail pour développer de nouvelles fonctionnalités.

Autres considérations

Un autre aspect que j'apprécie chez Xen est sa taille. Ce n'est pas une mesure parfaite, mais pour vous donner un ordre de grandeur : La base de code entière de Xen fait 2 % de la taille du noyau Linux en termes de lignes de code. Cela permet une chose très intéressante :

En tant que véritable Type 1, vous démarrez d'abord votre matériel sur Xen, qui est une sorte de micro-noyau en fin de compte. Cela signifie que la surface d'attaque est VRAIMENT faible.
Comme il n'est pas si grand, vous pouvez lire l'ensemble du code de base et tout comprendre. C'est un moyen fantastique de découvrir ce qu'est un hyperviseur, puis d'aller plus loin pour l'améliorer.
De plus, le projet Xen n'est pas non plus très important, ce qui signifie que vous pouvez faire avancer les choses plus rapidement si vous investissez dans ce projet, contrairement aux contributions de Linux/KVM, auxquelles IBM, Google et d'autres font confiance.

L'avenir de Xen ?

C'est là que ça compte. Chez Vates, nous nous sommes engagés à devenir l'un des plus grands mainteneurs du projet Xen. Nous y investissons beaucoup de R&D, car oui, il y a beaucoup de choses à faire ! C'est pourquoi notre équipe de développement XCP-ng a doublé depuis l'année dernière et a dépassé le nombre de 10 développeurs dédiés (déjà 3 nouveaux développeurs cette année !). À ce rythme, nous dépasserons même l'équipe de Citrix XenServer très bientôt (si ce n'est pas déjà le cas).

C'est aussi pourquoi nous n'avons pas peur de ce qui pourrait arriver au projet Xen, même si Citrix décide de l'arrêter à un moment donné pour une raison quelconque (il est vraiment difficile de deviner leurs intentions). Le projet Xen est un projet Open Source totalement indépendant. Et il a trouvé un nouveau foyer d'accueil chez Vates.

Proxmox vs XCP-ng ?

J'ai entendu dire que vous avez eu des commentaires enflammés @LTS_Tom . Nous avons eu la même chose en France quand quelqu'un sur Twitter qui utilisait Proxmox a décidé de passer à XCP-ng. Certaines personnes de la communauté Proxmox se sont mises en colère à ce sujet. Je ne comprends pas vraiment pourquoi certaines personnes se sentent menacées par les choix des autres : la réflexion :

Ici, à Vates, nous respectons profondément le projet Proxmox, puisqu'il est entièrement Open Source. Je n'ai pas ce niveau de respect contre la politique d'entreprise d'une société leader sur le marché de la virtualisation, qui pousse toujours les prix au maximum. Si vous l'aimez, tant mieux pour vous, personne ne vous oblige à passer à XCP-ng ! (mais nous respectons leur grand niveau technique et leurs ingénieurs évidemment !).

Il est également important (je pense) de comprendre la différence de philosophie entre les deux plateformes. Ici, chez Vates, nous voulons construire la plateforme de virtualisation la plus intégrée, et nous nous y consacrons à 100%. Nous ne faisons pas d'autres choses, comme la passerelle de messagerie et autres. Comme je l'ai dit, notre véritable ambition est de maîtriser entièrement tous les composants de la pile, et même d'être les plus grands contributeurs du projet Xen. Je ne pense pas que ce soit une priorité chez Proxmox, puisqu'ils intègrent principalement KVM et d'autres technologies open source (c'est très bien ! ce n'est juste pas le même périmètre/investissement).

Une autre différence de philosophie est d'être vraiment ouvert, pas seulement le code, mais avec notre communauté. Xen Orchestra et XCP-ng sont directement issus des retours des utilisateurs. Nous avons fait de notre mieux pour simplifier les contributions des utilisateurs (sur Github) mais aussi pour travailler avec des partenaires, en matériel ou en logiciel. Nous voulons vraiment construire un écosystème. Ce ne sont pas les gens qui viennent à nous, mais bien nous qui venons à différentes communautés (comme dans ce billet).

Enfin, l'autre grande différence est l'aspect technique (au-delà de Xen vs KVM) : nous voulons offrir une expérience intégrée qui ne nécessite aucune connaissance de Linux. C'est pourquoi la XAPI (API de XCP-ng/XenServer) est formidable : la création d'un stockage ne nécessite aucune commande Linux, de même pour le réseau et autres. Cela signifie donc qu'elle n'est pas destinée à être bricolée comme on peut le faire avec Proxmox ! C'est une conséquence directe de la philosophie KVM/Linux où l'hôte a un contrôle sur l'ensemble du système. Ce qui n'est pas le cas dans XCP-ng, votre "hôte" est en fait votre dom0 qui tourne déjà au-dessus de Xen.

J'espère avoir répondu à certaines questions pertinentes que j'ai vues dans la communauté et dans votre vidéo.

Notes : Ça me rappelle qu'il y a un projet axé sécurité nommé Qube OS basé justement sur Xen. Ça corrobore les propos de Olivier Lambert sur l'isolation bien meilleure côté Xen.