Et si votre serveur Linux était comme un appart en coloc où tout le monde partage la même cuisine, le même salon, les mêmes chiottes ?? Forcément, ça finit toujours mal avec quelqu’un qui monopolise les toilettes pendant que vous avez une urgence en spray, un autre fait crasher la machine à laver avec ses expérimentations douteuses de voyage dans le temps, et au final personne n’est content.
Hé bien figurez-vous qu’un développeur nommé Cong Wang de Multikernel Technologies vient de proposer une solution radicale qui consiste à donner à chaque processus son propre kernel Linux, avec ses propres core CPU, comme des colocataires qui auraient enfin chacun leur studio…
Selon le patch soumis sur la Linux Kernel Mailing List (LKML), cette architecture “multikernel” permettrait de faire tourner plusieurs noyaux Linux indépendants sur la même machine physique. C’est pas vraiment de la virtualisation classique façon VMware ou KVM, mais c’est plutôt comme si vous découpiez votre ordinateur en tranches et que chaque tranche vivait sa vie. Le truc marrant, c’est que Cong Wang n’est pas un petit nouveau qui débarque avec ses idées folles. Le bonhomme a déjà contribué à plus de 1000 patches au noyau Linux et il maintient le sous-système de traffic control . Autant dire qu’il sait de quoi il parle quand il touche au code du noyau.
D’ailleurs cette idée de séparer les kernels rappelle furieusement le projet Barrelfish que Microsoft Research et l’ETH Zurich avaient lancé il y a quinze ans. À l’époque, ils voulaient traiter l’OS comme un système distribué où chaque core CPU aurait son propre kernel qui communique avec les autres par messages. Sauf que voilà, c’était trop tôt. Les processeurs n’avaient pas assez de cores pour qu’on puisse se permettre ce genre de luxe, et puis franchement, qui avait besoin de ça en 2009 ?
Aujourd’hui avec nos CPU à 128 cores et nos problèmes de sécurité qui explosent, l’idée prend soudainement tout son sens.
Selon Phoronix et les patches sur la LKML, l’implémentation de Wang utilise kexec, ce mécanisme qui permet normalement de redémarrer directement dans un nouveau noyau sans repasser par un reboot. Sauf qu’ici, au lieu de remplacer le noyau existant, on en charge plusieurs qui vont cohabiter. Chaque kernel se voit attribuer ses propres cores CPU et ils communiquent entre eux via un système d’interruptions inter-processeurs (IPI) spécialement conçu pour l’occasion. Et dans les 7 patches proposés en RFC, Wang prévoit des mécanismes de surveillance pour gérer tous ces petits mondes parallèles.
Et pendant que Cong Wang bricolait son multikernel dans son coin, les géants du cloud comme Amazon, Microsoft et Google ont développé en parallèle une technologie appelée KHO ( Kexec HandOver ) qui permet de préserver l’état système lors du changement de kernel. En gros, ils veulent pouvoir mettre à jour le noyau Linux de leurs serveurs sans perdre les VMs qui tournent dessus. Sauf que si le multikernel de Wang fonctionne vraiment, ça pourrait rendre leur stack de virtualisation complètement obsolète.
Car pourquoi s’embêter avec des hyperviseurs complexes quand on peut juste donner à chaque workload son propre kernel ?
Le plus drôle dans tout ça, c’est que Wang admet candidement dans son RFC que pour l’instant, ça marche “que sur sa machine de dev avec des paramètres hardcodés”.
Maintenant si cette techno décolle, on pourrait voir des trucs assez dingues. Genre un kernel temps réel qui gère les processus critiques pendant qu’un kernel classique s’occupe du reste. Ou alors des kernels spécialisés pour différents types de workloads : un pour le machine learning, un pour les bases de données, un pour le réseau. Vous pourriez même imaginer des kernels avec différents niveaux de sécurité du genre un kernel ultra-paranoia pour vos données sensibles et un kernel plus relax pour Netflix. Et le plus beau c’est que si un kernel plante, les autres continuent de tourner tranquillement.
C’est comme avoir plusieurs systèmes de secours intégrés directement dans la machine.
Mais attention, on parle quand même d’une RFC, et pas encore d’un truc prêt pour la prod. La communauté des barbus du noyau va probablement passer des mois à débattre de chaque ligne de code, et c’est tant mieux parce que toucher à l’architecture fondamentale de Linux, c’est pas comme patcher un bug dans Firefox. Si ça merde, c’est potentiellement des millions de serveurs qui partent en vrille.
Au final, que ce patch soit accepté ou pas, ça montre surtout que Linux continue d’évoluer de manière radicale pour toujours aller plus loin ! Et si vous l’évolution de ce projet, tout se passe sur la LKML .
Intéressant comme réflexion. J'ai beaucoup utilisé Hyper-V dans les PME par le passé.
Le combo Hyper-V + Veeam permet de faire tourner 2 VM "incluses" dans la version standard, ce qui n'est pas négligeable versus le coût d'une datacenter.
Bref, parfois il faut être pragmatique, comme dans ce cas d'usage.
Alors là, c’est le genre de nouvelle qui fait plaisir ! Canonical vient de rendre Multipass, leur gestionnaire de machines virtuelles Ubuntu, 100% open source. Fini les bouts propriétaires cachés, on peut maintenant fouiller dans absolument tout le code !
Bon, je sais que vous connaissez déjà Multipass. C’est cet outil génial qui vous pond une VM Ubuntu en une seule commande. Super pratique pour tester des trucs sans pourrir votre système principal, ou pour simuler des environnements cloud en local. Mais jusqu’à maintenant, il y avait un hic : une partie du code tournant sur Windows et macOS était encore propriétaire. Et ça, ça faisait grincer des dents dans la communauté.
Un développeur du nom de Petr Beneš vient de partager une technique absolument brillante pour faire croire à une machine virtuelle qu’elle a un ventilateur CPU. Oui, un ventilo virtuel dans une VM.
Mais pourquoi diable faire ça, vous allez me dire ?
Eh bien figurez-vous que les créateurs de malwares sont devenus super malins ces dernières années. Pour éviter que leurs petites saloperies soient analysées par les chercheurs en sécurité, ils ont développé tout un tas de techniques pour détecter si leur code s’exécute dans une machine virtuelle.
Connexion