VMware → Proxmox : peut-on remplacer vMotion ?

Lorsqu'une entreprise envisage une sortie de VMware, la question de la migration à chaud revient presque immédiatement.

Pour une équipe VMware, la question n'est pas seulement de savoir si Proxmox VE possède une commande de migration à chaud.

La vraie question est plus opérationnelle : pourrons-nous toujours évacuer un hôte, intervenir sur le matériel ou appliquer une maintenance sans interrompre les applications ?

Dans de nombreux environnements, la réponse est oui. Proxmox VE sait déplacer une machine virtuelle en fonctionnement entre les nœuds d'un cluster. Mais cette capacité ne couvre pas automatiquement tous les scénarios associés à VMware vMotion, Storage vMotion, DRS ou Cross-vCenter vMotion.

L'équivalence dépend de ce qui doit réellement être déplacé : l'état d'exécution de la VM, ses disques, ses connexions réseau ou des ressources physiquement attachées à l'hôte.

En architecture, une fonctionnalité ne se compare jamais isolément. Elle se compare dans son contexte d'exploitation.

La réponse en bref

Cette équivalence fonctionnelle ne garantit pas à elle seule le même résultat en production. La compatibilité CPU, le réseau, le stockage et les procédures d'exploitation déterminent ce qui peut réellement être migré sans interruption perceptible.

Pourquoi vMotion est devenu essentiel à l'exploitation VMware

vMotion ne sert pas seulement à déplacer ponctuellement une VM d'un serveur vers un autre. Il fait partie du modèle d'exploitation de vSphere.

Une équipe l'utilise notamment pour :

• mettre un hôte ESXi en maintenance ;
• appliquer un correctif ou remplacer un composant matériel ;
• évacuer un serveur avant une intervention ;
• corriger manuellement un déséquilibre de charge ;
• exécuter les recommandations ou les décisions automatiques de VMware Distributed Resource Scheduler, ou DRS ;
• déplacer une VM vers un autre cluster ou un autre environnement lorsque l'architecture le permet.

La fonction contribue donc à la mobilité opérationnelle des workloads. Lors d'un VMware Exit, il faut comparer cette capacité globale, pas uniquement la présence d'une action Migrate dans l'interface cible.

Ce que VMware appelle vMotion

Le terme vMotion est souvent utilisé pour désigner plusieurs opérations différentes.

Migration du calcul avec stockage partagé

Dans son scénario classique, vMotion déplace l'exécution d'une VM entre deux hôtes ESXi qui accèdent aux mêmes fichiers sur un datastore partagé.

Les disques ne sont pas copiés. La mémoire, l'état du processeur virtuel et celui des périphériques sont transférés vers l'hôte cible. La VM continue ensuite à utiliser les mêmes disques depuis son nouveau serveur.

Storage vMotion

Storage vMotion déplace les fichiers et les disques d'une VM entre datastores. Le calcul peut rester sur le même hôte.

Ce mécanisme répond à des besoins différents : renouvellement d'une baie, rééquilibrage de capacité, changement de politique de stockage ou retrait d'un datastore.

Migration du calcul et du stockage

VMware permet également de modifier simultanément la ressource de calcul et le stockage. Ce scénario est souvent appelé shared-nothing vMotion.

Il devient nécessaire lorsque la destination n'accède pas au datastore de la source. La migration doit alors transporter l'état d'exécution et les données persistantes de la VM.

Entre clusters et instances vCenter

Une migration peut rester dans le même cluster, changer de cluster ou traverser des instances vCenter distinctes. Les prérequis augmentent avec le périmètre : compatibilité des versions, permissions, connectivité, stockage, réseau des VM, commutateurs virtuels et licences.

Parler de « remplacement de vMotion » sans préciser lequel de ces scénarios est étudié produit donc une comparaison incomplète.

Le vocabulaire de migration dans Proxmox VE

Pour une VM QEMU/KVM active, Proxmox VE parle d'online migration ou de live migration. Dans ce contexte, les deux expressions désignent le déplacement d'une VM en fonctionnement.

Une VM arrêtée fait l'objet d'une migration hors ligne. Cette opération ne doit pas être présentée comme une migration à chaud, même si son exécution est plus simple et accepte davantage de configurations.

Il faut aussi distinguer :

• la migration entre nœuds d'un même cluster Proxmox VE ;
• le déplacement de volumes entre stockages ;
• la migration d'une VM possédant des disques locaux ;
• la remote migration entre clusters indépendants ;
• le comportement des VM QEMU/KVM de celui des conteneurs LXC.

Le cas particulier des conteneurs LXC

Le guide Proxmox VE 9.2.4 indique qu'un conteneur LXC en fonctionnement ne bénéficie pas d'une migration réellement live. Proxmox propose une restart migration : le conteneur est arrêté, déplacé puis redémarré sur le nœud cible.

