Aller au contenu
forma_infoWindows, virtualisation, Nutanix et IA : des tutos écrits, courts et sourcés
⌕
6 minutes

VM bloquée dans Nutanix Move : le plan B par réplication Protection Domain

Quand le datamover Move gèle toujours au même octet, la réplication Async d’un Protection Domain entre deux Prism Element fait passer la VM. Déroulé, et les pièges : MAC, network mapping, suppression du PD.

VM bloquée dans Nutanix Move : le plan B par réplication Protection Domain
LinkedInXBlueskyRedditE-mailCopier le lienPartager…

Une VM gèle dans le datamover Move, toujours au même endroit, invité sain : relancer ne sert à rien. Un Protection Domain Async entre les deux Prism Element l’a fait passer ; voici le déroulé et trois pièges.

Le symptôme

Campagne de migrations AHV vers AHV. Une VM gèle trois fois au même octet du même disque, vers 60 GiB copiés, avec un compteur « Data Read (0) ». Retry, pause et reprise, nouveau plan, remise à zéro de l’espace libre dans l’invité, seconde appliance Move : rien n’y fait.

Le Protection Domain (PD) emprunte un autre chemin. Selon la Nutanix Bible, Cerebro pilote la réplication et indique à Stargate quelles données répliquer et vers où. C’est ce chemin qui a fait passer la VM.

Le déroulé

  1. Abandonner le plan Move de la VM.
  2. Déclarer un remote site dans chaque sens : sur le PE source vers la cible, sur le PE cible vers la source. Convention suivie : toutes les IP des CVM du cluster distant, port 2020, plutôt que la VIP. Le lien est établi quand, à la relecture, les capacités se complètent seules (dont SUPPORT_KVM) et que l’identifiant du cluster distant apparaît.
  3. Créer un PD sur le PE source et n’y protéger que la VM. Protéger ne transfère rien tant qu’aucun snapshot n’est pris.
  4. Lancer un snapshot hors planification, répliqué vers le remote site cible, et suivre la réplication.
  5. Une fois la réplication terminée, éteindre la VM source, puis restaurer la VM sur le PE cible depuis le snapshot. Démarrer, contrôler IP et ping. Si la source a tourné longtemps après le snapshot, un second snapshot pris après extinction évite de perdre ses dernières écritures.
  6. Nettoyer côté Move : le plan abandonné à l’étape 1 ne libère pas forcément les données déjà copiées sur la cible ; vérifiez-les et purgez-les.
  7. Supprimer PD et snapshots des deux côtés. Les remote sites peuvent rester pour les lots suivants.

Pour automatiser, nutanix.dev cite les endpoints v2 correspondants (cités, non testés ici) :

PrismGateway/services/rest/v2.0/protection_domains/(pd)/oob_schedules
PrismGateway/services/rest/v2.0/protection_domains/(pd)/dr_snapshots
PrismGateway/services/rest/v2.0/protection_domains/(pd)/restore_entities

Piège 1 : la MAC change

Réglé avec RetainMacAddress (voir le billet sur l’API Move), Move conserve la MAC. La restauration depuis un snapshot de PD, non : nouvelle MAC observée. Un post de la communauté Nutanix va dans le même sens : une MAC statique survit à une migration de PD, pas à un clone ni à une récupération depuis snapshot.

Vérifiez réservations DHCP et filtrages par MAC. L’IP, elle, est conservée si le réseau L2 est étendu entre les deux clusters. Éteignez la source avant de démarrer la copie, sinon conflit d’IP.

Piège 2 : le network mapping

Sans network mapping sur le remote site, prévoyez de rattacher à la main la carte de la VM restaurée. Pour l’ajouter à un remote site existant, le PUT v2 sur remote_sites a répondu HTTP 500 quel que soit le corps.

Ce qui a fonctionné : GET v1 sur /PrismGateway/services/rest/v1/remote_sites/<nom>, retrait des champs en lecture seule (stats, status, replicationLinks…), ajout du mapping, puis PUT v1 sur /PrismGateway/services/rest/v1/remote_sites, sans nom dans l’URL, objet complet en corps.

"networkMapping": {
  "l2NetworkMappings": [
    {"srcHypervisorType": "kKvm", "srcNetworkName": "<reseau>",
     "destHypervisorType": "kKvm", "destNetworkName": "<reseau>"}
  ]
}

Sans les deux champs kKvm, réponse 500 com.nutanix.util.base.CommandException. À faire sur les deux remote sites.

Piège 3 : le PD qui refuse de disparaître

Au nettoyage, le DELETE du PD a répondu 422 : « has N third-party backup snapshot(s) ». Un job planifié externe y avait déposé des snapshots de type scoped, invisibles dans l’UI, ncli, les API REST v1 et v2 et les recovery points de Prism Central. Parmi les outils essayés, seul cerebro_cli, depuis une CVM du cluster, les liste (même syntaxe dans un fil de la communauté Nutanix) :

cerebro_cli query_protection_domain <PD> list_snapshot_handles="true;scoped"

Ce qu’il faut retenir

  • Gel Move reproductible au même octet : un PD Async PE vers PE a fait passer la VM.
  • Remote sites dans les deux sens, PD limité aux VM gelées, source éteinte avant la restauration.
  • La restauration depuis snapshot change la MAC, contrairement à Move.
  • Network mapping L2 sur un remote site existant : API v1, kKvm des deux côtés.
  • Un PD qui refuse la suppression peut cacher des snapshots tiers : listez-les avec cerebro_cli, nettoyez-les depuis l’outil qui les a créés.

In English

When the Move datamover keeps freezing at the same byte, Async replication of a Protection Domain between two Prism Element clusters gets the VM across. The procedure and its pitfalls: the restored VM gets a new MAC, the L2 network mapping only went through API v1, and third-party snapshots invisible in the UI, listed by cerebro_cli, can block PD deletion.

Sources & vérification

Testé sur : Clusters AHV, Protection Domain Async entre deux Prism Element, API Prism Element v1 et v2

Comment les billets sont vérifiés et corrigés

Partager ce billet

LinkedInXBlueskyRedditE-mailCopier le lienPartager…

À lire aussi