Il en va souvent ainsi lorsqu’un premier de la classe fait une grosse bourde. Invariablement, les cancres au fond de la classe ricanent et se gaussent des mésaventures de l’infortuné. Le problème avec la récente boulette de Vmware est qu’elle ne fait rire personne. Le numéro un mondial de la virtualisation, dont l’hyperviseur contrôle près de 95% du marché, a en effet “oublié” de retirer une portion de code de VMWare ESX Server 3.5 Update 2 qui invalide le produit passé le 12 août. Cette bombe temporelle, vraisemblablement insérée pendant la phase bêta du produit, n’a pas été retirée, ce qui fait que des milliers de serveurs en production ayant migré vers la dernière version du logiciel ont commencé à dérailler le 12 au matin. Principal syndrome, l’impossibilité de démarrer de nouvelles machines virtuelles sur les serveurs affectés. Dans le monde physique, cela équivaut à une multitude de serveurs refusant obstinément de démarrer. Rien de bien grave, juste un problème catastrophique à l’échelle d’un datacenter (seule consolation, les VM déja démarrées continuent à fonctionner normalement, tant qu’on ne tente pas de les redémarrer…)
Si l’on ne peut que constater les dégâts, force est de reconnaître que VMware a réagi avec rapidité et sérieux. L’éditeur a officiellement reconnu sa bourde hier soir et a émis un premier message urgent à destination de ses clients vers 23h30. L’éditeur y expliquait le problème et promettait un remède rapide. Ce matin vers 7h20, les premiers correctifs express sont arrivés. Tous requièrent l’arrêt des machines virtuelles ou leur déplacement vers un autre serveur via VMotion pour l’application des correctifs, en attendant l’arrivée éventuel d’un correctif permettant la mise à jour dynamique d’ESX Server. Pas de quoi faire sourire des administrateurs systèmes sans doute déjà passablement stressés, mais une vraie solution qui supprime définitivement le problème.
Vers des stratégies de “double-sourcing”
Reste qu’une bourde d’une telle ampleur pourrait laisser des traces. Elle pourrait en effet faire réfléchir certains sur les nouvelles vulnérabilités qu’implique la virtualisation. Quels que soient les mécanismes de redondance mis en place par les utilisateurs, rien ne peut en effet les protéger contre une bévue critique dans le code de l’hyperviseur. Qu’une telle bévue se produise et c’est l’ensemble de leur capacité de production qui disparaît, en attendant un patch.
Aucun éditeur n’étant à l’abri d’une mésaventure identique , qu’il s’agisse de Microsoft, Sun, Oracle ou Citrix, il est sans doute temps, côté clients, de réfléchir sérieusement à une stratégie de double sourcing. Vmware y laissera sans doute quelques plumes en terme de parts de marché, mais c’est sans doute avec cette forme de banalisation (après tout il est courant pour les entreprises d’avoir deux fournisseurs pour leurs équipements) que l’usage de la virtualisation pourra véritablement se généraliser.
N.B. : La bourde de VMware appelle une dernière remarque sur la beauté des codes d’activations et d’inactivation, des restrictions de licence et autres mécanismes de DRM logiciel. Quand un éditeur les met en place, cela semble toujours une bonne idée, un moyen de contrôler plus efficacement l’utilisation de ses produits, de mieux gérer les licences ou de lutter contre le piratage… Le problème est qu’un jour ce genre de chien de garde finit toujours par se retourner contre son maître. Toute à son obsession du piratage, l’industrie du logiciel commercial a multiplié ce genre de mécanismes, mettant en doute explicitement l’honnêteté de ses clients. Vmware en fait aujourd’hui les frais comme Microsoft le fit il y a quelque années avec les mécanismes d’activation de Windows. De quoi inciter ces géants à la réflexion. Car un des avantages de l’open-source est qu’il ne s’embarrasse pas de ce genre de limitations…
Références externes
- reference #1
http://www.vmware.com/landing_pages/esxexpresspatches.html