Cette interruption peut être courte, mais le mécanisme n'est pas l'équivalent exact de la migration à chaud d'une VM QEMU/KVM. La suite de cet article concerne principalement ces VM.

Comment fonctionne une migration à chaud

Une migration à chaud ne se résume pas à une copie de la mémoire vive.

Proxmox VE commence par préparer un processus QEMU sur le nœud cible. Les processeurs virtuels y restent en pause pendant que la source transmet l'état nécessaire.

La mémoire est copiée par itérations. Pendant ce transfert, la VM continue de fonctionner et modifie certaines pages mémoire. Ces pages sont marquées comme modifiées, puis renvoyées lors d'un passage suivant.

Lorsque le volume restant devient suffisamment faible, la VM source est brièvement suspendue. Les dernières pages et l'état des périphériques sont transmis, puis la VM reprend sur la destination.

Il existe donc une phase finale pendant laquelle l'exécution est interrompue. Sa durée ne peut pas être promise à l'avance : elle dépend notamment de la mémoire utilisée, du taux de modification des pages, du débit disponible et de la capacité du système à converger.

Cas 1 : la VM utilise un stockage partagé

Le stockage partagé constitue le scénario le plus proche du vMotion classique.

Les deux nœuds accèdent déjà aux disques de la VM. Pendant la migration, Proxmox VE transfère principalement la mémoire et l'état des périphériques. Les volumes restent sur le stockage existant.

Cette architecture peut utiliser :

• un cluster Ceph ;
• un partage NFS ;
• un stockage iSCSI ou Fibre Channel correctement présenté ;
• un autre backend que Proxmox VE identifie comme partagé et que les deux nœuds peuvent utiliser.

Le mot SAN ne constitue toutefois pas une garantie. Il faut vérifier que le stockage, les volumes et leurs identifiants sont accessibles de manière cohérente sur la source et la destination.

Les bridges ou réseaux utilisés par la VM doivent également exister sur le nœud cible. Une migration techniquement terminée n'est pas un succès si la VM reprend son exécution sur un réseau incorrect ou inaccessible.

Cas 2 : la VM possède des disques locaux

Proxmox VE peut migrer en ligne une VM compatible tout en envoyant ses disques locaux vers la destination.

Le changement est important : l'opération ne transporte plus seulement l'état d'exécution. Elle doit aussi copier les données persistantes vers un stockage disponible sur le nœud cible.

La durée dépend alors de plusieurs facteurs :

• taille réellement occupée par les volumes ;
• performances de lecture et d'écriture des stockages ;
• bande passante disponible ;
• limite de débit configurée pour les migrations ;
• activité d'écriture de la VM ;
• concurrence avec les sauvegardes, réplications ou reconstructions de stockage.

Une VM possédant plusieurs téraoctets de données ne présente donc pas le même profil qu'une petite VM installée sur un stockage partagé.

Compatibilité CPU : le prérequis souvent sous-estimé

Une VM en fonctionnement conserve l'état du processeur virtuel qui lui a été présenté au démarrage. Le nœud cible doit pouvoir reprendre cet état.

Le type CPU host expose étroitement les capacités du processeur physique. Il peut rendre davantage d'instructions disponibles, mais il réduit la mobilité lorsque les nœuds utilisent des modèles, des générations ou des microcodes différents.

Les modèles CPU génériques et les familles x86-64-v* créent un socle plus homogène. Le bon choix consiste généralement à exposer les fonctions dont l'application a besoin sans dépasser celles disponibles sur le nœud le moins capable du périmètre de migration.

Le guide Proxmox VE demande des processeurs du même constructeur et aux capacités similaires pour un scénario supporté. Une migration entre Intel et AMD peut fonctionner dans certaines configurations, mais elle n'est pas garantie et ne doit pas devenir une hypothèse de production sans tests.

VMware répond historiquement à cette problématique avec Enhanced vMotion Compatibility, ou EVC, qui masque certaines fonctions CPU afin de présenter un niveau commun aux hôtes. Proxmox VE adopte une approche différente, fondée sur le modèle CPU configuré pour les VM.

Le réseau de migration

Par défaut, Proxmox VE peut utiliser le réseau du cluster pour le trafic de migration. La documentation recommande de ne pas laisser un transfert volumineux perturber les communications sensibles du cluster.

Un réseau de migration dédié permet de séparer les flux et d'utiliser une interface mieux dimensionnée. Sa conception doit couvrir :

• le débit utile entre chaque paire de nœuds ;
• la latence et la stabilité ;
• la cohérence du MTU sur tout le chemin ;
• la concurrence entre plusieurs migrations ;
• le trafic de stockage lorsque des disques doivent être copiés ;
• la supervision des erreurs, retransmissions et saturations.

