Échec de la migration à chaud Proxmox : que vérifier pour le réseau, les flags CPU et le stockage

décembre 1, 2025 • février 3, 2026 • Lecture : 36 min • Views: 9

Cet article vous a aidé ?

Si vous administrez Proxmox assez longtemps, la migration à chaud finira par vous trahir au pire moment : pendant une fenêtre de maintenance, à cause d’un « noisy neighbor », ou cinq minutes avant une démo. L’interface indique « failed », la VM tourne encore (peut-être), et vous avez un journal qui ressemble à un roman à suspense écrit par QEMU.

Il s’agit d’un guide orienté production pour isoler pourquoi une migration à chaud Proxmox échoue — spécifiquement les trois gros motifs : réseau, flags CPU et stockage. Nous allons vérifier les faits, pas les impressions. Vous allez lancer des commandes, interpréter des sorties et prendre des décisions qui arrêtent l’hémorragie.

Playbook de diagnostic rapide (quoi vérifier en premier)

Les échecs de migration à chaud semblent aléatoires parce que l’échec peut survenir à plusieurs phases : vérifications pré-vol, établissement du canal de migration, transfert RAM en pré-copy, bascule stop-and-copy, et nettoyage post-migration. Votre travail est d’identifier rapidement la phase et le goulot d’étranglement.

Première étape : identifier la phase et l’erreur réelle (pas le résumé de l’UI)

Vérifiez le journal de tâche dans l’UI, puis allez directement consulter les journaux système sur les deux nœuds.
Décision : si vous ne trouvez pas d’erreur concrète en 2 minutes, vous regardez le mauvais journal.

Deuxième étape : confirmer un chemin réseau de migration fonctionnel

Vérifiez la connectivité nœud-à-nœud sur les adresses IP réellement utilisées pour la migration (pas « management », pas « le ping qui passe »).
Contrôlez le MTU, la perte de paquets, la latence et les règles de pare-feu.
Décision : en cas de mismatch MTU ou de perte intermittente, corrigez le réseau avant de toucher aux paramètres Proxmox. La migration est un flux soutenu à haut débit ; il trouvera chaque faiblesse.

Troisième étape : confirmer la compatibilité du modèle CPU et la cohérence du type de machine QEMU

Comparez la configuration CPU de la VM avec les flags CPU des hôtes.
Décision : si le CPU est réglé sur host et que les nœuds ne sont pas identiques, stoppez. Définissez un type CPU compatible (par exemple x86-64-v2/v3) et retestez.

Quatrième étape : confirmer les hypothèses de stockage (partagé vs local, et ce qui doit être déplacé)

Le disque est-il sur un stockage partagé ? Sinon, l’option « with local disks » est-elle activée et y a-t-il bande passante et espace ?
Décision : si le disque VM est local et énorme, la migration à chaud peut être « en cours » mais pratiquement impossible dans votre fenêtre. Planifiez une migration froide ou une réplication.

Cinquième étape : vérifier la santé du cluster et la synchronisation horaire

Corosync et les problèmes de quorum peuvent bloquer les opérations, et la dérive horaire peut créer des symptômes bizarres TLS et d’authentification.
Décision : si le cluster n’est pas sain, ne faites pas de la migration votre premier correctif. C’est une fonctionnalité qui suppose une base stable.

Vérité opérationnelle : quand une migration échoue, les gains les plus rapides viennent de la vérification du chemin réseau et des hypothèses sur le modèle CPU. Le stockage est en général un problème à plus long terme, pas le tueur instantané “connexion fermée”.

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

La migration à chaud précède la plupart du branding « cloud ». La migration pratique des VMs était un sujet de recherche au début des années 2000 ; le pré-copy est devenu l’approche par défaut car il minimise le downtime en copiant itérativement les pages modifiées.
La migration QEMU est un protocole, pas un tour de magie. Il stream l’état de la VM (pages RAM, état CPU, état des périphériques) sur un canal qui se comporte comme toute autre connexion longue : perte, problèmes de MTU ou intervention de pare-feu peuvent le tuer.
« Compatibilité CPU » est une promesse contractuelle. Si le CPU de destination ne prend pas en charge une instruction utilisée par la VM, QEMU ne peut pas reprendre la VM en toute sécurité. C’est pour cela que les modèles CPU existent — pour promettre moins et déplacer davantage.
Les flags Intel et AMD ne sont pas que du marketing. Des éléments comme AVX/AVX2, AES-NI et les extensions de virtualisation apparaissent comme flags ; un mismatch peut bloquer la migration si le modèle CPU est trop spécifique.
Le type de machine compte. Les « machine types » QEMU (comme i440fx vs q35, et leurs versions) définissent le chipset et les modèles de périphériques. Les incompatibilités peuvent briser la migration même si les CPUs semblent compatibles.
Les mismatches MTU sont l’assassin silencieux des flux à haut débit. Le ping ICMP peut passer alors que de gros paquets se fragmentent ou se perdent ; le trafic de migration est volumineux et soutenu, il frappe vite le mur.
Ceph rend la migration plus simple et plus difficile. Plus simple parce que les disques sont partagés ; plus difficile parce que si le réseau Ceph est malade, la migration devient un stress test non planifié.
La compression et le postcopy existent parce que le pré-copy a ses limites. Si une VM modifie la mémoire plus vite que vous ne pouvez la copier (pensez aux bases de données très actives), le pré-copy peut boucler jusqu’à expiration ou forcer un downtime.
Corosync n’est pas le plan de données de migration. Corosync gère la messagerie de cluster et le quorum ; la migration utilise des canaux séparés (orchestration via SSH et sockets de migration QEMU). Mais un cluster cassé peut quand même bloquer des actions.

