JH.
vergeIO

VergeOS 26.2 et la sortie de VMware : ce qui bloque n’est pas la migration

La plupart des sorties de VMware s'arretent avant la fin. Non pas parce que la migration echoue, mais parce qu'il reste une poignee de charges de travail qui refusent de partir : les clusters Windows avec leur disque partage, et les petits sites distants. C'est la que se joue le renouvellement.

Julien HOKINI · · 9 min read
VergeOS 26.2 et la sortie de VMware : ce qui bloque n’est pas la migration

Une migration réussie ne se mesure pas au pourcentage de machines déplacées. Elle se mesure le jour où vous éteignez le dernier hôte de l'hyperviseur que vous vouliez quitter. Entre les deux, il reste une poignée de charges de travail qui refusent de partir, et depuis peu une dépendance que personne ne met sur la table : la bibliothèque de VMware qui sert à lire les disques que vous voulez emporter.

Quand j'ouvre un projet de sortie d'hyperviseur, je commence par la liste de ce qui ne bougera pas, pas par la cible. Dans à peu près tous les dossiers que j'ai vus passer, les machines qui migrent vite ne décident de rien. Les dernières décident si le renouvellement saute ou pas.

VergeIO a bâti sa communication sur VergeOS 26.2, annoncé le 13 octobre 2026, autour de ce constat : la plupart des sorties de VMware s'arrêtent avant la fin. La formulation de l'éditeur est juste. Le slogan m'intéresse moins que ce qu'il a mis dans la version pour aller chercher ces derniers workloads, et que ce que cela laisse dans l'angle mort.

Ce qui bloque réellement une sortie de VMware

Un projet type se déroule toujours de la même façon. Les serveurs de test, les applications internes, les serveurs web et les serveurs de fichiers partent vite, et on croit avoir fini à 90 %.

Puis on tombe sur trois choses, toujours les mêmes :

  • les clusters Windows qui ont besoin d'un disque partagé avec des réservations SCSI-3 ;
  • la baie de stockage qu'on garde allumée uniquement pour fournir ce disque partagé ;
  • les petits sites distants, qui tournent sur un seul serveur et qu'on n'a pas envie de toucher.

Le résultat, je l'ai vu plusieurs fois : deux hyperviseurs en production, deux consoles, deux compétences à maintenir, et un renouvellement VMware payé pour cinq ou dix charges de travail. Sur le plan technique, le projet est un succès. Sur le plan économique, il a échoué.

Les réservations SCSI-3, là où les projets se cassent

Un cluster de basculement Windows (WSFC) ne fonctionne pas comme une machine virtuelle ordinaire. Pour arbitrer qui écrit quoi sur le disque partagé, il s'appuie sur un mécanisme du monde SCSI : les réservations persistantes SCSI-3 (SCSI-3 PR). Elles ne sont pas optionnelles, elles forment le socle du quorum et de la protection contre le fractionnement du cluster. Microsoft documente précisément le jeu de commandes attendu côté stockage.

Sur vSphere, ça fonctionne parce que l'hyperviseur transmet les commandes de réservation au stockage sous-jacent. La base de connaissances Broadcom l'écrit : vSphere prend en charge WSFC avec disque partagé en relayant de façon transparente les réservations SCSI-3 vers le stockage. C'est donc la baie qui arbitre, pas l'hyperviseur.

De là découle le blocage que tout le monde connaît : un stockage hyperconvergé qui agrège des disques locaux dans un système de fichiers distribué n'a, historiquement, aucune raison de savoir répondre à ces commandes. Ni Ceph, ni NFS, ni LVM ne savent servir de disque partagé à un cluster Windows, et c'est l'un des sujets les plus récurrents sur les forums communautaires Proxmox, par exemple. Résultat : la baie reste, et avec elle une bonne raison de garder aussi la plateforme d'à côté.

Ce que VergeOS 26.2 apporte

VergeOS est un système d'exploitation d'infrastructure : hyperviseur, stockage, réseau, sauvegarde et PRA dans un seul OS posé sur des serveurs x86 standard. Le stockage interne s'appelle VergeFS. La version 26.2 ajoute trois choses.

D'abord, des migrations plus rapides. L'éditeur annonce 120 % plus rapide, soit 2,2 fois la vitesse de transfert, sur le transfert initial complet comme sur le transfert final, grâce à l'ajout d'E/S asynchrones aux transferts NBD. Le suivi des blocs modifiés (changed block tracking), déjà présent, servait à raccourcir la bascule, et ce gain la réduit encore.

Ensuite, le clustering Windows dans VergeFS. Un disque peut être marqué comme partagé et attaché simultanément à plusieurs machines virtuelles. La note de version précise que ces disques exposent une identité NAA/WWN correcte et prennent en charge les réservations persistantes SCSI-3. Cela permet de faire tourner un cluster de basculement Windows, donc SQL Server en cluster, sans baie dédiée derrière.

