Migration · VMware
Migrer des machines virtuelles VMware vers Apache CloudStack
Apache CloudStack peut importer des machines virtuelles depuis VMware vCenter et, à partir de la version 4.19, les convertir vers KVM. Pour le faire en toute sécurité, il faut néanmoins un inventaire, une zone cible, un essai préalable et un plan de bascule par machine. Pendant les 30 jours ouvrés de NexCMP Source, un ingénieur expert réalise ce travail avec vous, sans frais supplémentaires.
Inclus avec NexCMP Source ($499 paiement unique), non inclus avec NexCMP Free. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor et Apache CloudStack sont des marques déposées de leurs propriétaires respectifs. NexCMP est indépendant et n'est ni affilié à ces derniers, ni approuvé par eux.
Le problème: quitter VMware sans perdre le contrôle
Migrer vers Apache CloudStack implique un changement de plateforme pour chaque machine virtuelle: disques, cartes réseau, pilotes et souvent adresses IP. Menée dans la précipitation, cette transition risque d'entraîner des échecs de démarrage, des pertes d'accès pour les clients ou des problèmes de licences.
CloudStack fournit les outils d'importation, mais ne décide pas pour vous de l'ordre de migration des machines, du mappage de chaque réseau, du traitement des invités Windows ni de la durée d'interruption de chaque machine. Ce sont ces décisions et les tests associés qui constituent la migration.
Si vous commercialisez ces machines virtuelles auprès de vos clients, la migration comporte un second volet: les machines doivent être rattachées aux bons clients, aux bonnes offres et aux bons tarifs dans votre système de facturation. NexCMP constitue cette couche de facturation et de portail client au-dessus de CloudStack, et le même ingénieur prend en charge les deux volets.
Ce que CloudStack prend nativement en charge
Deux méthodes sont documentées pour migrer depuis VMware. Le choix dépend du maintien ou non de vos hôtes VMware dans votre cloud.
A. Convertir vers KVM avec virt-v2v
- Ce que documente CloudStack
- À partir de la version 4.19, un administrateur peut sélectionner une VM VMware dans un datacenter vCenter existant ou externe et l'importer dans un cluster KVM, sous Tools, Import-Export Instances. La VM est exportée, convertie avec virt-v2v et ses disques sont importés au format QCOW2. La documentation la plus récente ajoute un flux basé sur VDDK en complément du flux OVF; la version 4.22 a introduit la conversion directe vers un pool de stockage et la version 4.22.1 la sélection automatique de l'OS invité selon l'OS source.
- Limites indiquées dans la documentation
- virt-v2v n'est pas installé par l'agent CloudStack et doit être déployé sur chaque hôte KVM, sous peine d'échec de la conversion. Le succès n'est pas garanti et dépend de l'OS invité et des systèmes de fichiers; la documentation recommande donc de tester avant toute mise en production. La VM importée reçoit par défaut le type d'OS invité CentOS 4.5 (32-bit) en version 4.19 et doit être modifiée ultérieurement.
Source: Apache CloudStack — Importation de VM VMware vers KVM · consulté le 2026-10-19
B. Importer sur place (unmanaged instances)
- Ce que documente CloudStack
- Pour les clusters vSphere dont les hôtes font déjà partie de CloudStack, listUnmanagedInstances liste les VM et importUnmanagedInstance permet de les intégrer à la gestion de CloudStack. Le listage des instances VMware non gérées a été introduit en version 4.14, la dissociation (unmanaging) en 4.15 et l'importation via l'interface en 4.16.
- Limites indiquées dans la documentation
- Le réseau cible doit déjà exister dans CloudStack et le stockage doit être ajouté en tant que primary storage. Les disques de données doivent être mappés à des offres de disque (disk offerings), et la coexistence de types de contrôleurs de disque ou de types de cartes réseau différents génère une erreur. Une VM en cours d'exécution ne peut être importée que si le VLAN réseau et l'offre de calcul (compute offering) correspondent; dans le cas contraire, elle doit d'abord être arrêtée.
Source: Apache CloudStack — À propos de l'importation et de l'exportation d'Instances · consulté le 2026-10-19
La méthode A s'applique lorsque la destination est KVM. La documentation de NexCMP désignant KVM comme l'hyperviseur testé, nous prévoyons la méthode A à moins que votre architecture ne maintienne des hôtes VMware sous CloudStack. Vérifiez la version de CloudStack que vous utilisez: les pages ci-dessus décrivent des comportements différents entre la version 4.19 et la version la plus récente.
Ce qui migre et les points d'attention
Disques
- Ce qui se passe
- Convertis en QCOW2 et importés dans le pool de stockage principal de destination (méthode A), ou mappés aux offres de disque de CloudStack (méthode B).
- Attention
- Avec la méthode B, un disque n'est pas redimensionné si son offre de disque associée est plus grande. L'espace de stockage temporaire pendant une conversion selon la méthode A correspond par défaut au stockage secondaire; le stockage principal ne peut être utilisé à cette fin que s'il est en NFS.
Source: Apache CloudStack — Importation de VM VMware vers KVM · consulté le 2026-10-19
Réseaux
- Ce qui se passe
- Les réseaux doivent exister dans CloudStack avant l'importation. Un script de découverte liste les réseaux vCenter auxquels au moins une VM est rattachée, afin de pouvoir créer les réseaux correspondants.
- Attention
- virt-v2v ne peut pas reconfigurer les paramètres réseau d'un invité ni modifier son adresse MAC. Si le sous-réseau cible est différent, l'invité nécessitera des ajustements après la conversion.
Source: libguestfs — manuel virt-v2v · consulté le 2026-10-19
Invités Linux
- Ce qui se passe
- Une VM Linux en cours d'exécution peut être importée via la méthode A: CloudStack la clone avant l'exportation, ce qui permet de la convertir dans un état crash-consistent.
- Attention
- La documentation de CloudStack recommande d'éteindre d'abord les VM Linux. virt-v2v n'installe pas de nouveaux noyaux ni de pilotes, et signale si la prise en charge de virtio est manquante ; l'invité doit donc respecter les versions minimales requises avant la conversion.
Source: libguestfs — manuel virt-v2v · consulté le 2026-10-19
Invités Windows
- Ce qui se passe
- Doivent être arrêtés proprement avant l'importation par la voie A. Les pilotes virtio proviennent du paquet virtio-win et sont installés au premier démarrage ; Windows peut redémarrer quatre fois ou plus après ce premier démarrage.
- Attention
- Le démarrage rapide ou la mise en veille prolongée empêchent la conversion, et un disque système configuré en disque dynamique n'est pas pris en charge. L'importation de Windows nécessite la présence des pilotes virtio sur l'hôte de conversion.
Source: libguestfs — manuel virt-v2v · consulté le 2026-10-19
VMware Tools
- Ce qui se passe
- virt-v2v tente de désinstaller VMware Tools.
- Attention
- Le manuel indique que la désinstallation n'est pas fiable sous Windows, où VMware Tools doit parfois être retiré par une autre méthode.
Source: libguestfs — manuel virt-v2v · consulté le 2026-10-19
Type d'OS invité
- Ce qui se passe
- La VM importée reçoit un type d'OS invité par défaut.
- Attention
- En 4.19, il s'agit de CentOS 4.5 (32-bit) et il doit être modifié manuellement ; la version 4.22.1 peut le faire correspondre à partir de l'OS invité source si les mappages existent.
Source: Apache CloudStack — Importation de VM VMware vers KVM · consulté le 2026-10-19
Facturation et clients
- Ce qui se passe
- Les offres, tarifs et comptes clients sont configurés dans NexCMP, et chaque machine migrée est rattachée au bon client.
- Attention
- Défini en semaine 1 selon votre version de CloudStack. Il s'agit d'une prestation NexCMP, pas d'une fonctionnalité de CloudStack.
Le plan, semaine par semaine
Modèle type, adapté à votre cas. Les 30 working days de travail continu correspondent à environ six semaines calendaires.
Semaine 1 — Inventaire et décisions
Avec un accès en lecture seule à vCenter, nous inventorions chaque VM : OS invité, disques, interfaces réseau, VLAN, Snapshots, état d'alimentation et dépendances. Nous choisissons la voie A ou B, définissons les vagues et identifions les machines nécessitant une attention particulière, comme les invités Windows, les volumes importants et tout élément soumis à une licence fixe.
Semaine 2 — Préparation de la cible
La zone CloudStack est vérifiée ou déployée : hôtes KVM, stockage, réseaux alignés sur ceux de VMware. Nous installons virt-v2v sur les hôtes KVM (et nbdkit sur les hôtes Ubuntu), préparons les pilotes virtio pour Windows et ouvrons les flux réseau entre les hôtes de conversion, vCenter et ESXi. Si vous revendez les machines, NexCMP est installé et connecté à CloudStack au cours de la même semaine.
Semaine 3 — Pilote
Quelques machines non critiques, représentatives de chaque type d'invité présent dans votre infrastructure, suivent la procédure complète. Nous validons le démarrage, la connectivité réseau et les pilotes, configurons le type d'OS invité et mesurons la durée d'indisponibilité. Les résultats obtenus permettent de fixer les créneaux pour les vagues suivantes.
Semaines 4 et 5 — Vagues de migration
Les machines sont migrées par groupes selon les créneaux convenus. Chaque groupe est validé avant de lancer le suivant, et les machines VMware d'origine restent éteintes mais conservées pour permettre un retour arrière. Si vous revendez les machines, les clients, offres et tarifs sont configurés en parallèle dans NexCMP, avec un fonctionnement de facturation en double avant la bascule définitive.
Semaine 6 — Bascule finale et transfert
Les dernières machines sont migrées, la date de facturation est ajustée si vous les revendez, et les modifications DNS sont appliquées. Nous documentons l'ensemble des opérations réalisées, contrôlons le durcissement ainsi que les Backups, et restons disponibles pour la migration jusqu'à la fin des 30 working days.
Aperçu indicatif. Le plan définitif est arrêté en semaine 1, et le seul engagement ferme de l'offre porte sur les 30 working days.
Risques et mesures d'atténuation
Aucune migration n'est sans risque, et nous ne promettons pas une interruption nulle. Voici les difficultés possibles et les mesures appliquées.
Indisponibilité par machine
Les machines Windows ne peuvent pas être converties à chaud, et une machine Linux en fonctionnement est convertie dans un état crash-consistent. CloudStack ne fournit pas d'estimation de temps pour la conversion. Nous la mesurons lors du pilote, puis fixons une fenêtre d'arrêt par groupe de machines.
Échec d'une conversion
CloudStack précise que le succès n'est pas garanti et dépend du système invité. Nous validons chaque typologie d'invité lors du pilote avant chaque vague, et la machine d'origine reste intacte tant que la nouvelle machine n'a pas été contrôlée.
Pilotes et VMware Tools
Les machines Windows reçoivent les pilotes virtio pendant la conversion, les machines Linux doivent intégrer la prise en charge de virtio au préalable, et VMware Tools peut exiger une suppression manuelle. Ces éléments sont vérifiés pour chaque invité lors du pilote.
Adresses IP, adresses MAC et DNS
Les invités conservent leurs adresses MAC ainsi que leur propre configuration réseau ; un sous-réseau de destination différent nécessite donc des modifications au niveau du système invité. Nous recensons chaque adresse en semaine 1, réduisons les TTL DNS avant la bascule et prévenons vos clients à l'avance.
Licences logicielles des invités
Windows et les logiciels commerciaux au sein d'une machine peuvent être soumis à une licence liée à l'ancienne plateforme. Nous les répertorions dans l'inventaire afin que vous puissiez confirmer les conditions auprès de chaque éditeur avant la migration.
Conversions interrompues
CloudStack indique que le redémarrage des serveurs de gestion pendant une migration l'interrompt et oblige à relancer l'importation. Nous planifions les vagues en dehors des créneaux de maintenance et évitons tout redémarrage lorsqu'une vague est en cours.
Bascule de la facturation et retour arrière
Si vous commercialisez les machines, la date de bascule de la facturation est choisie avec vous et les deux systèmes fonctionnent d'abord en parallèle. Les originaux VMware sont conservés jusqu'à ce que vous confirmiez que la migration est terminée, ce qui garantit une solution de repli pour chaque groupe.
Qui fait quoi
Un accès en lecture seule à vCenter et la liste des machines que vous considérez comme critiques
- L'expert prend en charge
- Inventorie chaque VM et planifie les vagues
L'accès à l'environnement CloudStack et aux hôtes KVM, ou le matériel pour les déployer
- L'expert prend en charge
- Prépare la zone, les réseaux et les hôtes de conversion
Les paquets VDDK et virtio requis par la méthode choisie, lorsque les éditeurs exigent que vous les téléchargiez vous-même
- L'expert prend en charge
- Les installe et les teste sur les hôtes de conversion
Les fenêtres d'arrêt convenues et les notifications à vos clients
- L'expert prend en charge
- Exécute le pilote et les vagues, puis vérifie chaque machine par la suite
Vos décisions tarifaires, si vous commercialisez les machines
- L'expert prend en charge
- Configure les offres, les clients et la facturation dans NexCMP, et assure la période de fonctionnement en parallèle
Ce que vous obtenez durant les 30 jours ouvrés
La migration est incluse dans la mise à niveau NexCMP Source : un paiement unique de $499 comprenant le code source complet (serveur Rust, portail et console d'administration Vue, agent de nœud Go, CLI, scripts de build), le droit de modifier et de compiler votre propre version sans limite, 12 mois de nouvelles versions du code source, toutes les applications et 30 jours ouvrés d'accompagnement continu avec un ingénieur expert.
Au cours de ces 30 jours ouvrés, l'expert assure votre migration de VMware vers Apache CloudStack sans frais supplémentaires. Ce temps peut également, ou à la place, servir à migrer depuis WHMCS ou un autre système, ou à effectuer une configuration complète de A à Z et compiler vos applications. Le décompte commence dès le début des travaux avec l'expert et s'affiche sur votre page de licence. L'assistance pour la migration s'étend sur ces mêmes 30 jours.
NexCMP Free n'inclut pas cette prestation. L'édition Free est gratuite pendant un an avec tous les modules et sans support technique (uniquement la correction des bugs du code source), puis se renouvelle à $99 par an.
VMware vers CloudStack — questions fréquentes
Combien cela coûte-t-il ?
Est-ce inclus dans NexCMP Free ?
Quelles versions de CloudStack et de VMware sont prises en charge ?
Mes machines virtuelles subiront-elles une interruption de service ?
Toutes les VM peuvent-elles être converties ?
Dois-je conserver VMware par la suite ?
Que dois-je fournir?
Sources et notes
Les déclarations techniques proviennent de la documentation officielle d'Apache CloudStack et du manuel de virt-v2v. La documentation évoluant d'une version à l'autre, vérifiez la version que vous utilisez. La mention de la version 4.19 provient de la documentation 4.19, qui introduit la page VMware-to-KVM par 'As of CS 4.19'. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor et Apache CloudStack sont des marques déposées de leurs propriétaires respectifs. NexCMP est indépendant et n'est ni affilié ni approuvé par ces derniers.
Quittez VMware accompagné d'un ingénieur
Passez à NexCMP Source pour $499 et démarrez vos 30 jours ouvrés, ou contactez d'abord [email protected] au sujet de votre environnement.
Dernière mise à jour :