Modèle mental : ce que la « migration à chaud » fait réellement

Pensez à la migration à chaud comme à deux workflows qui s’exécutent en parallèle :

Plan de contrôle : Proxmox coordonne le déplacement : vérifie la disponibilité de la cible, verrouille la VM, configure tunnels/ports, démarre un processus QEMU destination en mode « incoming », puis demande au QEMU source de migrer.
Plan de données : QEMU stream l’état d’exécution de la VM : pages mémoire, état des vCPU, état des périphériques. L’état des disques n’est streamé que si vous migrez explicitement des disques locaux (ou faites une migration de stockage). Avec un stockage partagé, les disques restent là ; la VM pointe simplement vers le même bloc depuis un autre nœud.

La plupart des échecs « mystérieux » sont l’un de ces cas :

Échecs de connectivité et de négociation (SSH, pare-feu, mauvaise IP, MTU, TLS/certs, résolution de noms).
Échecs de compatibilité (modèle CPU, flags, type de machine, différences de modèles de périphériques, différences de firmware/UEFI).
Échecs liés au débit/latence (la migration ne peut pas suivre ; le pré-copy ne converge jamais ; la migration de stockage se bloque ; la VM modifie la RAM trop rapidement).
Garde-fous opérationnels (cluster sans quorum, cible sans stockage, mémoire insuffisante, contraintes HA, ou ressources épinglées).

Nous allons maintenant diagnostiquer cela avec des tâches concrètes.

Tâches de vérification pratiques (commandes, sorties, décisions)

Vous voulez des commandes qui répondent à une question chacune. Exécutez-les sur les nœuds source et cible sauf indication contraire. Ne « réparez » rien tant que vous ne pouvez pas expliquer l’échec en une phrase.

Tâche 1 : Identifier la raison de l’échec de migration dans les journaux système

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd -u pve-cluster --since "30 min ago" | tail -n 80
Dec 26 10:12:09 pve1 pvedaemon[2461]: VM 113 qmp command failed - unable to connect to VM 113 qmp socket
Dec 26 10:12:10 pve1 pvedaemon[2461]: start migration failed: command '/usr/bin/ssh -e none -o 'BatchMode=yes' root@10.10.10.12 ...' failed: exit code 255
Dec 26 10:12:10 pve1 pvedaemon[2461]: migration aborted (duration 00:00:03): can't connect to destination

Ce que cela signifie : Il s’agit d’un échec du plan de contrôle. Le code de sortie 255 de SSH signifie généralement un problème d’authentification/clé d’hôte/pare-feu/routage, pas une incompatibilité QEMU.

Décision : Arrêtez de chercher du côté CPU/stockage. Corrigez SSH et la connectivité nœud-à-nœud en premier.

Tâche 2 : Vérifier la configuration du réseau de migration dédié dans Proxmox

cr0x@server:~$ cat /etc/pve/datacenter.cfg
keyboard: en-us
migration: secure,network=10.10.10.0/24

Ce que cela signifie : Proxmox privilégiera 10.10.10.0/24 pour le trafic de migration. Si ce réseau est cassé ou mal routé entre les nœuds, la migration échoue ou traîne.

Décision : Assurez-vous que chaque nœud a une IP stable sur ce sous-réseau et que le routage est correct. Si vous n’avez pas de vrai réseau de migration, supprimez le paramètre ou réparez le réseau.

Tâche 3 : Vérifier les IP que Proxmox pense devoir utiliser

cr0x@server:~$ cat /etc/pve/nodes/pve1/config | sed -n '1,120p'
# node config
acme: account=default

cr0x@server:~$ cat /etc/hosts
127.0.0.1 localhost
192.168.1.11 pve1
192.168.1.12 pve2
10.10.10.11 pve1-mig
10.10.10.12 pve2-mig

Ce que cela signifie : De nombreux clusters s’appuient sur une résolution de noms cohérente. Si pve2 résout sur une IP de management mais que la migration est configurée sur un autre réseau, vous pouvez vous retrouver avec des chemins asymétriques.

Décision : Choisissez un schéma de noms qui ne ment pas. Assurez-vous que le nom d’hôte utilisé pour SSH correspond au réseau prévu, ou utilisez une configuration réseau de migration explicite.

Tâche 4 : Confirmer que SSH root sans mot de passe fonctionne entre les nœuds (la prérequis ennuyeuse)

cr0x@server:~$ ssh -o BatchMode=yes -o ConnectTimeout=5 -e none root@10.10.10.12 "pveversion && hostname && true"
pve-manager/8.2.2/9355359cd (running kernel: 6.8.12-4-pve)
pve2

Ce que cela signifie : Le plan de contrôle peut atteindre la destination et exécuter des commandes.

Décision : Si cela échoue, corrigez les clés SSH, les problèmes known_hosts, le routage ou le pare-feu avant toute autre chose.

Tâche 5 : Vérifier les mismatches MTU et les configurations jumbo-frame partielles

cr0x@server:~$ ip -d link show vmbr1
4: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2c:fd:a1:11:22:33 brd ff:ff:ff:ff:ff:ff promiscuity 0
    bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 0

cr0x@server:~$ ip -d link show vmbr1
4: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2c:fd:a1:aa:bb:cc brd ff:ff:ff:ff:ff:ff promiscuity 0

Ce que cela signifie : Un nœud est en MTU 9000, l’autre en 1500. Ce n’est pas « à peu près correct ». C’est un échec de migration en devenir.

Décision : Standardisez le MTU de bout en bout (NIC, ports de switch, VLAN, bridges). Si vous ne pouvez pas garantir le jumbo partout, repassez en 1500 et passez à autre chose.

Blague #1 : Les jumbo frames sont comme des promesses exécutives — formidables quand elles sont end-to-end, mais un maillon faible les transforme en rumeur coûteuse.

