Quitter VMware ne se résume pas à recréer des VM à la main. Migration Manager est la brique de la stack FuturFusion qui planifie et exécute le transfert de machines virtuelles depuis VMware vers Incus, par lots, sans réinstaller les systèmes invités. Ce guide explique le rôle de l'outil, son architecture (appliance, sources, cibles, transfert de disques), et documente jusqu'où un lab sans ESXi permet d'aller : le déploiement et la connexion se valident, mais l'import complet exige un vCenter/ESXi 8.0 réel. Pour qui prépare une sortie de l'écosystème VMware.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Ce que fait Migration Manager et sa place dans FuturFusion.
- Son architecture : appliance, source, cible, transfert de disques.
- Le workflow de migration, étape par étape.
- Ce qu'un test sans ESXi valide, et où il s'arrête.
Prérequis
Section intitulée « Prérequis »- Un cluster Incus ou un serveur Incus cible, idéalement sous Incus OS.
- Une source VMware (vCenter ou ESXi 8.0) pour une migration réelle.
- Des notions sur la stack, via Operations Center.
Ce qu'est Migration Manager
Section intitulée « Ce qu'est Migration Manager »Migration Manager a été annoncé le 21 décembre 2025, avec Operations Center, sous licence Apache 2.0. C'est un outil de planification et de migration orienté VMware vers Incus. Il matérialise l'argument central de la stack FuturFusion : offrir un chemin de sortie de VMware entièrement open source, sans réécrire chaque VM à la main.
Comme les autres briques récentes du projet, il est jeune. Il faut le voir pour ce qu'il est : un outil de migration utilisable et prometteur, pas une plateforme éprouvée sur des milliers de VM. Le modèle qu'il manipule reste simple à comprendre, ce qui aide à cadrer un projet de sortie.
L'architecture : appliance, source, cible
Section intitulée « L'architecture : appliance, source, cible »Migration Manager se déploie comme une appliance dédiée, sur le même principe qu'Operations Center : une image Incus OS immuable qui expose une API et un CLI (migration-manager). L'appliance est le chef d'orchestre ; elle ne porte ni les VM sources, ni les VM cibles, elle pilote le transfert entre les deux.
Autour d'elle, le modèle repose sur quelques objets clés :
| Objet | Rôle |
|---|---|
| Source | Un endpoint vCenter/ESXi que l'appliance interroge pour lister et lire les VM. |
| Cible (target) | Le cluster Incus qui accueillera les VM migrées. |
| Réseau (network) | La correspondance entre réseaux VMware et réseaux Incus. |
| Lot (batch) | Un groupe de VM migré ensemble, avec sa fenêtre de bascule. |
Le transfert de disques est le point technique sensible. Migration Manager lit les disques VMDK de la source via le VDDK (Virtual Disk Development Kit de VMware) exposé par nbdkit, puis reconstruit un disque exploitable côté Incus. C'est ce mécanisme qui permet de récupérer les données réelles d'une VM, pas seulement sa définition.
Le workflow de migration
Section intitulée « Le workflow de migration »Le déroulé suit un ordre logique, du branchement de la source à la bascule finale :
- Déclarer la source VMware auprès de l'appliance. L'outil vérifie la connectivité et l'authentification.
- Inventorier : Migration Manager lit l'inventaire de la source et enregistre les propriétés de chaque VM (matériel, disques, réseau).
- Déclarer la cible Incus et la correspondance réseau.
- Constituer un lot de VM à migrer ensemble.
- Transférer les disques en tâche de fond, source encore allumée.
- Basculer (cutover) : arrêt de la VM source, transfert final incrémental, démarrage côté Incus.
La déclaration d'une source se fait en une commande, avec l'empreinte du certificat pour établir la confiance :
migration-manager source add vcenter-prod https://vcenter.exemple.lan \ --trusted-cert-fingerprint <sha256># identifiants vCenter demandés de façon interactive| Name | Type | Connectivity Status | Username || vcenter-prod | vmware | OK | administrator |Un statut OK confirme que l'appliance dialogue avec la source. L'inventaire se consulte ensuite avec migration-manager instance list, et les éventuels problèmes de lecture remontent dans migration-manager warning list.
Tester sans ESXi : ce que ça valide, ce qui manque
Section intitulée « Tester sans ESXi : ce que ça valide, ce qui manque »Monter un vCenter/ESXi 8.0 de test n'est pas toujours possible. On peut alors simuler la source avec vcsim, le simulateur vSphere du projet govmomi. Ce détour a des vertus réelles, et une limite nette qu'il faut connaître avant de s'y engager.
Ce qu'un test avec un simulateur valide :
- Le déploiement de l'appliance Migration Manager et l'accès à son API.
- La déclaration d'une source :
source addrenvoie bien un statut de connectivitéOK. - La découverte de l'inventaire : l'appliance voit les VM annoncées par la source.
- La compatibilité de version, à condition d'annoncer une source 8.0 (le simulateur code en dur une version plus ancienne ; il faut le recompiler).
Ce qu'un simulateur ne permet pas :
La leçon pratique est double. D'un côté, un simulateur suffit à valider l'installation, la connexion et le modèle de l'outil, ce qui lève déjà beaucoup d'incertitudes sur la mise en place. De l'autre, la migration réelle (import du profil matériel complet, transfert des blocs de disque) reste indissociable d'une source de production : c'est là que se joue la vraie répétition avant un projet de sortie de VMware.
À retenir
Section intitulée « À retenir »- Migration Manager migre des VM VMware vers Incus, par lots, sans réinstaller les invités.
- Annoncé fin 2025, Apache 2.0, brique de la stack FuturFusion.
- Il se déploie en appliance Incus OS et pilote le transfert entre une source et une cible.
- Le transfert de disques passe par le VDDK/nbdkit de VMware.
- Un simulateur (vcsim) valide l'installation, la connexion et la version, mais pas l'import complet ni le transfert.
- La migration réelle exige une source vCenter/ESXi 8.0 avec de vraies VM.