Proxmox « migration aborted » : causes fréquentes et procédure de réparation

Ce que signifie réellement « migration aborted » dans Proxmox

Dans Proxmox VE, les migrations prennent plusieurs formes :

• Migration en direct (QEMU transfère l’état mémoire pendant que la VM tourne). Nécessite généralement un stockage partagé ou des stratégies de réplication rendant le disque disponible sur la cible.
• Migration hors ligne (la VM est arrêtée ; la configuration et les disques sont déplacés). Plus lente, souvent plus simple, parfois le seul choix sensé.
• Migration de stockage (déplacer les disques entre backends de stockage, éventuellement sans déplacer le nœud de calcul).
• Approches assistées par réplication (réplication ZFS ou Ceph/RBD où la localité et les règles de cohérence des disques diffèrent).

« migration aborted » n’est pas une erreur unique. C’est un état d’échec de haut niveau pour un flux de travail en plusieurs étapes :

1. Contrôles du cluster (permissions, configuration, quorum, disponibilité du nœud cible).
2. Contrôles de connectivité (SSH et/ou réseau de migration).
3. Contrôles de stockage (le disque existe-t-il sur la cible ? est-il partagé ? assez d’espace ? ID de stockage correct ?).
4. Démarrage par QEMU du canal de migration (synchronisation pré-copie de la mémoire, suivi des pages modifiées).
5. Basculage final / nettoyage (la partie qui fait mal quand elle échoue).

Quand la migration est abandonnée, Proxmox a peut‑être déjà effectué du travail : créé une configuration transitoire sur la cible, réservé de l’espace, lancé un processus récepteur, ou partiellement copié des disques. Votre tâche est de déterminer dans quel état vous êtes maintenant, pas l’état que vous espériez.

Idée paraphrasée de James Hamilton (ingénierie de la fiabilité AWS) : « Opérez en minimisant la variabilité et apprenez de chaque échec. » Ce n’est pas poétique. C’est correct.

Petite blague #1 : La migration en direct, c’est comme déménager en gardant la cuisson en cours — possible, mais les chances de faire tomber la soupe ne sont pas nulles.

Playbook de diagnostic rapide (vérifiez ceci en premier)

Si vous n’avez que cinq minutes avant que quelqu’un commence à « aider », faites ceci dans l’ordre. Le but est d’identifier si le goulot d’étranglement est l’état du cluster, le réseau, le stockage ou les contraintes de la VM.

1) Confirmer l’état du cluster et la disponibilité du nœud cible

• Y a‑t‑il le quorum ? Corosync oscille‑t‑il ?
• Le nœud cible est‑il dans un état propre et non fencing ou partiellement déconnecté ?
• La VM est‑elle verrouillée ?

2) Récupérer le log de la tâche, puis les logs du nœud

• Le journal des tâches Proxmox donne la première ligne d’erreur significative.
• Les logs système vous disent la raison réelle (échec d’auth, refus de permission, reset réseau, OOM, disque plein).

3) Identifier la topologie de stockage et si elle correspond au type de migration

• Le stockage partagé (Ceph, NFS, iSCSI, etc.) facilite la migration de calcul.
• Le stockage local implique le déplacement/réplication des disques et des contraintes de bande passante.
• Les datasets ZFS, LVM thin et qcow2 se comportent différemment pendant la copie et la gestion des snapshots.

4) Vérifier le chemin réseau de migration

• Incompatibilité MTU, routage asymétrique, règles de firewall ou un bond saturé peuvent tuer une migration.
• Des pics de latence peuvent prolonger la pré‑copie indéfiniment jusqu’à timeout ou abandon par l’opérateur.

5) Vérifier les bloqueurs côté invité

• Huge pages, périphériques en passthrough, CD‑ROM/ISO locaux, ou flags CPU non supportés peuvent bloquer ou dégrader la migration.
• Le ballooning mémoire et le taux de pages modifiées peuvent faire en sorte qu’une migration en direct « n’en finisse jamais ».

Une fois le problème classifié, arrêtez de tourner en rond. Choisissez la voie de réparation et suivez‑la jusqu’au bout. C’est la différence entre opérateurs expérimentés et clique‑boutons.

Faits et contexte intéressants (pourquoi ça échoue ainsi)