Tâche 6 : Valider le chemin réseau de migration avec de grands paquets (ne faites pas confiance au ping par défaut)

cr0x@server:~$ ping -M do -s 8972 -c 3 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 8972(9000) bytes of data.
8972 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.391 ms
8972 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.402 ms
8972 bytes from 10.10.10.12: icmp_seq=3 ttl=64 time=0.388 ms

--- 10.10.10.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2046ms
rtt min/avg/max/mdev = 0.388/0.393/0.402/0.006 ms

Ce que cela signifie : Les gros paquets passent avec l’option « do not fragment ». Bon signe pour un flux à haut débit.

Décision : Si cela échoue avec « Frag needed » ou perte de paquets, corrigez le MTU et/ou la configuration du switch avant de retenter la migration.

Tâche 7 : Vérifier l’état du pare-feu et les règles liées à la migration

cr0x@server:~$ pve-firewall status
Status: running
Enabled: 1

cr0x@server:~$ iptables -S | grep -E 'DROP|REJECT' | head
-A INPUT -j PVEFW-INPUT
-A FORWARD -j PVEFW-FORWARD

Ce que cela signifie : Le pare-feu est activé. La migration utilise couramment SSH et des ports de migration QEMU négociés par Proxmox. Des règles trop strictes peuvent casser cela.

Décision : Si vous avez activé récemment le pare-feu, confirmez que les autorisations cluster/migration existent. Désactivez temporairement au niveau nœud seulement pour le diagnostic si la politique le permet, puis implémentez des règles correctes.

Tâche 8 : Confirmer le quorum du cluster et la santé de corosync (les opérations sont gateées)

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

Quorum information
------------------
Date:             Thu Dec 26 10:20:31 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.4a
Quorate:          Yes

Ce que cela signifie : Le cluster est quorate. Cela élimine une grande classe de problèmes « pourquoi tout est verrouillé ? ».

Décision : Si non quorate, corrigez d’abord le réseau du cluster. Tenter des migrations comme contournement va aggraver l’incident.

Tâche 9 : Vérifier la config VM pour le modèle CPU et la compatibilité de migration

cr0x@server:~$ qm config 113 | egrep '^(name|memory|cores|sockets|cpu|machine|bios|efidisk0|hostpci|args):'
name: api-prod-01
memory: 16384
cores: 6
sockets: 1
cpu: host,hidden=1,flags=+aes
machine: pc-q35-8.1
bios: ovmf
efidisk0: ceph-vm:vm-113-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M

Ce que cela signifie : Le CPU est réglé sur host. C’est excellent pour la performance et terrible pour les clusters hétérogènes. Notez aussi que le type de machine est versionné.

Décision : Si le nœud cible a une génération/fabricant CPU différent, changez le type CPU pour une base compatible et alignez les types de machine entre nœuds.

Tâche 10 : Comparer les flags CPU hôtes entre nœuds (détecter le mismatch rapidement)

cr0x@server:~$ lscpu | egrep 'Model name|Vendor ID|CPU family|Model:|Flags' | head -n 20
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
CPU family:            6
Model:                 106
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx avx2

cr0x@server:~$ lscpu | egrep 'Model name|Vendor ID|CPU family|Model:|Flags' | head -n 20
Vendor ID:             AuthenticAMD
Model name:            AMD EPYC 7302P 16-Core Processor
CPU family:            23
Model:                 49
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl cpuid tsc_known_freq pni pclmulqdq svm ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx avx2

Ce que cela signifie : Fabricants différents. Avec cpu: host, cette VM échouera presque à coup sûr en migration (ou sera bloquée) car le modèle CPU exposé diffère.

Décision : Utilisez un modèle CPU commun dans la configuration VM. Dans Proxmox, choisissez une base comme x86-64-v2/v3 (selon votre parc) ou un modèle QEMU nommé supporté par tous les nœuds.

Tâche 11 : Confirmer que les versions de QEMU sont suffisamment proches (ne mélangez pas les grandes ères)

cr0x@server:~$ pveversion -v | egrep 'pve-manager|pve-qemu-kvm|kernel'
pve-manager/8.2.2/9355359cd
pve-qemu-kvm: 8.1.5-5
kernel: 6.8.12-4-pve

Ce que cela signifie : Si la source utilise QEMU 8.1 et la cible une version plus ancienne/plus récente avec des types de machine ou des modèles de périphériques incompatibles, vous pouvez rencontrer des incompatibilités de migration.

Décision : Gardez les nœuds sur les mêmes versions majeures Proxmox/QEMU. Faites des upgrades rolling avec une politique : migrez les VMs hors du nœud en cours de mise à jour, n’effectuez pas de migrations entre versions incompatibles en plein upgrade.

Tâche 12 : Inspecter les détails de la tentative de migration dans le journal des tâches

cr0x@server:~$ grep -R "TASK OK\|TASK ERROR\|migration" /var/log/pve/tasks/active 2>/dev/null | tail -n 30
UPID:pve1:00003C2A:0001B2F4:676D5F9A:qmigrate:113:root@pam:
start migration of VM 113 to node 'pve2' (10.10.10.12)
migration aborted (duration 00:00:19): storage 'local-lvm' is not available on node 'pve2'
TASK ERROR: migration aborted

Ce que cela signifie : La vérification de disponibilité du stockage a échoué. Ce n’est pas une question de bande passante ; c’est « vous avez demandé un stockage partagé mais vous ne l’avez pas ».

Décision : Soit déplacez les disques vers un stockage partagé d’abord, soit activez volontairement la migration « with local disks », soit rendez le stockage disponible sur le nœud cible.

