Une migration à chaud déplace une VM allumée d’un hôte AHV à un autre sans interrompre sa charge. Ses étapes expliquent pourquoi elle échoue parfois, et pourquoi certaines VM ne peuvent pas bouger du tout.
Les étapes
La Nutanix Bible la voit déclenchée par la maintenance, l’équilibrage d’ADS (Acropolis Dynamic Scheduler), l’ajout de nœuds ou l’administrateur, et décrit cette séquence :
- créer une VM d’accueil sur l’hôte de destination ;
- copier la mémoire par itérations, 50 au plus « at the time of writing » ;
- mettre la VM en pause sur la source ;
- copier l’état final ;
- mettre à jour les commutateurs réseau ;
- reprendre la VM sur la destination ;
- supprimer la VM en pause côté source.
La pause n’intervient que si AHV peut transférer la mémoire restante en 300 ms au plus : c’est la fenêtre de gel maximale. Sinon, après la dernière itération, la migration peut s’arrêter sur « failure to converge » ; ADS, l’évacuation d’hôte ou l’administrateur peuvent la relancer. Le taux de modification de la mémoire compte plus que sa taille, et AHV peut ralentir la VM pour réduire ce qu’il faut renvoyer.
À la reprise, AHV diffuse un paquet RARP sur le sous-réseau : les commutateurs externes apprennent où tourne désormais la VM.
Le réseau et la commande
Selon Nutanix Pedia (non daté) et un membre du forum Nutanix (mai 2026), le trafic de migration passe par défaut par l’interface de gestion br0 ; d’après ce même membre, une segmentation backplane le déplace sur l’interface dédiée. Dans le même fil, un autre membre rappelle qu’une segmentation sur les mêmes cartes physiques n’isole pas ce trafic physiquement. La bande passante se limite par migration avec bandwidth_mbps. Syntaxe relevée en 2015 par magander.se et reprise par Nutanix Pedia, à vérifier sur votre version :
acli vm.get <VM> | grep allow_live_migrate
acli vm.migrate <VM> host=<ip_hote> live=yes bandwidth_mbps=100La sortie de acli vm.get contient un champ allow_live_migrate, à True dans l’exemple publié par Julien Dumur en 2025, près de hardware_virtualization et cpu_passthrough : premier endroit à regarder quand une VM refuse de bouger.
Ce qui la bloque
- Une configuration GPU en passthrough. Un employé Nutanix l’écrit en 2022 : « Live migration of VMs with a GPU configuration is not supported. » Lors des mises à jour du BIOS, du BMC ou de l’hyperviseur, ces VM sont éteintes puis rallumées au retour du nœud.
- L’affinité VM-hôte, qui interdit de sortir des hôtes de la règle : voir ce billet.
- Une VM éteinte, qui n’est liée à aucun hôte : ADS choisit son nœud au démarrage (forum Nutanix, 2024).
Les générations de processeur
Comme l’EVC de VMware, AHV détermine la génération de processeur la plus ancienne du cluster et y contraint tous les domaines QEMU. La Bible décrit aussi l’Advanced Processor Compatibility (APC), qui affranchit les clusters du plus petit dénominateur commun tout en présentant par défaut un processeur homogène ; un modèle de référence peut être fixé par VM pour migrer à chaud entre clusters de générations différentes. Entre clusters, elle recommande 5 ms de latence et en supporte 40 au plus.
Selon un retour du forum en 2021, il fallait éteindre les VM après l’ajout d’un nœud plus ancien (un redémarrage ne suffisait pas), et Prism avertissait d’une migration vers les anciens nœuds ; vérifiez sur votre version, l’APC ayant changé la donne. Prérequis d’ajout : ce billet.
Ce qu’il faut retenir
- La VM n’est gelée que si le reste de sa mémoire passe en 300 ms ; sinon, « failure to converge ».
- Le rythme d’écriture en mémoire pèse plus que la taille de la VM.
- GPU en passthrough, VM éteinte : pas de migration à chaud ; affinité VM-hôte : pas de migration hors des hôtes de la règle.
- Selon un retour du forum en 2021, il fallait éteindre les VM après l’ajout d’un nœud plus ancien (un redémarrage ne suffisait pas) ; vérifiez sur votre version, l’APC ayant changé la donne.
acli vm.getetallow_live_migrated’abord,acli vm.migrateensuite.
In English
Iterative memory copy, a freeze of 300 ms at most, RARP: the steps of a live migration on AHV, what makes it fail or prevents it, and the role of CPU generations. The memory change rate matters more than its size, a VM with GPU passthrough does not live-migrate, and AHV aligns VMs on the oldest CPU generation in the cluster.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible, Nutanix Community) et blogs techniques, relevé 2026-10
- Nutanix Bible, AHV Architecture (Live Migration, CPU compatibility) nutanixbible.com
- Nutanix Community, GPU Pass-Through for Guest VMs (2022) next.nutanix.com
- Nutanix Community, Living Migration Between Old and New Processors (2021) next.nutanix.com
- Nutanix Community, Need to migrate VMs on AHV (intra cluster) (2024) next.nutanix.com
- Nutanix Community, Does live migration traffic use the VM's network when Backplane LAN is not configured? (2026) next.nutanix.com
- magander.se, Nutanix Acropolis VM Live Migration (2015) magander.se
- Nutanix Pedia, Configuring HA & Live Migration in Acropolis (non daté) nutanixpedia.blogspot.com
- Julien Dumur, Maxi Best of Nutanix CLI, checking VMs (2025) juliendumur.fr