• Fait 1 : Proxmox VE utilise Corosync pour l’appartenance au cluster et pmxcfs (un système de fichiers FUSE) pour distribuer la configuration sous /etc/pve. Si pmxcfs est mal en point, les migrations deviennent vite étranges.
• Fait 2 : La migration en direct de QEMU repose sur un algorithme pré‑copie : il envoie les pages mémoire pendant que la VM tourne, puis renvoie les pages « sales ». Un taux d’écritures élevé peut empêcher la convergence.
• Fait 3 : Le canal de migration n’est pas « juste SSH ». Proxmox utilise SSH pour l’orchestration, mais QEMU ouvre son propre flux de migration (souvent sur un réseau dédié) qui peut être bloqué même si SSH fonctionne.
• Fait 4 : Les configs des VM dans Proxmox sont stockées sous forme de fichiers texte dans /etc/pve/qemu-server/. Une config partiellement écrite ou un verrou obsolète peut faire échouer les nouvelles tentatives.
• Fait 5 : Les VMs sur Ceph (RBD) migrent généralement l’état compute sans copier les disques, mais vous misez alors sur la santé de Ceph, les permissions clients et les chemins réseau vers les réseaux public et cluster de Ceph.
• Fait 6 : La réplication ZFS dans Proxmox est basée sur des snapshots. Fiable, mais pas magique : snapshots manquants, renommage de datasets ou commandes zfs « aidantes » peuvent casser la chaîne.
• Fait 7 : Le mécanisme de « verrou VM » existe pour empêcher les opérations concurrentes. Si une migration s’abandonne au mauvais moment, le verrou peut rester et bloquer tout jusqu’à son nettoyage.
• Fait 8 : Les incompatibilités MTU apparaissent souvent comme « marche pour petits transferts, casse pour gros ». Les migrations sont des gros transferts.

Causes racines fréquentes, avec chemins de réparation

A) Problèmes d’état du cluster (quorum, corosync, pmxcfs)

Ce à quoi ça ressemble : La migration échoue immédiatement, parfois avec des erreurs génériques ; l’interface peut afficher des nœuds « ? » ; les configs n’apparaissent pas sur tous les nœuds ; les tâches échouent avec « no quorum » ou ne peuvent pas écrire sous /etc/pve.

Ce qui se passe réellement : Proxmox a besoin d’une appartenance au cluster cohérente pour déplacer des ressources en toute sécurité. Sans quorum, il refuse de faire des changements. Si pmxcfs est dégradé, même lire/écrire les configs VM peut échouer.

Chemin de réparation : Stabilisez le cluster d’abord. Si votre cluster n’est pas sain, ne migrez pas. Corrigez les liens corosync, le quorum et la synchronisation temporelle. Puis retentez la migration.

B) Échecs SSH et d’authentification (couche d’orchestration)

Ce à quoi ça ressemble : « migration aborted: ssh error » ou des échecs en début de log de tâche. Parfois intermittent — rien de tel qu’un changement de clés en milieu de journée pour pimenter l’entreprise.

Ce qui se passe réellement : Proxmox utilise SSH entre nœuds pour la coordination et certains transferts de fichiers. Mauvaises clés hôtes, known_hosts cassé, permissions, ou commande forcée dans authorized_keys peuvent tuer le processus.

Chemin de réparation : Vérifiez l’accès SSH root entre les nœuds (comme Proxmox l’attend), corrigez les mismatches de clés hôtes, confirmez que sshd permet ce dont vous avez besoin, puis retentez.

C) Problèmes du chemin réseau de migration (firewall, MTU, routage, congestion)

Ce à quoi ça ressemble : La migration démarre puis s’annule ; les logs affichent « connection reset », timeouts, ou erreurs de socket migration QEMU. Parfois ça atteint 90% puis échoue. Indice : la coordination initiale a fonctionné ; le plan de données n’a pas.

Ce qui se passe réellement : Le flux de migration de QEMU est sensible à la perte de paquets et aux problèmes de path MTU. Les firewalls peuvent autoriser SSH mais bloquer la plage de ports de migration. Ou vous exécutez la migration sur un réseau de production saturé par Ceph, sauvegardes et rsync « temporaires ».

Chemin de réparation : Confirmez la MTU bout en bout, assurez‑vous que le firewall permet le trafic de migration, placez la migration sur une interface dédiée si possible, et arrêtez de saturer le lien.

D) Incompatibilité de stockage : réalité partagée vs locale

Ce à quoi ça ressemble : « storage ‘local-lvm’ not found on target », « volume does not exist », « cannot open disk image », ou migration qui s’abandonne après avoir copié certains disques.

Ce qui se passe réellement : La configuration VM référence des IDs de stockage. Si le nœud cible n’a pas la même définition de stockage (même ID, type compatible), Proxmox ne peut pas placer le disque. Pour le stockage local, il faut soit déplacer les disques (migration de stockage), soit les répliquer (réplication ZFS, sauvegarde/restauration, etc.).

Chemin de réparation : Alignez les définitions de stockage entre nœuds, confirmez l’espace, vérifiez les volumes, et choisissez la méthode de migration appropriée (mouvement compute en direct vs hors ligne avec transfert de disques).