Tâche 13 : Déterminer si les disques VM sont sur un stockage partagé ou local

cr0x@server:~$ qm config 113 | grep -E '^(scsi|virtio|sata|ide)[0-9]+:'
scsi0: local-lvm:vm-113-disk-0,size=120G
scsi1: ceph-vm:vm-113-disk-1,size=500G

Ce que cela signifie : Stockage mixte. Un disque est sur local-lvm (local au nœud), l’autre sur Ceph (partagé). La migration à chaud sans migration des disques locaux échouera ou sera bloquée.

Décision : Décidez : soit relocalisez scsi0 vers un stockage partagé (idéal), soit acceptez le coût/temps de migration des disques locaux.

Tâche 14 : Vérifier que le nœud cible a assez de mémoire libre et pas de surprises de ballooning

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           251Gi       118Gi        11Gi       2.1Gi       122Gi       133Gi
Swap:           8.0Gi       0.0Gi       8.0Gi

Ce que cela signifie : Vous avez de la marge. Rappelez-vous : la migration a besoin de mémoire sur la destination pour recevoir les pages, et la VM peut picoter pendant la bascule.

Décision : Si la mémoire disponible est serrée, ne tentez pas le hasard. Migrez une autre VM d’abord, ou planifiez une coupure contrôlée.

Tâche 15 : Vérifier si la VM modifie la mémoire trop vite (le pré-copy peut ne pas converger)

cr0x@server:~$ qm monitor 113 --cmd "info migrate"
capabilities: xbzrle: on  compress: off  events: on  postcopy-ram: off
Migration status: active
transferred ram: 7032.4 MB
remaining ram: 6141.2 MB
total ram: 16384.0 MB
duplicate: 82.1 MB
skipped: 0.0 MB
normal: 6950.3 MB
dirty pages rate: 61200 pages/s
expected downtime: 340 ms

Ce que cela signifie : Le taux de pages sales est élevé. Si cela reste élevé, la migration pourrait ne jamais se terminer ou étendre le downtime au-delà de votre seuil.

Décision : Si cela ne converge pas, limitez la charge, activez la compression de migration avec précaution, ou utilisez postcopy pour des cas spécifiques (en connaissant les risques).

Tâche 16 : Valider la santé de Ceph si les disques VM sont sur Ceph (la migration le mettra à l’épreuve)

cr0x@server:~$ ceph -s
  cluster:
    id:     9c0ad9b4-1b2b-4b4d-a8b8-4f9b4b0f2a71
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 31 sec, osd.7 has slow ops
  services:
    mon: 3 daemons, quorum a,b,c (age 2h)
    mgr: a(active, since 2h)
    osd: 12 osds: 12 up (since 2h), 12 in (since 7d)
  data:
    pools:   3 pools, 256 pgs
    objects: 1.20M objects, 4.6 TiB
    usage:   13 TiB used, 21 TiB / 34 TiB avail
    pgs:     254 active+clean

Ce que cela signifie : Ceph n’est pas totalement heureux. Les slow ops peuvent se traduire par des pics de latence IO VM pendant la migration et bloquer la migration de stockage.

Décision : Si Ceph est dégradé ou lent, reportez les migrations lourdes. Réparez le sous-système de stockage d’abord ; il ne « guérira pas plus vite » sous charge.

Blague #2 : Si votre stockage signale déjà des slow ops, ajouter une migration à chaud, c’est comme « tester » un parachute en sautant deux fois.

Vérifications réseau qui détectent 80 % des échecs

Quand la migration échoue rapidement avec des erreurs de connexion, c’est généralement le réseau ou SSH. Quand elle échoue lentement (ou reste bloquée à un pourcentage), c’est généralement le débit, la perte ou une VM qui ne converge pas. Votre travail est de transformer « le réseau a l’air ok » en réalité mesurable.

Vérifier quelles IPs et routes sont réellement utilisées

Proxmox peut être configuré pour utiliser un réseau de migration, mais le routage Linux décide toujours comment les paquets quittent la machine. Si vous avez plusieurs NICs/VLANs, confirmez que la route vers l’IP de migration cible utilise l’interface prévue.

cr0x@server:~$ ip route get 10.10.10.12
10.10.10.12 dev vmbr1 src 10.10.10.11 uid 0
    cache

Interprétation : Bien : il utilise vmbr1 avec une IP source sur le sous-réseau de migration.

Décision : Si cela route via la NIC de management, corrigez le routage ou ajustez la configuration du réseau de migration pour ne pas saturer le mauvais lien.

Mesurer la perte et la latence comme un adulte

La perte tue le débit TCP ; le jitter rend la convergence plus difficile. Utilisez mtr si disponible, ou au moins un ping consistant. Pour un réseau de migration sur le même switch, vous voulez des chiffres ennuyeux.

cr0x@server:~$ ping -c 50 10.10.10.12 | tail -n 5
--- 10.10.10.12 ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 50062ms
rtt min/avg/max/mdev = 0.312/0.398/0.911/0.089 ms

Décision : Toute perte dans un LAN de datacenter est un signal d’alerte. Réparez le câblage, les ports de switch, les offloads NIC ou la congestion avant de blâmer Proxmox.

Valider la bande passante (vite et sale)

Les migrations sont essentiellement de grandes copies mémoire plus un overhead. Si vous attendez qu’une VM de 16–64 GB migre « vite », vous avez besoin d’un vrai débit. Si vous n’avez pas iperf3, installez-le. C’est un outil de diagnostic, pas un mode de vie.

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

cr0x@server:~$ iperf3 -c 10.10.10.12 -P 4 -t 10
Connecting to host 10.10.10.12, port 5201
[SUM]   0.00-10.00  sec  9.72 GBytes  8.35 Gbits/sec  0             sender
[SUM]   0.00-10.04  sec  9.70 GBytes  8.31 Gbits/sec                  receiver