Enfin, les sites distants à un seul serveur. Un site peut désormais tourner sur une machine, deux liens réseau et sans réseau cœur, les deux ports servant à la fois au trafic externe et aux charges de travail.

Deux détails de la version parlent aux gens qui exploitent. Chaque VM remonte son propre numéro de série SMBIOS, utile pour distinguer les machines dans un outil d'inventaire. Le chemin de restauration compatible oVirt conserve l'UUID d'origine de la VM, ce qui évite de casser les jobs de sauvegarde existants. La version ajoute aussi un délai d'inactivité configurable sur les sessions shell et SSH, positionné pour répondre à des exigences CIS, DISA STIG et NIST 800-53. Ce réglage aide à satisfaire un contrôle, ce qui ne revient pas à démontrer une conformité.

Une ligne de la note de version demande une relecture. Elle indique que les E/S ne sont plus sérialisées ni verrouillées en exclusif sur un disque partagé, et que la coordination des écritures est laissée au cluster invité. VergeOS fournit donc la plomberie du stockage partagé et les primitives de réservation, mais l'arbitrage reste dans les machines virtuelles, comme sur n'importe quelle plateforme. Ce n'est pas anormal, c'est le modèle du disque partagé. Mais ce point ne se tranche pas sur une fiche technique : il se teste.

La dépendance dont personne ne parle : le SDK de VMware

Je ne l'ai trouvée ni dans la communication de l'éditeur, ni dans la presse spécialisée. Pour sortir une machine virtuelle de vSphere, il faut lire ses disques, et la façon sanctionnée de les lire passe par le kit de développement de VMware lui-même.

La chaîne technique est simple :

  • le suivi des blocs modifiés passe par l'API vSphere, plus précisément la méthode QueryChangedDiskAreas des API de protection des données de vSphere (ex-VADP) ;
  • le transfert des blocs passe par le VDDK (Virtual Disk Development Kit), la bibliothèque cliente qui donne accès aux fichiers .vmdk, avec NBD comme l'un de ses modes de transport.

La ligne « E/S asynchrones sur les transferts NBD » que VergeIO met en avant se situe exactement sur ce chemin.

Il existe une dissymétrie contre-intuitive :

ComposantCôtéStatut de licence
API de protection des données (VADP)ServeurIncluses avec toutes les éditions vSphere sous licence (KB Broadcom 311197)
VDDKClient« Pas un droit client », selon Broadcom

Vous avez la serrure. Vous n'avez pas la clé.

Vers le 25 août 2026, Broadcom a retiré les pages de téléchargement public du VDDK, sans annonce préalable. La société l'a confirmé à The Register le 10 septembre 2026 et à TechTarget la veille : la possibilité pour les organisations individuelles de télécharger le VDDK a récemment changé. L'accès passe désormais par le Technology Alliance Program, pour l'usage couvert par la licence : la sauvegarde et la restauration. Broadcom ne reconnaît pas l'usage « migration vers un hyperviseur concurrent ». Selon son porte-parole, le VDDK n'est pas un droit client, n'a jamais été inclus dans un achat de logiciel Broadcom, et le changement ne fait que renforcer des termes qui s'appliquaient déjà.

Microsoft Azure Migrate, le Migration Toolkit de Red Hat et Nutanix Move ont mis à jour leur documentation après le 25 août, et Platform9 a publié début septembre un billet sur les alternatives de son outil vJailbreak. Red Hat a indiqué ne pas disposer de substitut direct, le logiciel étant propriétaire, sous licence et non copiable. Pour la sauvegarde et la restauration, Broadcom renvoie les clients vers les solutions de ses partenaires approuvés : les outils de sortie sont touchés, pas les outils de sauvegarde.

VergeIO est-il concerné ? Sa documentation décrit le « VMware Connector » comme une connexion directe par API à vSphere, qui réalise des sauvegardes complètes puis incrémentales via le CBT de VMware. Elle ne nomme jamais le SDK utilisé. Et la nouveauté phare de la 26.2, des E/S asynchrones sur les transferts NBD, porte sur un transport qui, dans l'écosystème VMware, est celui du VDDK.

Je ne peux pas trancher à leur place. Soit le connecteur embarque son propre lecteur de disques, soit il dépend du VDDK. C'est la première question que je poserais à l'éditeur avant d'engager un projet, parce que la réponse change la nature du risque. Un chemin de migration qui repose sur un SDK dont l'accès se resserre pose un problème de contrat plus que de technique, et ce contrat est celui du fournisseur que vous êtes en train de quitter.

Le modèle de licence