E) Échecs de copie de disque (espace, permissions, stockage lent, bizarrerie de snapshot)

Ce à quoi ça ressemble : rsync ou qemu-img échoue ; « No space left on device » ; « Input/output error » ; migration très lente puis abandon.

Ce qui se passe réellement : La migration de disque est une charge de travail stockage : métadonnées lourdes pour qcow2, séquentiel pour raw, et pénalisant pour les volumes thin fragmentés. De plus, si le stockage sous‑jacent est dégradé (erreurs ZFS, recovery Ceph), vous le découvrirez pendant la migration.

Chemin de réparation : Vérifiez l’espace, la santé du stockage et les erreurs I/O. Si le stockage est malade, arrêtez les migrations et réparez le stockage. Si c’est juste lent, planifiez une fenêtre hors production et faites une migration hors ligne.

F) Contraintes invité (modèle CPU, passthrough, hugepages, TPM, média local)

Ce à quoi ça ressemble : La migration s’interrompt avec des messages sur des périphériques, incompatibilité CPU ou « cannot migrate with device ». Parfois elle échoue après le démarrage de QEMU car la destination ne peut pas recréer le même matériel virtuel.

Ce qui se passe réellement : La migration en direct exige que la destination émule un ensemble de CPU et de périphériques compatibles. Le passthrough PCI, certains périphériques USB et quelques configurations sont hostiles à la migration. L’état TPM peut aussi compliquer selon la configuration.

Chemin de réparation : Utilisez une base CPU compatible (par ex. x86-64-v2/v3), évitez le passthrough pour les VMs devant migrer, détachez les médias locaux, et choisissez la migration hors ligne si nécessaire.

G) Verrous, restes et état à moitié migré

Ce à quoi ça ressemble : La VM est indiquée comme verrouillée ; les opérations suivantes disent « resource is locked » ; la config existe sur les deux nœuds ; des disques existent à deux endroits avec des noms similaires.

Ce qui se passe réellement : Une migration est une transaction avec étapes de nettoyage. Si elle s’abandonne, le nettoyage peut ne pas s’exécuter. Résultat : un verrou qui bloque les opérations futures et des artefacts sur la cible qui perturbent la tentative suivante.

Chemin de réparation : Identifiez où la VM tourne réellement, puis supprimez les verrous obsolètes et ne supprimez que les artefacts que vous pouvez prouver sûrs à supprimer. « Prouver » signifie : vérifier les références de volume, les VMID et le contenu du stockage — deux fois.

Tâches pratiques : commandes, ce que signifie la sortie, et la décision à prendre

Voici les actions que j’exécute en production. Chaque tâche inclut une commande, ce que « bon » et « mauvais » signifient, et la décision suivante. Exécutez‑les sur les nœuds source et cible selon le cas.

Task 1: Récupérer l’échec exact depuis le journal des tâches Proxmox

cr0x@server:~$ tail -n 80 /var/log/pve/tasks/active
UPID:pve1:000A1B2C:0F2B3C4D:676D2A1E:qmigrate:101:root@pam:

cr0x@server:~$ cat /var/log/pve/tasks/0F/2B/UPID:pve1:000A1B2C:0F2B3C4D:676D2A1E:qmigrate:101:root@pam: | tail -n 60
starting migration of VM 101 to node 'pve2' (192.168.10.12)
found local disk 'local-lvm:vm-101-disk-0' (in current node)
migration aborted (duration 00:00:14): storage 'local-lvm' not available on target node
TASK ERROR: migration aborted

Signification : Le journal de tâche contient généralement une ligne qui compte. Ici c’est un mismatch d’ID de stockage.

Décision : Arrêtez de dépanner le réseau. Corrigez les définitions de stockage ou effectuez une migration de stockage / sauvegarde‑restauration.

Task 2: Vérifier le quorum et l’appartenance au cluster

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 14:12:06 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Signification : Quorate: Yes signifie que les écritures sur le cluster sont autorisées. Si c’est « No », les migrations sont une mauvaise idée.

Décision : Si pas de quorum : corrigez le réseau/temps du cluster ou restaurez le quorum. Ne forcez pas les migrations sauf si vous aimez les split‑brain surprises.

Task 3: Vérifier la santé des liens corosync

cr0x@server:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 10.10.0.11
        status  = OK
LINK ID 1 udp
        addr    = 10.20.0.11
        status  = OK

Signification : Les liens doivent être OK. Les liens qui oscillent provoquent des retards de pmxcfs et des échecs « aléatoires ».

Décision : Si un lien est down : réparez le réseau avant la migration. La stabilité de corosync n’est pas optionnelle.