Décision : Si vous obtenez 1–2 Gbps sur un lien « 10G », la migration semblera bloquée. Réparez le réseau (configuration de bonding, duplex, switch, VLAN, drivers NIC, offloads) avant de tuner QEMU.

Observer le trafic en temps réel pendant la migration

Ne devinez pas si la migration sature un lien. Regardez.

cr0x@server:~$ ip -s link show dev vmbr1 | sed -n '1,12p'
4: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2c:fd:a1:11:22:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    98234982344 81234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    112334455667 92345678      0       0       0       0

Décision : Si les drops s’incrémentent pendant la migration, vous avez trouvé le coupable. Les drops ne sont pas « acceptables si petits ». Ils amplifient les retransmissions et bloquent la progression.

Garder les pare-feux prévisibles

Dans des environnements stricts, le pare-feu Proxmox est utile — jusqu’à ce que quelqu’un l’active sans modéliser le trafic. La migration utilise :

SSH de la source vers la destination pour l’orchestration.
Canaux de migration QEMU (souvent tunnelisés/gérés par Proxmox ; le comportement varie avec la « secure migration »).
Trafic de stockage (Ceph, NFS, iSCSI) qui peut monter en charge pendant et après la migration.

Ce qu’il vous faut : une politique de pare-feu explicite : autorisation nœud-à-nœud sur les réseaux de migration, et strict partout ailleurs. « Drop everything and see what breaks » n’est pas une stratégie de sécurité ; c’est une stratégie pour garder du travail pour le commandant d’incident.

Flags CPU et incompatibilités de type de machine

La compatibilité CPU est la catégorie d’échec la plus nette « stop ». QEMU ne peut pas téléporter des fonctionnalités CPU. La migration exige que la destination présente un CPU compatible avec ce que le système d’exploitation invité a déjà vu.

Le piège courant : `cpu: host` dans un cluster hétérogène

host expose le modèle et les fonctionnalités du CPU de l’hôte au guest. C’est excellent si vous épinglez une VM à un nœud pour toujours ou si vous avez des CPUs véritablement identiques dans le cluster. C’est un coup de fusil sinon.

Sur du matériel hétérogène, choisissez un type CPU de base pour que le guest voie un CPU virtuel cohérent partout. Oui, vous perdrez peut-être quelques instructions. Non, votre application n’en pâtira probablement pas. L’alternative est « la migration ne fonctionne pas », ce qui est une régression très perceptible.

Modèles CPU de base : choisissez-en un et standardisez

Le choix dépend de votre parc :

x86-64-v2 : baseline conservatrice pour une large compatibilité (utile si vous avez des nœuds plus anciens).
x86-64-v3 : baseline plus moderne avec un ensemble d’instructions étendu ; bon si votre parc est récent et homogène.
Modèles QEMU nommés (ex. Haswell, Skylake-Server) : utiles dans des parcs Intel-only, mais peuvent être trop spécifiques.

Votre objectif n’est pas la performance maximale ; c’est la mobilité prévisible. Si vous avez besoin de performance maximale pour une VM spéciale, documentez qu’elle est épinglée et non migrable entre tous les nœuds.

L’alignement du type de machine n’est pas optionnel

Les types de machine QEMU comme pc-q35-8.1 encodent les versions de chipset/périphériques. Si vous avez des QEMU mismatch entre nœuds, vous pouvez rencontrer un état de périphérique incompatible lors de la migration.

Politique opérationnelle : gardez le cluster sur la même version Proxmox autant que possible. Pendant les upgrades, migrez les workloads hors du nœud à upgrader, mettez-le à jour, puis réintégrez les workloads. Ne faites pas « demi-cluster sur la nouvelle version QEMU » et attendez-vous à des migrations à chaud transparentes pour toutes les combinaisons de périphériques.

Passthrough PCI et vGPU : douleur particulière

Si une VM utilise des périphériques hostpci, la migration à chaud est généralement inenvisageable sauf si vous disposez d’un matériel et d’outils très spécifiques. L’état du périphérique ne peut pas être transféré en toute sécurité et la destination peut ne pas avoir le même mapping physique.

cr0x@server:~$ qm config 210 | egrep 'hostpci|machine|cpu'
cpu: host
machine: pc-q35-8.1
hostpci0: 0000:65:00.0,pcie=1

Décision : Traitez les VMs en passthrough comme épinglées. Concevez la maintenance autour d’elles (failover au niveau applicatif, coupures planifiées, ou migration froide).

Une citation fiabilité à garder sur votre bureau

Espérer n’est pas une stratégie. — Rudy Giuliani

Cette phrase est souvent répétée en exploitation parce qu’elle est brutalement applicable : ne « comptez pas » sur la correspondance des CPUs, ne « supposez » pas que le MTU est cohérent, ne « présumez » pas que le stockage est partagé. Vérifiez.

Stockage : partagé, local, Ceph, ZFS et le chemin des données de migration

Le stockage est l’endroit où les migrations meurent lentement. Le réseau et les mismatches CPU tuent la migration rapidement ; une mauvaise conception du stockage la fait traîner, ralentir ou « fonctionner » avec un downtime inacceptable.

Sachez ce que vous migrez : état compute vs état disque

Migration à chaud (stockage partagé) : déplacer RAM+CPU+état périphériques ; les disques restent sur le stockage partagé (Ceph RBD, NFS, iSCSI, etc.). Rapide et prévisible.
Migration à chaud avec disques locaux : déplacer RAM+état et copier les blocs disque sur le réseau. Cela peut être brutal pour les gros disques et les VMs actives.
Migration de stockage : copier des disques entre stockages ; peut être faite en ligne pour certains scénarios, mais reste très I/O intensive.