Proxmox VE propose un mode de migration sécurisé et un mode non chiffré. La mémoire d'une VM peut contenir des informations sensibles. Le mode non sécurisé ne doit donc être envisagé que sur un réseau privé, isolé et maîtrisé. Le contenu du stockage reste actuellement transféré par un canal sécurisé.

La même prudence existe côté VMware : les flux vMotion doivent utiliser une connectivité prévisible et protégée. Le dimensionnement exact ne se transpose pas automatiquement d'une plateforme à l'autre, car les architectures réseau et stockage peuvent changer pendant le VMware Exit.

Les configurations qui peuvent bloquer une migration

La migration à chaud suppose que la destination puisse reconstruire l'environnement de la VM.

Les limitations confirmées par le guide Proxmox VE actuel comprennent :

• un périphérique PCI passé directement à la VM ;
• un GPU affecté par PCI passthrough ;
• un périphérique USB passé directement ;
• une autre ressource physiquement liée au serveur source ;
• un stockage absent ou inaccessible sur la destination ;
• un bridge ou un réseau qui ne peut pas être reproduit ;
• un modèle CPU que le nœud cible ne peut pas fournir ;
• une destination utilisant des versions de paquets plus anciennes et incompatibles.

Une image ISO ou un volume local doit rester accessible ou être transféré. En revanche, la présence d'un snapshot ne sera pas qualifiée ici de blocage systématique : le comportement dépend du backend de stockage, du format et de l'opération demandée.

Lorsque la VM utilise un périphérique local non migrable, une migration hors ligne peut rester possible après adaptation de la configuration sur la destination. Cette solution implique une interruption planifiée.

Migration planifiée, HA et CRS ne jouent pas le même rôle

Pendant une maintenance planifiée, l'hôte source fonctionne encore. Il peut transmettre la mémoire et l'état de la VM à un autre nœud.

Lors d'une panne brutale, cet état a déjà été perdu. La haute disponibilité peut redémarrer la VM sur un autre serveur, mais elle ne peut pas migrer en direct la mémoire devenue inaccessible.

Dans Proxmox VE :

• une migration manuelle déplace une ressource encore active ;
• le mode maintenance peut demander l'évacuation des services HA d'un nœud ;
• la HA redémarre une ressource après une panne et un fencing correct ;
• le Cluster Resource Scheduler, ou CRS, choisit le placement et peut rééquilibrer certaines ressources HA ;
• CRS utilise la migration lorsqu'elle est possible, mais ne rend pas migrable une VM qui ne respecte pas les prérequis.

Le fonctionnement de CRS, ses règles et ses différences avec VMware DRS sont détaillés dans notre article Proxmox CRS : le nouveau DRS pour équilibrer automatiquement les clusters ?.

Migration entre clusters et Proxmox Datacenter Manager

À l'intérieur d'un cluster Proxmox VE, la migration entre nœuds reste le scénario natif le plus établi.

La remote migration permet aussi de déplacer une VM vers un cluster indépendant. Cette opération demande de faire correspondre les stockages et les bridges de la source avec ceux de la destination. Elle peut également changer l'identifiant de la VM.

Proxmox Datacenter Manager fournit un plan de contrôle centralisé pour les ressources de plusieurs clusters et expose les migrations entre remotes. Sa documentation actuelle mentionne la migration à chaud de VM entre clusters.

Cette capacité doit toutefois être présentée avec prudence. Dans le guide Proxmox VE 9.2.4, la commande sous-jacente qm remote-migrate reste qualifiée d'expérimentale. Les versions de PVE et de PDM, le mapping réseau, le stockage, la compatibilité CPU et le retour arrière doivent être validés ensemble.

Deux clusters reliés à Proxmox Datacenter Manager ne deviennent pas un cluster unique. Ils ne partagent ni le même quorum, ni le même domaine HA, ni un CRS commun.

Comparaison synthétique

Ce que VMware conserve comme avantages

VMware conserve une profondeur d'intégration construite sur de nombreuses années entre vCenter, vMotion, EVC, DRS, les Distributed Switches et les outils d'exploitation de l'écosystème.

Cette maturité se traduit notamment par :

• une présentation détaillée des recommandations DRS ;
• des automatismes et des niveaux de contrôle bien connus des équipes ;
• des scénarios Cross-vCenter documentés ;
• des procédures de maintenance souvent déjà industrialisées ;
• un écosystème d'intégrations qui sait observer et piloter les migrations.

Une entreprise qui utilise réellement ces fonctions doit chiffrer leur reconstruction dans l'architecture Proxmox. Les ignorer parce que la migration manuelle fonctionne serait une erreur de cadrage.

Ce que Proxmox VE apporte

La migration des VM fait partie des fonctions natives de Proxmox VE. Elle est administrée depuis la même interface que les clusters, le stockage et la HA, sans licence distincte dédiée à la migration.