Task 4: Confirmer que pmxcfs est monté et réactif

cr0x@server:~$ mount | grep pve
pve on /etc/pve type fuse.pve (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

cr0x@server:~$ ls -la /etc/pve/qemu-server | head
total 0
drwxr-xr-x 2 root www-data 0 Dec 26 13:58 .
drwxr-xr-x 8 root www-data 0 Dec 26 13:58 ..
-rw-r----- 1 root www-data 512 Dec 26 13:40 101.conf

Signification : Si /etc/pve n’est pas monté, vous n’êtes pas dans un état de cluster sain.

Décision : Réparez pmxcfs/corosync avant toute autre action. Migrer avec un filesystem de configuration cassé, c’est s’assurer du travail le week‑end.

Task 5: Vérifier si la VM est verrouillée (et pourquoi)

cr0x@server:~$ qm config 101 | grep -i lock
lock: migrate

Signification : Un verrou indique une opération en cours ou une opération avortée qui n’a pas nettoyé.

Décision : Ne supprimez pas les verrous aveuglément. Déterminez d’abord où la VM tourne réellement (Task 6). Si elle est stable et que vous faites du nettoyage, alors vous pouvez débloquer.

Task 6: Déterminer où la VM tourne réellement

cr0x@server:~$ qm status 101
status: running

cr0x@server:~$ pvesh get /cluster/resources --type vm | awk '$1 ~ /qemu/ && $2 ~ /101/ {print}'
qemu 101 running pve1

Signification : La vue des ressources du cluster doit indiquer un nœud propriétaire. Si elle affiche « unknown » ou bascule, votre cluster est instable.

Décision : Si la VM tourne sur la source, considérez les artefacts sur la cible comme suspects. Si elle tourne sur la cible, arrêtez de « re‑migrer » tant que configs et disques ne sont pas alignés.

Task 7: Supprimer un verrou obsolète (seulement après vérification)

cr0x@server:~$ qm unlock 101

Signification : qm unlock retire le verrou d’opération, pas le problème sous‑jacent.

Décision : Si le déverrouillage est nécessaire pour poursuivre le nettoyage (supprimer volumes partiels, retenter la migration), faites‑le. Si vous déverrouillez pour « faire disparaître l’erreur », replongez dans le journal.

Task 8: Valider que les définitions de stockage correspondent entre nœuds

cr0x@server:~$ pvesm status
Name        Type     Status     Total     Used    Available   %
local       dir      active    196G      22G        164G     11%
local-lvm   lvmthin  active    900G     610G        290G     67%
ceph-rbd    rbd      active     10T       6T          4T     60%

Signification : La colonne Name (ID de stockage) doit exister sur la source et la cible pour les disques de la VM. Même ID, backend compatible.

Décision : Si local-lvm existe sur la source mais pas la cible : soit le définir sur la cible (si approprié), soit déplacer les disques vers un stockage partagé d’abord.

Task 9: Vérifier les volumes de disque réellement référencés par la VM

cr0x@server:~$ qm config 101 | egrep '^(scsi|virtio|sata|ide)[0-9]+:'
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,size=80G
scsi1: ceph-rbd:vm-101-disk-1,size=200G

Signification : Le stockage mixte est courant. C’est aussi un piège fréquent : un disque est partagé, l’autre non.

Décision : Soit déplacez scsi0 vers un stockage partagé (migration de stockage), soit acceptez une migration hors ligne avec transfert de disque.

Task 10: Vérifier l’espace libre là où le disque atterrirait

cr0x@server:~$ lvs -a -o+lv_size,data_percent,metadata_percent,lv_attr,devices pve
  LV            VG  Attr       LSize   Data%  Meta%  Attr       Devices
  data          pve twi-aotz-- 900.00g  67.11  12.03 twi-aotz-- /dev/sda3(0)
  vm-101-disk-0 pve Vwi-aotz--  80.00g  92.30         Vwi-aotz-- data(12345)

Signification : Pour les pools thin, surveillez le Data% du pool et du LV spécifique. Une utilisation élevée du pool signifie que la prochaine écriture peut échouer en cours de migration.

Décision : Si l’utilisation du pool est élevée : libérez de l’espace, étendez le pool, ou ne migrez pas encore. « Disque plein pendant migration » est un classique générateur d’états partiels.

Task 11: Vérifier la santé de Ceph avant d’imputer à Proxmox

cr0x@server:~$ ceph -s
  cluster:
    id:     6e0e1d8a-5a1c-4b7a-a7a0-3f1b3e8c9c51
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 12/345678 objects degraded (0.003%)

  services:
    mon: 3 daemons, quorum a,b,c
    mgr: x(active), standbys: y
    osd: 9 osds: 8 up, 9 in

  data:
    pools:   4 pools, 512 pgs
    objects: 115k objects, 420 GiB
    usage:   1.2 TiB used, 8.8 TiB / 10 TiB avail
    pgs:     510 active+clean, 2 active+degraded

Signification : La migration en direct avec Ceph repose sur un I/O Ceph stable. Si Ceph est dégradé, votre VM peut sembler OK, mais les migrations et redémarrages deviennent aléatoires.

Décision : Si Ceph n’est pas sain : réparez Ceph d’abord, puis migrez. La migration n’est pas l’endroit pour découvrir que vous étiez à un OSD d’un gros problème.

Task 12: Valider le réseau de migration et la MTU (le tueur silencieux)

cr0x@server:~$ ip -br link show | egrep 'vmbr|bond|enp'
bond0            UP             3c:fd:fe:aa:bb:cc
vmbr0            UP             3c:fd:fe:aa:bb:cc
enp65s0f0        UP             3c:fd:fe:aa:bb:cc

cr0x@server:~$ ip link show vmbr0 | grep mtu
mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

cr0x@server:~$ ping -M do -s 8972 -c 3 10.10.0.12
PING 10.10.0.12 (10.10.0.12) 8972(9000) bytes of data.
8980 bytes from 10.10.0.12: icmp_seq=1 ttl=64 time=0.412 ms
8980 bytes from 10.10.0.12: icmp_seq=2 ttl=64 time=0.401 ms
8980 bytes from 10.10.0.12: icmp_seq=3 ttl=64 time=0.398 ms

--- 10.10.0.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms

Signification : Si vous avez configuré des jumbo frames, elles doivent fonctionner bout en bout. Si vous voyez « Frag needed » ou perte de paquets, attendez‑vous à des problèmes de migration.

Décision : Si la MTU ne correspond pas : corrigez le réseau ou abaissez la MTU à 1500 de façon cohérente. Les MTU mixtes sont du théâtre de performance avec un fort taux de casse.

Task 13: Vérifier l’état du firewall et les règles (SSH qui marche n’est pas une preuve)

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ iptables -S | head -n 20
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N PVEFW-FORWARD
-N PVEFW-INPUT
-N PVEFW-OUTPUT

Signification : Si le firewall Proxmox est activé, assurez‑vous que le trafic de migration est autorisé sur les interfaces utilisées. L’interface GUI peut l’afficher, mais la vérité CLI est plus rapide en incident.

Décision : Si des règles bloquent les ports de migration : corrigez les règles. Ne désactivez pas le firewall « temporairement » sauf si vous aimez rédiger des rapports d’incident.

Task 14: Chercher les erreurs migration côté QEMU dans journald

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd --since "1 hour ago" | tail -n 80
Dec 26 13:57:22 pve1 pvedaemon[1923]: starting migration of VM 101 to node 'pve2'
Dec 26 13:57:33 pve1 pvedaemon[1923]: migration aborted: QEMU exited with code 1
Dec 26 13:57:33 pve1 pvedaemon[1923]: ERROR: vm 101 - unable to migrate - VM uses local cdrom 'local:iso/installer.iso'

Signification : C’est le type de blocage « évident après coup » que l’erreur générique masque.

Décision : Détachez l’ISO local ou assurez‑vous que le même chemin/stockage ISO existe sur la cible.

Task 15: Valider les paramètres de compatibilité CPU

cr0x@server:~$ qm config 101 | grep -E '^cpu:'
cpu: host,flags=+aes

cr0x@server:~$ pvesh get /nodes/pve1/capabilities/qemu/cpu | head
cputype
kvm64
qemu64
x86-64-v2-AES
x86-64-v3

Signification : cpu: host est rapide mais vous lie aux fonctionnalités CPU de la source. Migrer vers un nœud avec une microarchitecture différente peut échouer ou forcer un reset.

Décision : Dans les clusters avec CPUs mixtes, standardisez un modèle CPU de base pour les VMs migrables.

Task 16: Inspecter l’état de la réplication (utilisateurs de réplication ZFS)

cr0x@server:~$ pvesr status
JobID  Guest  Target  Last_sync              Status
101    101    pve2    2025-12-26 13:40:02    ok

Signification : Si la réplication est obsolète ou échoue, les migrations qui supposent « le disque déjà présent » vont avorter ou démarrer sur une version de disque incorrecte.

Décision : Réparez les erreurs de réplication d’abord ; ne faites pas de migration pour dépanner la réplication.

Erreurs courantes : symptôme → cause → correction

1) Symptom : « storage not available on target »