Si vous n’avez pas de stockage partagé et que vous attendez une migration à chaud rapide, vous ne planifiez pas ; vous auditionnez pour un rapport d’incident.

Vérifier les définitions de stockage et la disponibilité sur les deux nœuds

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
ceph-vm          rbd      active        34.00TiB        13.00TiB        21.00TiB   38.24%
local            dir      active         1.80TiB         0.72TiB         1.08TiB   40.00%
local-lvm        lvmthin  active         1.75TiB         1.62TiB       130.00GiB   92.70%

Ce que cela signifie : local-lvm est dangereusement plein. Si vous tentez une migration de disques locaux, vous risquez de manquer d’espace en cours de copie.

Décision : Si les pools thin dépassent ~85–90 %, considérez cela comme un risque d’incident. Libérez de l’espace ou étendez avant de migrer des disques.

Spécificités ZFS : ZFS local n’est pas un stockage partagé

ZFS est excellent. Un ZFS local reste local. La migration à chaud exige soit un stockage partagé soit un mécanisme de déplacement des disques.

Si vous utilisez ZFS sur chaque nœud, le bon modèle mental est : vous pouvez utiliser la réplication ZFS (zfs send/receive) pour pré-stager les disques, puis faire une bascule contrôlée. Ce n’est pas la même chose que « migrer à chaud n’importe quand ».

Spécificités Ceph : réseaux séparés, modes de défaillance différents

Ceph utilise typiquement un réseau « public » (clients) et parfois un réseau « cluster » (réplication/backfill). Le trafic de migration est séparé. Mais opérationnellement ils se percutent parce que la migration augmente l’I/O et la charge CPU, révélant le vrai comportement d’un cluster Ceph marginal.

Avant des événements de migration importants, rendez Ceph ennuyeux :

Tous les OSDs up/in.
Pas de storms de deep-scrub.
Pas de recovery/backfill surchargés.
Latence dans les limites normales.

Migration de disques locaux : décidez si ça vaut le coup

Si vous devez migrer des disques locaux en ligne, quantifiez au moins :

Taille du disque (allouée et réelle).
Bande passante disponible entre nœuds.
Taux d’écriture de la VM (overhead de copy-on-write).
Tolérance métier à la dégradation des performances pendant la copie.

Dans beaucoup d’environnements production, la bonne décision est : planifiez une fenêtre de maintenance et faites une migration froide, ou redessinez le stockage pour un accès partagé.

Erreurs courantes : symptôme → cause racine → correction

1) « Migration failed: can’t connect to destination »

Symptôme : Échec en quelques secondes, code SSH 255 dans les journaux.
Cause racine : Mismatch de clé SSH, clés d’hôte modifiées, pare-feu bloquant SSH, mauvaise IP/route.
Correction : Validez ssh -o BatchMode=yes root@dest depuis la source sur l’IP de migration. Corrigez le routage/hosts/pare-feu ; rétablissez la confiance SSH du cluster si nécessaire.

2) Migration bloquée à 0 % ou qui progresse à peine

Symptôme : La progression n’avance pas ; l’UI affiche une tâche en cours longtemps.
Cause racine : Mauvais chemin réseau (utilisation du mgmt 1G au lieu du 10G), problèmes MTU provoquant retransmissions, perte de paquets, ou états de suivi du pare-feu posant problème.
Correction : Confirmez ip route get et testez le débit (iperf3). Validez les pings jumbo avec -M do. Corrigez MTU, routes ou désactivez les offloads défaillants.

3) « CPU feature mismatch » / « host doesn’t support requested features »

Symptôme : Échec rapide avec erreurs liées au CPU ; souvent visible uniquement dans les logs QEMU.
Cause racine : VM en cpu: host ou modèle CPU trop spécifique ; la destination n’a pas le flag requis.
Correction : Réglez le CPU de la VM sur une baseline du cluster. Gardez les nœuds sur des familles matérielles cohérentes quand c’est possible.

4) « storage ‘local-lvm’ is not available on node … »

Symptôme : Migration bloquée avant de commencer ; le journal de tâche mentionne un stockage indisponible.
Cause racine : Disque VM sur stockage local au nœud ; le nœud cible n’a pas cet ID de stockage (par design).
Correction : Déplacez les disques vers un stockage partagé d’abord, migrez avec disques locaux volontairement, ou ajustez les définitions de stockage si vous aviez l’intention d’un stockage partagé.

5) Migration réussit mais la VM reste trop longtemps en pause (« live » ressenti hors-ligne)

Symptôme : Migration aboutit mais le downtime dure plusieurs secondes ; l’application subit des timeouts.
Cause racine : La VM salit la mémoire trop vite ; le pré-copy ne converge pas ; le débit réseau est insuffisant ; latence IO disque élevée (surtout sur du stockage partagé sous charge).
Correction : Migrez durant une période d’activité moindre, envisagez d’ajuster les paramètres de migration (compression/postcopy) avec précaution, et corrigez la latence stockage sous-jacente.

6) Migration échoue seulement pour certaines VMs (d’autres migrent bien)

Symptôme : Certaines VMs migrent ; d’autres échouent systématiquement.
Cause racine : Ces VMs ont des périphériques passthrough, des flags CPU spéciaux, des différences de huge pages, ou des combinaisons machine/périphériques spécifiques.
Correction : Normalisez les profils matériels des VMs. Documentez les exceptions (VM épinglées). Ne prétendez pas que chaque workload est mobile.

7) Migration casse juste après l’activation du pare-feu Proxmox

