ESXi/ARM : Retour sur le portage vers Raspberry Pi

Rappelez-vous, en Août dernier, VMware annonçait le portage de ESXi sur ARM64 (voir mon billet ici). A l’époque, la plateforme avait été présentée lors du keynote comme fonctionnant sur du matériel “server-grade” et disposant déjà de la plupart des fonctions standards comme vMotion.

Entre temps, l’équipe en charge de ce projet nous a concocté une petite surprise, une prouesse en fait, en l’état du développement de ESXi/ARM : son adaptation à la plateforme RaspBerry Pi (version 3) ! Assez incroyable, quand on pense aux capacités très modestes de cette plateforme, alimentée par son port USB ^^

J’ai eu l’occasion de discuter avec Régis Duchesne, membre de l’équipe en charge de ce projet et qui était présent au stand IoT/Edge computing hier. Voici un petit compte-rendu de cette super rencontre.

En l’état, la plateforme de démo, un RaspBerry Pi 3 donc, permet uniquement de booter ESXi et initialiser le stack VSAN (ça vous dirait un petit Witness VSAN à 40 euros ? ^^), mais en théorie, toutes les fonctions de virtualisation sont prêtes et capables de rendre les services qu’on attend d’elle. En fait, Régis m’a précisé que cela a été un très gros challenge de faire rentrer un ESXi dans un Pi3 en si peu de temps (quelques semaines) ; en effet, lors de l’annonce du portage en Août, il n’était pas encore question d’aller si loin dans le downscaling.

Il a notamment fallu adapter le code vis à vis du gestionnaire d’interruption qui diffère sensiblement de ceux des plateformes expérimentées jusqu’à présent. De même, ils ont utilisé un adptateur USB-Ethernet pour pouvoir monter la connectivité réseau car le driver ESXi spécifique de l’interface intégré au Pi 3 n’existe pas encore… bref, un sacré bidouillage, mais qui prouve aussi l’architecture solide et souple du code d’ESXi.

D’ailleurs, même si aujourd’hui la commercialisation de cette nouvelle plateforme n’est pas d’actualité, nous avons déjà tous bénéficié des avancées de ce développement : certains bugs dans le code ont été trouvés grâce à ce portage puis “up-streamé” (dans jargon VMware) vers la branche x86 de l’hyperviseur. Ce sera aussi le cas pour les optimisations du code réalisées sur ARM. On peste souvent sur la lourdeur des développements d’applications et systèmes actuels, certains développeurs considérant que “les plateformes suivront, il suffira de rajouter du CPU ou de la RAM” : définitivement, cette expérience prouve une fois de plus que l’optimisation reste une composante fondamentale du travail de tout développeur, de mon point de vue.

En terme de perspectives, aujourd’hui VMware est clairement positionné en veille sur l’IoT. Régis a pris un use case à venir qui concentre une partie de l’attention : les “IoT gateways”. En substance, la société (et d’autres avec elle d’ailleurs) considère qu’à terme, dans nos logements, dans nos entreprises, existeront des concentrateurs regroupant des interfaces de gestions de la plupart des objets connectés. Se faisant, il s’agit ici de proposer une architecture virtuelle qui libèrerait les développeurs des contraintes matérielles tout en concentrant et isolant ces modules sur une plateforme unique, à la manière de ce qu’on connait aujourd’hui sur la virtualisation serveur. On imagine ici que ces “petites VMs” seraient automatiquement déployées à la demande des IoT connectés, utilisant des dépôts publics sur le Net, puis démarrée sur l’IoT Gateway.

Concernant l’autre cible à laquelle on pense rapidement, à savoir les serveur ARM en Data Center, Régis a été clair : aujourd’hui, si nous avions vraiment à y gagner énergiquement, financièrement ou en terme de performance par watt, ARM serait déjà assez largement déployé dans nos productions. Or, force est de constater qu’à part certains domaines très particuliers chez les cloud providers (je pense notamment à ScaleWay, qui vous propose des serveurs dédiés et virtuels sur base ARM), l’écosystème des serveur ARM est plus que confidentiel. En fait, il s’avère que ce qu’on arrive à faire en terme de consolidation et d’optimisation dans le monde Intel est globalement équivalent à ce qu’on pourrait faire aujourd’hui avec ARM. Par voie de conséquence, aucune raison pragmatique de changer, pour le moment en tout cas.

En résumé, ESXi/ARM représente pour le moment une plateforme de démonstration technologique, qui profite aussi indirectement à nos environnements x86. Les débouchés pour VMware sont clairement à venir. En tout état de cause, pour les geeks que nous sommes, cela reste une expérience vraiment cool et tout le monde espère qu’on puisse disposer, dans un futur proche, d’une distribution utilisable, ne serait-ce que pour s’amuser avec chez soi, pour quelques dizaines d’euros !!

Un grand merci à Régis pour son temps et son enthousiasme. d’ailleurs, petit teaser, il est très probable qu’on puisse l’inviter dans une prochaine session VMUG à Nantes, il se fera un plaisir de répondre à toutes vos question ! … à suivre ^^

2 thoughts on “ESXi/ARM : Retour sur le portage vers Raspberry Pi

  1. J’adore. Malheuresement je n’ai pas eu occasion de rencontrer Regis. (Quelle dommage). rien que pour le VSAN c’est clairement “huge” de pouvoir proposer (peut etre) dans le future, l’installation sur 2 hotes, avec la witness sur Rapsberry.. –:).
    J’aime bien clairement le mot “optimization du code”. Pendant la General Session, VMware a montré la facture AVANT et APRES virtualisation chez un client, dans le passée. Pres de 80% économie d’energie. Awesome. C’est ça que j’adore chez VMware. Constante Innovation et recherche. Ravis de rencontrer l’auteur de ce blog qui mérite d’etre connu d’avantage. Bravo.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.