Cause : L’ID de stockage référencé dans la config VM n’existe pas sur la cible, ou existe mais différemment (dir vs lvmthin vs zfs).

Correction : Alignez les définitions de stockage sur les nœuds (pvesm status), ou migrez les disques vers un stockage partagé d’abord, ou réalisez une migration hors ligne avec déplacement de disque.

2) Symptom : Migration avortée après démarrage, avec « connection reset »

Cause : MTU mismatch, firewall bloquant le flux de migration, ou lien congestionné provoquant un timeout QEMU.

Correction : Testez la MTU avec ping -M do, vérifiez les règles de firewall, déplacez les migrations sur un réseau dédié ou réduisez le trafic pendant la fenêtre.

3) Symptom : VM reste verrouillée après échec

Cause : Le nettoyage ne s’est pas terminé ; le verrou est resté dans la config.

Correction : Vérifiez où la VM tourne (pvesh get /cluster/resources), puis qm unlock <vmid>. Nettoyez les disques partiels seulement après avoir prouvé qu’ils ne sont pas utilisés.

4) Symptom : « no quorum » ou le cluster affiche des nœuds inconnus

Cause : Échec du lien corosync, réseau divisé, ou problèmes de synchronisation temporelle menant à une instabilité d’appartenance.

Correction : Restaurez la communication corosync. Ne migrez pas tant que pvecm status n’est pas quorate et stable.