Symptôme : Des migrations auparavant fonctionnelles échouent désormais ; d’autres trafics peuvent rester OK.
Cause racine : Manque d’autorisations nœud-à-nœud pour le réseau de migration ou services associés ; règles stateful qui coupent les flux longue durée.
Correction : Implémentez des allowlists explicites entre nœuds sur les réseaux de migration. Testez les migrations lors du déploiement des règles de pare-feu.

Trois mini-récits d’entreprise tirés du terrain

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

Une entreprise avait deux nœuds Proxmox qui « semblaient identiques » dans le rack : même châssis, même fournisseur, même nombre de NICs. Quelqu’un les avait commandés six mois d’écart et a supposé que « même modèle » signifiait « même CPU ». Ce n’était pas le cas. L’un est arrivé avec un stepping plus récent et une baseline microcode différente, et l’autre était une famille CPU différente à cause de substitutions chaîne d’approvisionnement.

Ils avaient configuré la plupart des VMs en cpu: host pour la performance. Ça a marché des mois parce qu’ils n’avaient jamais eu à migrer les VMs lourdes — jusqu’à ce qu’une mise à jour firmware sur le nœud A nécessite un reboot et qu’ils tentent d’évacuer les workloads. La première migration a échoué instantanément. La deuxième aussi. Ils se sont retrouvés avec un nœud planifié pour maintenance et un nœud incapable d’accepter les workloads.

Lors de l’appel d’incident, l’hypothèse que « migration à chaud = bouton » a fait perdre du temps. Les gens ont traqué la latence Ceph, puis les règles de pare-feu, puis les paramètres HA. L’indice était dans qm config depuis le début : cpu: host. Un rapide lscpu a clos le mystère.

La correction n’a pas été héroïque. Ils ont changé les modèles CPU des VMs pour une baseline supportée sur les deux nœuds, testé la migration sur une VM, puis propagé le changement au parc. L’impact perf a été négligeable. La leçon est restée : si vous voulez de la mobilité, il faut la budgéter dans l’exposition des features CPU.

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

Une autre organisation s’est amusée avec les jumbo frames. Ils ont activé MTU 9000 sur les hôtes parce que « 10G, c’est cher et on doit optimiser ». Mais l’équipe réseau n’a activé le jumbo que sur certains ports de switch. Quelques trunks VLAN restaient en 1500. Personne n’avait un diagramme end-to-end complet, parce que bien sûr personne ne l’avait.

Le trafic normal avait l’air OK. Le ping de management fonctionnait. SSH fonctionnait. Les petits paquets s’en fichent. Puis ils ont essayé de migrer une VM gourmande en mémoire. Elle partait, transférait un peu, puis se bloquait et finissait par échouer. Parfois ça réussissait mais prenait une éternité. L’équipe a blâmé Proxmox, puis QEMU, puis Ceph, puis ses choix de vie.

La percée est venue du test pas glamour : un ping large avec « do not fragment ». Il a échoué. Pas « peut-être ». Échoué. Le réseau de migration avait un chemin qui silently black-holed les paquets jumbo, causant fragmentation, retransmissions et débit terrible.

Ils ont corrigé en standardisant le MTU sur tout le chemin de migration. Et le twist : après la correction, ils sont finalement revenus à MTU 1500. Pourquoi ? Simplicité opérationnelle. Ils ont choisi une performance prévisible plutôt qu’une optimisation théorique. C’est ce que vous apprennent les systèmes en production : le réseau le plus rapide est celui qui fonctionne tous les jours.

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

Une équipe considérait la migration à chaud comme une fonctionnalité à tester continuellement, pas comme un bouton découvert lors d’un incident. Chaque semaine, ils réalisaient un petit jeu de migrations : une VM Linux, une VM Windows, une VM « busy », et une VM UEFI. Ils consignaient les résultats et gardaient une baseline de durée de migration et de downtime.

C’était ennuyeux. Personne n’a été promu pour « tout fonctionne encore ». Mais la pratique a payé quand une mise à jour de firmware de switch a introduit une perte de paquets intermittente sur un VLAN spécifique. Le premier signe n’a pas été des plaintes utilisateurs — c’était le test hebdomadaire de migration montrant un ralentissement soudain et des échecs occasionnels.

Parce qu’ils avaient une baseline, ils ont pu dire « ça a changé » et le prouver avec des données : perte ping, chute iperf, et doublement de la durée de migration. L’équipe réseau l’a pris au sérieux car les preuves étaient serrées et reproductibles.

Ils ont rollback le firmware, restauré la baseline, puis re-upgradé avec une validation appropriée. Pas d’incident majeur. La pratique ennuyeuse n’a pas juste « sauvé la journée » ; elle a évité une urgence à 2h du matin impliquant trop de personnes et pas assez de café.

Checklists / plan étape par étape

Checklist A : Avant de tenter une migration à chaud en production

Santé du cluster : pvecm status doit indiquer qu’il est quorate. Si non, stoppez.
Alignement des versions : pveversion -v cohérent entre nœuds (surtout pve-qemu-kvm).
Réseau de migration : Décidez si vous en utilisez un. Si oui, configurez-le et vérifiez-le avec des pings jumbo.
Confiance SSH : Node-to-node ssh -o BatchMode=yes fonctionne sur les IPs de migration.
Politique modèle CPU : Modèle CPU baseline pour le parc migrable décidé ; évitez cpu: host sauf si les nœuds sont réellement homogènes.
Politique stockage : Stockage partagé pour les VMs migrables, ou plan documenté pour les disques locaux.
Liste d’exceptions : VMs en passthrough/vGPU/edge-case documentées comme épinglées.
Capacité : La cible a de la mémoire et des ressources CPU suffisantes pour la VM et l’overhead de migration.

Checklist B : Quand une migration échoue (plan incident 15 minutes)