Dans un arbitrage de sortie de VMware, le prix compte autant que la technique, et c'est souvent lui qui déclenche le projet.

VergeOS se licencie par serveur physique, indépendamment du nombre de sockets, de cœurs ou de la capacité. C'est structurellement l'inverse du modèle par abonnement au cœur vers lequel Broadcom a poussé sa base installée. L'éditeur revendique environ 45 % d'économies face à VMware. Son directeur marketing, George Crump, a avancé un chiffre bien plus élevé sur un cas client : Topgolf serait passé de six serveurs Dell VxRail par site à trois serveurs Dell standard, sur 110 sites, pour des économies annoncées proches de 96 %.

Ces chiffres viennent de l'éditeur. Ils ne sont pas vérifiables de l'extérieur, et un cas client n'est pas une grille tarifaire. Le principe de facturation, lui, est vérifiable, et il change la donne : avec un modèle par serveur, réutiliser le matériel existant devient un levier de coût direct au lieu d'un argument secondaire.

Ce que je vérifierais avant de croire l'annonce

Je n'ai pas testé VergeOS. Ce qui suit n'est pas un retour d'expérience : c'est la liste de ce que je mettrais dans une maquette avant de signer quoi que ce soit.

  1. La dépendance au SDK de VMware. Demander par écrit au fournisseur si son connecteur VMware embarque son propre lecteur de disques ou s'appuie sur le VDDK. La réponse décide de la pérennité du chemin de migration, et la question n'a rien de technique.
  2. Le comportement des réservations sous charge réelle. Il faut un test de bascule avec perte franche d'un nœud et un contrôle du fencing, pas seulement vérifier que le cluster démarre. C'est le seul moyen de savoir si l'arbitrage tient quand ça compte.
  3. La portée des verrous. La coordination étant laissée aux invités et les E/S n'étant plus verrouillées en exclusif côté stockage, il faut valider les cas dégradés : nœud qui gèle, latence, coupure réseau entre les deux ports.
  4. La sauvegarde. Le chemin oVirt qui conserve l'UUID est censé préserver les jobs existants. À confirmer avec l'outil réellement en place, parce que c'est typiquement ce qui casse en silence après une migration.
  5. Le calcul de licence sur cinq ans, renouvellement matériel compris, à périmètre égal et non au prix affiché d'une édition.
  6. Le chiffre de 2,2×. C'est une mesure de laboratoire, sur des transferts NBD, contre la version précédente du produit. Il sert à comparer deux versions de VergeOS entre elles, pas à prévoir une fenêtre de bascule sur votre parc, où le réseau et le stockage décident.
  7. Les sites distants. Un serveur et deux liens séduisent côté exploitation. Reste à regarder la sauvegarde, la bande passante et surtout le temps de restauration depuis le site central.

Ce que je retiens du mouvement

Le contenu technique de cette version est moins spectaculaire que son cadrage, et c'est plutôt bon signe. Plus que « nos migrations sont plus rapides », l'annonce dit que la migration rapide, tout le monde sait la faire depuis longtemps, et que cela ne suffit pas à finir un projet. Les deux autres nouveautés, le clustering Windows et le site distant à un serveur, s'attaquent aux raisons qui font garder une plateforme en vie. Le renouvellement se joue là.

Un autre signal est moins technique. VergeIO a fait entrer à son conseil d'administration l'ancien CTO de VMware, Kit Colbert (vingt ans chez VMware, dont quatre à la tête de l'ingénierie, parti après le rachat par Broadcom), dans la même période qu'un nouveau directeur général venu des ventes hyperconvergées. Cela compte au-delà de la gouvernance : la vague de migration est désormais animée par des gens qui connaissent la base installée de l'intérieur.

L'affaire du VDDK rappelle toutefois que le chemin de sortie appartient à celui dont on sort. Tant que la migration s'appuie sur ses API et ses bibliothèques, la date de fin de support n'est pas la seule échéance à surveiller : la politique commerciale de l'éditeur sur ses outils de transfert peut aussi changer du jour au lendemain, sans annonce, un 25 août.

La question de fond reste ouverte, et la fiche technique ne la tranchera pas : la plateforme qui vous sert aujourd'hui à faire tourner deux serveurs de fichiers vous servira-t-elle demain à faire tourner votre cluster SQL et votre PRA ? Ça ne se lit pas dans un communiqué, ça se teste avec vos charges, vos fenêtres de bascule et votre exploitation. Et si le projet n'est pas mesuré jusqu'à l'extinction du dernier hôte, il n'est pas terminé, il est suspendu.

Analyse de l'annonce, pas un test terrain : les chiffres de migration et d'économies proviennent de l'éditeur et sont signalés comme tels. Rédigé avec l'aide de l'IA pour la forme et la formulation de l'article.

Sources

vergeIO VMware stockage Windows Server