5) Symptom : La migration échoue seulement pour certaines VMs

Cause : Ces VMs utilisent cpu: host, des périphériques en passthrough, des ISOs locaux, ou des modèles de périphériques spéciaux incompatibles avec la cible.

Correction : Standardisez les modèles CPU, retirez le hardware non migrable pour ces invités, assurez l’accès aux médias depuis les deux nœuds, ou réalisez une migration hors ligne.

6) Symptom : Migration « bloque » à un pourcentage élevé pendant longtemps

Cause : Le taux de pages modifiées dépasse la bande passante de migration ; la mémoire change plus vite qu’on ne peut la copier.

Correction : Réduisez la charge d’écriture de l’invité (temporairement), augmentez la bande passante de migration, ou passez à une migration hors ligne pour cette fenêtre de charge.

7) Symptom : Migration avortée et la cible a des volumes résiduels

Cause : La copie de disque s’est partiellement terminée ; la cible a maintenant des volumes orphelins ou des datasets partiels.

Correction : Identifiez les volumes appartenant au VMID, confirmez qu’ils ne sont référencés par aucune config VM, puis supprimez‑les. Si doute, conservez‑les et changez le plan pour restaurer depuis sauvegarde/réplication.

Petite blague #2 : « Réessayez » n’est pas une stratégie ; c’est la façon de transformer une erreur en événement récurrent sur le calendrier.

Trois mini-récits du monde de l’entreprise (anonymisés, réalistes)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox deux nœuds pour des outils internes. Rien d’extraordinaire : quelques dizaines de VMs, LVM‑thin local sur chaque nœud, et des sauvegardes nocturnes. Quelqu’un a demandé une maintenance sur le nœud A, alors l’ingénieur d’astreinte a décidé de « juste migrer en direct tout vers le nœud B ».

L’hypothèse était simple : « La migration est un déplacement de calcul. » Ils avaient utilisé la migration en direct dans un autre environnement avec stockage partagé et ont oublié que, dans ce cluster, les blocs de disque étaient locaux. La première migration a renvoyé « migration aborted », et l’ingénieur a interprété cela comme un « souci réseau » et a réessayé. Et encore.

Chaque tentative a créé des artefacts partiels de disques sur la cible. LVM‑thin est efficace jusqu’à un certain point : les métadonnées ont augmenté, le thin pool a commencé à se remplir, et des VMs non liées sur le nœud B ont constaté des pauses I/O. Le problème de migration est devenu un problème de plateforme.

Ils ont finalement arrêté et regardé la config VM. local-lvm n’était pas un stockage partagé ; c’était deux îles séparées portant le même nom dans la conversation humaine, pas dans la réalité Proxmox. La correction a été ennuyeuse : arrêter les migrations en direct, planifier une migration hors ligne avec déplacement de stockage, ou restaurer depuis sauvegarde sur l’autre nœud.

La leçon opérationnelle : la migration est d’abord une décision de topologie de stockage, puis une décision de calcul. Si vous ne savez pas où sont les blocs, vous ne savez pas ce que vous déplacez.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise avait construit un « réseau fast lane » pour la migration Proxmox et le trafic Ceph. Jumbo frames activées, bonding configuré, VLAN séparé, tout y était. Les graphiques étaient beaux. Les opérateurs se sentaient confiants. C’est là que l’histoire se complique.