Dans un cluster homogène, avec un stockage partagé et des réseaux cohérents, le fonctionnement est direct et lisible. La possibilité de transférer des disques locaux offre aussi une souplesse utile pour certaines architectures sans stockage centralisé.

Proxmox VE expose clairement les commandes, les journaux de tâches et les paramètres de migration. Cette transparence facilite le diagnostic, mais elle ne dispense pas de construire la supervision, les procédures et les garde-fous attendus en production.

Checklist avant de considérer vMotion comme remplacé

CPU

• Inventorier les constructeurs, modèles, générations et microcodes.
• Recenser les VM configurées avec un CPU de type host.
• Définir le plus petit modèle CPU commun acceptable.
• Tester les migrations dans les deux directions entre les nœuds autorisés.

Stockage

• Identifier les volumes partagés et locaux.
• Vérifier l'accessibilité réelle depuis chaque destination.
• Mesurer les performances pendant une copie de disque local.
• Contrôler les limites de bande passante et l'espace disponible.

Réseau

• Définir un réseau de migration adapté.
• Contrôler le débit, la latence, le MTU et la redondance.
• Vérifier les bridges et VLAN sur tous les nœuds.
• Observer l'impact sur Corosync, le stockage et les flux applicatifs.

Configuration des VM

• Recenser PCI, GPU et USB passthrough.
• Identifier les ISO, volumes ou ressources liés à un seul hôte.
• Mesurer la mémoire utilisée et son taux de modification.
• Documenter les dépendances applicatives et réseau.

Exploitation

• Définir les critères de succès applicatifs.
• Superviser les migrations et leurs erreurs.
• Tester le mode maintenance et la HA séparément.
• Documenter l'annulation et le retour vers le nœud d'origine.
• Prévoir la conduite à tenir lorsqu'une migration ne converge pas.

Une méthode de validation en POC

Le POC doit reproduire les cas difficiles, pas seulement déplacer une VM inactive.

Un protocole utile peut suivre cette progression :

1. migrer une VM arrêtée afin de valider les mappings de base ;
2. migrer une VM active et peu chargée sur stockage partagé ;
3. répéter l'opération avec une charge CPU soutenue ;
4. utiliser une VM consommant beaucoup de mémoire ;
5. générer un taux de modification mémoire important ;
6. mesurer une migration comprenant des écritures disque ;
7. migrer une VM possédant des disques locaux ;
8. tester plusieurs destinations et plusieurs générations CPU ;
9. provoquer une perte de connectivité sur un environnement isolé ;
10. observer l'interruption depuis l'application, pas seulement depuis l'hyperviseur ;
11. mesurer la durée, le trafic généré et la charge des stockages ;
12. exécuter le retour arrière prévu.

Les résultats doivent être conservés par profil de workload. Une moyenne globale masque les VM qui ne peuvent pas respecter la même fenêtre de maintenance que les autres.

Pour structurer cette validation, voir ce qu'un POC Proxmox doit réellement valider et notre page POC Proxmox.

Proxmox remplace-t-il vMotion ?

Oui, pour de nombreux scénarios courants de maintenance et de migration à chaud.

Une architecture Proxmox VE correctement conçue permet de migrer des VM en fonctionnement, d'évacuer un hôte pour maintenance et de déplacer des charges utilisant un stockage partagé ou, sous conditions, des disques locaux.

Mais cette réponse ne peut pas être généralisée à tous les usages VMware.

Les environnements fortement intégrés à vCenter, DRS, EVC, aux migrations Cross-vCenter ou à des périphériques physiques demandent une qualification plus détaillée. La maturité des procédures, la visibilité opérationnelle et les automatismes existants comptent autant que la capacité technique à déplacer une VM.

La bonne conclusion n'est donc pas « Proxmox possède vMotion ». Elle est plus précise : Proxmox VE couvre une grande partie des besoins associés à vMotion, à condition que l'architecture cible et les procédures d'exploitation aient été conçues pour conserver cette mobilité.

Une migration réussie ne dépend pas uniquement de la présence d'une fonction de Live Migration. Elle dépend surtout de l'architecture, des procédures d'exploitation et des validations réalisées avant la bascule.

VSHIFT accompagne cette validation dans le cadre d'un audit de l'existant et de l'architecture cible, d'un POC Proxmox ou d'une trajectoire VMware Exit. Les études de cas illustrent les autres points à qualifier avant une bascule.

Sources officielles

• Proxmox VE Administration Guide 9.2.4
• Proxmox Datacenter Manager 1.1.7 — Introduction
• Proxmox Datacenter Manager — Remotes
• Proxmox Datacenter Manager — Command Syntax
• Broadcom — vMotion avec stockage partagé ou shared-nothing
• Broadcom — VMware EVC et compatibilité CPU
• Broadcom — exigences réseau vMotion
• Broadcom — Cross-vCenter Migration