Récupérez l’erreur réelle : vérifiez journalctl -u pvedaemon et les journaux de tâches.
Classifiez l’échec : connect/auth vs compat CPU vs gating stockage vs lenteur/convergence.
Sanité réseau : ip route get, ping -M do -s ..., iperf3 rapide si autorisé.
Sanité CPU : qm config VMID pour le type CPU ; lscpu pour comparer les nœuds.
Sanité stockage : qm config pour localiser les disques ; pvesm status et (si Ceph) ceph -s.
Retentez une fois après un correctif ciblé. Pas cinq fois. Les tentatives répétées créent du bruit, des contentions de verrous et parfois un état partiel.
Escaladez avec des preuves : fournissez la ligne d’erreur exacte et les sorties de commandes. « La migration a cassé » n’est pas un ticket, c’est une humeur.

Checklist C : Après correction (pour que ça reste corrigé)

Standardiser les modèles CPU des VMs migrables sur le parc.
Standardiser le MTU sur les réseaux de migration, ou se standardiser sur 1500.
Planifier des migrations de test régulières et enregistrer durée/downtime.
Documenter les VMs épinglées et pourquoi elles le sont.
Maintenir l’alignement des versions des nœuds ; éviter les clusters mixtes de longue durée.

FAQ

1) Ai-je besoin d’un stockage partagé pour la migration à chaud ?

Si vous voulez une migration à chaud rapide et fiable : oui, en pratique. Sans stockage partagé vous pouvez migrer des disques locaux, mais vous faites alors une grosse copie en ligne et appelez ça « live ». Ça peut aller pour des petits disques et des VMs calmes, pas pour des bases de données de production très actives.

2) Pourquoi la migration fonctionne pour certaines VMs mais pas d’autres ?

Profils matériels virtuels différents. CPU réglé sur host, passthrough de périphérique, types de machine différents, ou args QEMU spécifiques peuvent rendre une VM non migrable même si le cluster est sain.

3) `cpu: host` est-il toujours mauvais ?

Non. C’est acceptable pour des VMs « performance d’abord » sur un nœud unique ou pour des clusters véritablement identiques. C’est problématique si vous supposez une uniformité matérielle que vous n’appliquez pas. Si vous voulez de la mobilité, choisissez un modèle CPU baseline et respectez-le.

4) Quelle est la façon la plus rapide de détecter un problème MTU ?

Un ping large en « do not fragment » sur l’IP de migration : ping -M do -s 8972 target pour MTU 9000. Si ça échoue, le jumbo ne fonctionne pas end-to-end. Corrigez-le ou cessez d’utiliser le jumbo.

5) Pourquoi la migration reste bloquée autour d’un certain pourcentage ?

C’est souvent que le pré-copy ne converge pas à cause d’un taux de pages sales élevé, ou que le débit réseau s’effondre à cause de perte/retransmissions. Vérifiez qm monitor VMID --cmd "info migrate" et cherchez le taux de pages sales et le statut de migration.

6) Puis-je migrer entre nœuds sur des versions Proxmox/QEMU différentes ?

Parfois, mais ce n’est pas une pratique à adopter systématiquement. La compatibilité de migration est meilleure quand les versions QEMU et les types de machine sont alignés. Pour les upgrades rolling, évacuez un nœud, mettez-le à jour, puis réintroduisez-le — minimisez l’opération en version mixte.

7) Comment savoir si ma migration utilise la mauvaise NIC ?

ip route get <destination migration IP> vous indique quelle interface et quelle IP source seront utilisées. Si ce n’est pas votre bridge/NIC de migration, corrigez les routes ou la configuration de réseau de migration.

8) Les VMs Windows et l’UEFI : risques spéciaux de migration ?

L’UEFI est généralement OK si les deux nœuds le supportent et que la config VM est cohérente. Les problèmes viennent plutôt des différences de périphériques, des mismatches de type de machine ou des changements de layout de stockage. Gardez le firmware/type de machine cohérents et évitez les modifications matérielles ad hoc.

9) Dois-je activer la compression de migration ?

Seulement après avoir mesuré un goulot réseau et si vous avez de la marge CPU. La compression échange CPU contre bande passante. Sur des hôtes CPU-bound, elle aggrave tout, y compris la charge que vous tentez de ne pas perturber.

10) J’ai Ceph et la migration échoue quand même ?

Alors l’échec n’est probablement pas « disponibilité disque partagé » mais réseau/CPU/pare-feu ou santé Ceph sous charge. Vérifiez ceph -s et surveillez les slow ops. Ceph peut être « up » et pourtant opérationnellement misérable.

Conclusion : prochaines étapes pour rester sain d’esprit

Quand la migration à chaud Proxmox échoue, ne la traitez pas comme un événement mystique. C’est un ensemble de prérequis prévisibles : chemin réseau stable, exposition CPU compatible, et architecture de stockage qui correspond à vos attentes.

Prochaines étapes qui réduisent réellement les incidents futurs :

Choisir une politique CPU pour les VMs (modèle baseline pour les workloads migrables) et l’appliquer.
Rendre le réseau de migration ennuyeux : MTU cohérent end-to-end, débit vérifié, autorisations pare-feu explicites.
Arrêter de prétendre que les disques locaux sont partagés. Si vous avez besoin de mobilité, concevez un stockage partagé ou un processus de cutover basé sur la réplication.
Effectuer des migrations test régulières et garder une baseline. Si vous ne testez qu’en cas d’incident, vous faites de l’ingénierie du chaos sur vos clients.

Si vous ne faites rien d’autre : vérifiez le chemin IP de migration et cessez d’utiliser cpu: host dans des clusters avec matériel mixte. Ces deux changements éliminent une quantité surprenante de douleur.