Un switch sur le chemin avait un port configuré en MTU 1500 à cause d’un modèle mal appliqué. La plupart du trafic fonctionnait. SSH fonctionnait. Le cluster Ceph fonctionnait en grande partie parce qu’il est résilient et que les petits paquets sont courants. Mais les migrations en direct s’abandonnaient de manière intermittente en plein transfert avec des erreurs de socket vagues.

Les ingénieurs ont chassé des fantômes : versions Proxmox, mises à jour du noyau, options QEMU. Certains ont essayé « désactivez le firewall ». Ça n’a pas aidé. Quelqu’un a même blâmé une VM spécifique parce qu’« elle modifie trop la mémoire ». C’était partiellement vrai, mais pas la cause racine.

La percée est venue d’une sonde MTU simple. Les ICMPs volumineux avec « do not fragment » échouaient sur le réseau de migration. Corriger la MTU sur ce port de switch a rendu les migrations d’aléatoires à banales.

Le problème n’était pas les jumbo frames ; c’était les jumbo frames incohérentes. Les optimisations qui exigent une parfaite cohérence à travers l’infrastructure doivent être traitées comme des changements de production, pas comme un « assaisonnement réseau ».

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe exploitant Proxmox avec des générations CPU mixtes a standardisé tôt les types de CPU des VMs. Elles n’utilisaient pas cpu: host pour rien qui pourrait migrer. Elles ont choisi un modèle CPU de base et l’ont documenté. Ça leur a coûté un peu de performance de pointe. Ça les a sauvés plusieurs fois.

Un après‑midi, un nœud a commencé à générer des erreurs mémoire ECC. Le matériel était dégradé mais encore partiellement fonctionnel. Ils devaient évacuer rapidement les VMs pour éviter des corruptions que l’on ne découvre qu’aux audits trimestriels. La migration en direct était le plan, et elle devait fonctionner.

Parce que la compatibilité CPU était déjà standardisée, ils n’ont pas été bloqués par « la destination ne prend pas en charge les fonctionnalités demandées ». Parce que les IDs de stockage étaient cohérents entre les nœuds, ils n’ont pas perdu de temps à créer des mappings d’urgence. Ils avaient un réseau de migration dédié testé chaque trimestre avec une sonde MTU et un iperf.

L’évacuation a réussi. Le postmortem a été presque sans drame. Le « geste héroïque » était une checklist qu’ils suivaient depuis des mois : modèles CPU cohérents, nommage de stockage constant, validation périodique du chemin de migration.

La fiabilité, c’est surtout de la répétition. La partie excitante est optionnelle.

Listes de contrôle / plan étape par étape (récupération propre et prévention)

Étape par étape : récupérer proprement après un abandon de migration

1. Arrêtez de réessayer. Récupérez le journal de tâche et identifiez la première ligne d’erreur exploitable.
2. Confirmez la réalité de la VM. Où tourne‑t‑elle ? Quel nœud la possède selon les ressources du cluster ?
3. Stabilisez le cluster. Si le quorum ou corosync est instable, réparez cela d’abord.
4. Vérifiez les verrous. Si la VM est verrouillée pour migration et que vous devez continuer, déverrouillez seulement après avoir identifié quel nœud est autoritaire.
5. Vérifiez la topologie de stockage. Les disques sont‑ils sur un stockage partagé ? Les IDs de stockage existent‑ils sur les deux nœuds ?
6. Inspectez les artefacts disques sur la cible. Identifiez les volumes/datasets orphelins ; ne supprimez rien que vous ne pouvez pas attribuer.
7. Choisissez la bonne méthode de migration :
   • Stockage partagé sain → la migration en direct est raisonnable.
   • Stockage local impliqué → planifiez une migration de stockage ou une migration hors ligne.
   • Réplication présente → assurez‑vous que la réplication est à jour et cohérente.
8. Retentez une fois, avec intention. Même erreur deux fois signifie que vous n’avez pas changé les conditions. Ne collectionnez pas les erreurs comme des cartes à échanger.

Checklist de prévention : rendre « migration aborted » plus rare

• Standardisez les IDs de stockage sur tous les nœuds. Même noms, mêmes types, mêmes attentes.
• Modèle CPU de base pour les charges migrables. Évitez cpu: host sauf si la VM est conçue pour être non migrable.
• Séparez les réseaux quand c’est pratique : management, corosync, stockage, migration. Au minimum, isolez la contention de bande passante.
• Validez la MTU bout en bout (chaque trimestre, après changement de switch ou firmware). Les jumbo frames sont un contrat.
• Surveillez la santé du stockage (Ceph, ZFS, SMART). Les migrations amplifient les signaux faibles.
• Documentez les VMs non migrables (passthrough, contraintes de licence, périphériques spéciaux) pour que l’astreinte ne le découvre pas en pleine urgence.
• Exercez la migration de façon régulière. Si vous ne migrez qu’en urgence, vous faites de l’ingénierie du chaos sans en tirer les bénéfices.

