Virtualisation : les chemins ouverts après la refonte des licences

Une migration d'hyperviseur ne consiste pas à déplacer des machines virtuelles. Techniquement, ce transfert est l'étape la mieux outillée et la plus rapide. Ce qui prend du temps, ce sont les quinze accessoires qui pendaient à l'ancien hyperviseur : l'agent de sauvegarde, la supervision, l'automatisation du déploiement, le contrôle d'accès, la connexion au stockage, et les habitudes de l'équipe d'exploitation.

Ce qui a changé dans la facture

Le modèle historique reposait sur une licence perpétuelle par processeur, assortie d'un support annuel. Le modèle actuel repose sur un abonnement facturé au cœur, avec un nombre minimal de cœurs facturés par processeur puis un volume minimal par commande. Deux conséquences pratiques en découlent. D'abord, les serveurs équipés de processeurs à faible nombre de cœurs paient pour des cœurs qu'ils n'ont pas. Ensuite, les petits parcs sont proportionnellement les plus touchés, puisqu'ils se heurtent aux minimums de commande.

Le second effet est moins visible : la sortie du modèle perpétuel supprime la possibilité de figer une version et de continuer à l'exploiter sans support. La dépense devient récurrente et non plus amortissable, ce qui change la nature de l'arbitrage budgétaire.

Trois trajectoires, trois profils de risque

La première trajectoire est légitime quand le parc est important, que l'outillage est profondément intégré et que la négociation porte sur un volume significatif. Elle ne règle rien sur le fond, mais elle achète du temps, ce qui est parfois exactement ce qu'il faut.

La deuxième s'appuie sur des hyperviseurs alternatifs devenus crédibles en production : les distributions bâties sur le noyau Linux et son module de virtualisation, les solutions issues du monde de la virtualisation ouverte, ou l'hyperviseur intégré au système d'exploitation serveur le plus répandu. Le point de vigilance n'est pas la capacité à exécuter des machines virtuelles, acquise depuis longtemps, mais la maturité de l'écosystème autour : sauvegarde compatible, haute disponibilité éprouvée, gestion des grappes, intégration avec le stockage partagé, et disponibilité d'un support commercial si vous en voulez un.

La troisième consiste à cesser d'exploiter l'hyperviseur pour consommer des machines virtuelles comme un service. Le coût de licence disparaît de vos comptes parce qu'il est absorbé par l'opérateur, ce qui ne veut pas dire qu'il n'existe plus. Cette trajectoire déplace le sujet vers le contrat, et notamment vers les conditions de sortie, que nous détaillons dans notre analyse de la clause de réversibilité.

Chiffrer le coût de bascule

Un projet de changement d'hyperviseur se décompose toujours de la même façon. Un inventaire complet des machines, de leurs dépendances et de leurs fenêtres d'arrêt possibles. Une reprise de la chaîne de sauvegarde, car l'agent et le mode de capture changent. Une reprise de la supervision et des alertes. Une reprise de l'automatisation, qui est souvent la partie la plus longue quand des années de scripts ont été écrites contre une interface donnée. Une formation de l'équipe. Enfin, une période de double exploitation pendant laquelle les deux plateformes coexistent, avec leurs deux coûts.

Sur un parc de cent machines virtuelles réparties sur six hôtes, ce projet se compte en trois à six mois de calendrier et en dizaines de jours-homme, largement dominés par le réoutillage. La méthode qui réduit le risque consiste à procéder par lots, en commençant par les environnements de test et de préproduction, puis par les applications internes, et en gardant la production critique pour la fin.

Le préalable indispensable est un inventaire fiable. Beaucoup de projets calent parce que personne ne sait quelles machines servent encore, ni à quoi. C'est le sujet que nous traitons dans nos notes sur la tenue d'une CMDB vivante, où le taux de fraîcheur des découvertes est le seul indicateur qui compte.

Ce que la bascule ne doit pas emporter avec elle

Deux garde-fous méritent d'être posés avant de commencer. Le premier concerne la sauvegarde : tant que la chaîne de restauration n'a pas été testée sur la nouvelle plateforme, l'ancienne ne s'éteint pas. Le second concerne le réseau : changer d'hyperviseur revient souvent à changer de modèle de commutation virtuelle, ce qui peut invalider silencieusement des règles de segmentation. Ce point rejoint directement notre analyse de la taille à partir de laquelle une orchestration de conteneurs sur site se défend, car les mêmes équipes finissent par exploiter les deux couches et par cumuler les deux charges.

Enfin, si le mouvement s'accompagne d'un déplacement de matériel vers un autre site, les contraintes physiques reprennent le dessus : densité, puissance souscrite, fenêtres d'accès. Nous les avons détaillées dans notre comparatif entre baie entière, demi-baie et unité.