FAQ

1) Pourquoi Proxmox affiche seulement « migration aborted » sans raison claire ?

Parce que la tâche de haut niveau encapsule plusieurs sous‑systèmes. La ligne exploitable se trouve généralement plus tôt dans le journal de tâche ou dans journald pour pvedaemon/qemu.

2) Puis‑je migrer en direct une VM utilisant local-lvm ?

Pas comme simple déplacement de calcul. Si les disques sont locaux au nœud source, il faut que les disques soient disponibles sur la cible (stockage partagé, réplication, ou copie de disque). Sinon Proxmox avortera.

3) Est‑il sûr d’exécuter qm unlock après une migration échouée ?

C’est sûr après avoir confirmé où la VM tourne réellement et quels artefacts existent. Le déverrouillage n’est pas destructeur, mais il peut permettre à vous (ou à l’automatisation) d’exécuter ensuite des actions destructrices.

4) Pourquoi la migration échoue à 90–99% puis s’abandonne ?

C’est souvent la phase de bascule finale ou de convergence. Causes communes : taux de pages modifiées trop élevé, instabilité réseau, ou la destination incapable de recréer un périphérique/fonction CPU.

5) « SSH fonctionne » signifie‑t‑il que le réseau de migration est correct ?

Non. SSH est le plan de contrôle. La migration QEMU est un flux de données qui peut être bloqué par des règles de firewall, des problèmes MTU, ou des différences de routage même si SSH est parfait.

6) Quelle est la façon la plus rapide de dire si le stockage est en cause ?

Vérifiez les lignes de disque dans la config VM et comparez‑les à pvesm status sur la cible. Si un ID de stockage référencé n’existe pas ou n’est pas partagé, c’est un problème de stockage.

7) Comment gérer les disques résiduels sur la cible après une migration de stockage ratée ?

Identifiez les volumes par VMID, confirmez qu’ils ne sont référencés par aucune config VM sur la cible ou la source, puis supprimez‑les. En cas d’incertitude, conservez‑les et récupérez via sauvegarde/restauration pour éviter de supprimer la seule copie bonne.

8) Pourquoi les réglages CPU empêchent‑ils la migration ?

La migration en direct exige que la destination offre un CPU virtuel compatible. Utiliser cpu: host expose des fonctionnalités CPU spécifiques à l’hôte ; si la cible ne peut pas les reproduire, QEMU peut refuser la migration ou la VM peut ne pas démarrer en toute sécurité.

9) Des problèmes Ceph peuvent‑ils apparaître comme « migration aborted » même si les VMs semblent OK ?

Oui. La migration met le stockage sous pression avec des opérations métadonnées, des reconnexions et parfois des rafales d’I/O concurrentes. Un cluster Ceph légèrement dégradé peut « fonctionner » jusqu’à ce que vous lui demandiez quelque chose d’ambitieux en même temps.

10) Quand dois‑je arrêter d’essayer la migration en direct et passer hors ligne ?

Quand la charge a un taux de pages modifiées élevé, quand le réseau est contraint, quand le stockage est local et doit être copié de toute façon, ou quand vous êtes en incident et avez besoin de déterminisme plus que d’élégance.

Prochaines étapes (ce qu’il faut faire après réparation)

Après que la migration ait réussi — ou après avoir choisi la voie hors ligne correcte — effectuez ces suivis pratiques :

1. Consignez la cause racine dans vos notes d’exploitation. Le prochain abandon semblera « nouveau » à moins que vous ne l’étiquetiez.
2. Normalisez les IDs de stockage et les modèles CPU à travers le cluster. C’est une de ces tâches ennuyeuses qui paie chaque mois.
3. Testez le réseau de migration avec une sonde MTU et un test de débit durant une fenêtre calme. Faites‑en une tâche récurrente, pas une découverte héroïque.
4. Auditez les configs VM pour ISOs locaux, périphériques passthrough et usage de « host CPU ». Décidez quelles VMs doivent être migrables et configurez‑les en conséquence.
5. Nettoyez les artefacts des migrations avortées : volumes obsolètes, anciens snapshots, jobs de réplication restants. Faites‑le avec des preuves, pas des impressions.

L’objectif n’est pas d’éliminer les échecs. L’objectif est de rendre les échecs lisibles, récupérables et moins fréquents. « migration aborted » devient ennuyeux une fois que votre cluster, votre réseau et votre stockage cessent de se surprendre mutuellement.