Proxmox “migration aborted”: causas comunes y ruta de reparación

Qué significa realmente “migration aborted” en Proxmox

En Proxmox VE, las migraciones vienen en varias modalidades:

• Live migration (estado de memoria de QEMU se mueve mientras la VM está en ejecución). Normalmente requiere almacenamiento compartido o estrategias de replicación que hagan el disco disponible en el destino.
• Offline migration (la VM está detenida; se mueven la configuración y los discos). Más lenta, a menudo más simple y a veces la única elección sensata.
• Storage migration (mover discos entre backends de almacenamiento, opcionalmente sin mover el nodo de cómputo).
• Enfoques asistidos por replicación (replicación ZFS o Ceph/RBD donde la localización y las reglas de consistencia de los discos difieren).

“migration aborted” no es un único error. Es un estado de fallo de alto nivel para un flujo de trabajo de múltiples pasos:

1. Comprobaciones del clúster (permisos, configuración, quorum, preparación del nodo destino).
2. Comprobaciones de conectividad (SSH y/o red de migración).
3. Comprobaciones de almacenamiento (¿existe el disco en el destino? ¿es compartido? ¿hay espacio suficiente? ¿ID de almacenamiento correcta?).
4. Inicio por parte de QEMU del canal de migración (sincronización pre-copy de memoria, seguimiento de páginas sucias).
5. Conmutación final / limpieza (la parte que duele cuando falla).

Cuando aborta, Proxmox puede ya haber hecho algo de trabajo: creado una configuración transitoria en el destino, reservado espacio, iniciado un proceso receptor o copiado discos parcialmente. Tu tarea es determinar en qué estado estás ahora, no en cuál esperabas estar.

Idea parafraseada de James Hamilton (ingeniería de confiabilidad en AWS): “Opera minimizando la variabilidad y aprendiendo de cada fallo.” No es poético. Es correcto.

Broma corta #1: La migración en vivo es como mudarse de apartamento mientras sigues cocinando la cena: es posible, pero las probabilidades de derramar sopa no son nulas.

Guion rápido de diagnóstico (revisa esto primero)

Si solo tienes cinco minutos antes de que alguien empiece a “ayudar”, haz esto en orden. El objetivo es identificar si el cuello de botella es estado del clúster, red, almacenamiento o restricciones del invitado.

1) Confirma la salud del clúster y la disponibilidad del nodo destino

• ¿Hay quorum? ¿Está corosync con flapping?
• ¿El nodo destino está en un estado limpio y no está fenceado ni parcialmente desconectado?
• ¿La VM está bloqueada?

2) Extrae el registro de la tarea y luego los registros del nodo

• El registro de tareas de Proxmox da la primera línea de error significativa.
• Los registros del sistema te dicen la razón real (fallo de autenticación, denegación de permisos, reinicio de conexión, OOM, disco lleno).

3) Identifica la topología de almacenamiento y si coincide con el tipo de migración

• El almacenamiento compartido (Ceph, NFS, iSCSI, etc.) facilita la migración de cómputo.
• El almacenamiento local implica mover/replicar discos y restricciones de ancho de banda.
• Los datasets ZFS, LVM thin y qcow2 se comportan distinto durante copia y manejo de snapshots.

4) Revisa la ruta de la red de migración

• Desajuste de MTU, enrutamiento asimétrico, reglas de firewall o un bond muy cargado pueden matar una migración.
• Picos de latencia pueden alargar la pre-copy hasta que expire o el operador aborte.

5) Verifica bloqueos desde el invitado

• Huge pages, dispositivos en passthrough, CD-ROM/ISO locales o flags de CPU no soportados pueden bloquear o degradar la migración.
• El ballooning de memoria y la tasa de páginas sucias pueden hacer que una migración en vivo “nunca termine”.

Una vez que clasificas el problema, dejas de malgastar tiempo. Eliges la ruta de reparación y la sigues hasta completar. Esa es la diferencia entre operadores y clicadores de botones.

Hechos interesantes y contexto (por qué falla así)

• Hecho 1: Proxmox VE usa Corosync para la pertenencia al clúster y pmxcfs (un sistema de archivos FUSE) para distribuir la configuración bajo /etc/pve. Si pmxcfs está inestable, las migraciones se vuelven extrañas rápidamente.
• Hecho 2: La migración en vivo de QEMU se basa en un algoritmo pre-copy: envía páginas de memoria mientras la VM corre y luego reintenta las páginas “sucias”. Altas tasas de escritura pueden impedir la convergencia.
• Hecho 3: El canal de migración no es “solo SSH”. Proxmox usa SSH para orquestación, pero QEMU abre su propio stream de migración (a menudo en una red dedicada) que puede estar bloqueado aunque SSH funcione.
• Hecho 4: Las configuraciones de VM en Proxmox se almacenan como archivos de texto en /etc/pve/qemu-server/. Una configuración parcialmente escrita o un lock obsoleto puede descarrilar los reintentos.
• Hecho 5: Las VMs con respaldos Ceph (RBD) normalmente migran el estado de cómputo sin copiar discos, pero dependes de la salud de Ceph, permisos cliente y las rutas de red hacia las redes públicas y de clúster de Ceph.
• Hecho 6: La replicación ZFS en Proxmox se basa en snapshots. Es fiable, pero no es magia: snapshots faltantes, renombres de datasets o comandos manuales “útiles” pueden romper la cadena.
• Hecho 7: El mecanismo de “lock” de VM existe para evitar operaciones concurrentes. Si una migración aborta en el momento equivocado, el lock puede quedarse y bloquear todo hasta que se limpie.
• Hecho 8: Los desajustes de MTU aparecen comúnmente como “funciona para transferencias pequeñas, falla para las grandes”. Las migraciones son transferencias grandes.

Causas raíz comunes, con rutas de reparación

A) Problemas de estado del clúster (quorum, corosync, pmxcfs)

Cómo se manifiesta: La migración falla al instante, a veces con errores genéricos; la GUI puede mostrar nodos “?”; las configuraciones no aparecen en todos los nodos; tareas fallan con “no quorum” o no se puede escribir bajo /etc/pve.

Qué está pasando realmente: Proxmox necesita membresía consistente del clúster para mover recursos con seguridad. Sin quorum, se niega a hacer cambios. Si pmxcfs está degradado, incluso leer/escribir configuraciones de VM puede fallar.

Ruta de reparación: Estabiliza el clúster primero. Si tu clúster no está saludable, no migres. Arregla los enlaces de corosync, el quorum y la sincronización horaria. Luego reintenta la migración.

B) Fallos de SSH y autenticación (la capa de orquestación)

Cómo se manifiesta: “migration aborted: ssh error” o fallos tempranos en el registro de la tarea. A veces es intermitente—porque nada dice “empresa” como rotar claves a mitad del día.

Qué está pasando realmente: Proxmox usa SSH entre nodos para coordinación y ciertas transferencias de archivos. Claves de host incorrectas, known_hosts roto, permisos o un comando forzado en authorized_keys pueden matarlo.

Ruta de reparación: Verifica acceso SSH root entre nodos (como Proxmox espera), corrige mismatches de host key, confirma que sshd permite lo necesario y reintenta.

C) Problemas en la ruta de la red de migración (firewall, MTU, enrutamiento, congestión)

Cómo se manifiesta: La migración inicia y luego aborta; los registros muestran “connection reset”, timeouts o errores de socket de migración de QEMU. A veces llega al 90% y luego cae. Eso es una pista: la coordinación inicial funcionó; el plano de datos no.

Qué está pasando realmente: El stream de migración de QEMU es sensible a la pérdida de paquetes y problemas de path MTU. Firewalls pueden permitir SSH pero bloquear el rango de puertos de migración. O estás haciendo migración sobre una red de producción saturada que también transporta tráfico de Ceph, backups y el rsync “temporal” de un colega.

Ruta de reparación: Confirma MTU extremo a extremo, asegura que las reglas de firewall permitan el tráfico de migración, pon la migración en una interfaz dedicada si puedes y evita saturar el enlace.

D) Desajuste de almacenamiento: realidad compartida vs local

Cómo se manifiesta: “storage ‘local-lvm’ not found on target”, “volume does not exist”, “cannot open disk image” o la migración aborta después de copiar algunos discos.

Qué está pasando realmente: La configuración de la VM referencia IDs de almacenamiento. Si el nodo destino no tiene la misma definición de almacenamiento (mismo ID, tipo compatible), Proxmox no puede colocar el disco. Para almacenamiento local, debes mover los discos (storage migration) o replicarlos (replicación ZFS, backups/restore, etc.).

Ruta de reparación: Alinea las definiciones de almacenamiento entre nodos, confirma espacio, verifica volúmenes y elige el método de migración correcto (mover solo cómputo vs offline con transferencia de discos).

E) Fallos al copiar discos (espacio, permisos, almacenamiento lento, rarezas de snapshot)

Cómo se manifiesta: rsync o qemu-img copy falla; “No space left on device”; “Input/output error”; la migración es dolorosamente lenta y luego aborta.

Qué está pasando realmente: La migración de discos es una carga para el almacenamiento: metadata-heavy para qcow2, secuencial para raw y castigadora para volúmenes thin-provisioned fragmentados. Además: si el almacenamiento subyacente está degradado (errores ZFS, recuperación de Ceph), lo descubrirás durante la migración.

Ruta de reparación: Verifica espacio, salud del almacenamiento y errores de I/O. Si el almacenamiento está enfermo, deja de migrar y arregla el almacenamiento. Si solo está lento, planifica downtime y haz una migración offline.

F) Restricciones del invitado (modelo CPU, passthrough, hugepages, TPM, medios locales)

Cómo se manifiesta: La migración aborta con mensajes sobre dispositivos, incompatibilidad de CPU o “cannot migrate with device”. A veces aborta después de que QEMU inicia porque el destino no puede recrear el mismo hardware virtual.

Qué está pasando realmente: La migración en vivo requiere que el destino emule una CPU y un conjunto de dispositivos compatibles. El passthrough PCI, algunos dispositivos USB y ciertas configuraciones son hostiles a la migración. El estado de TPM también puede complicar las cosas según la configuración.

Ruta de reparación: Usa una línea base de CPU compatible (p. ej., x86-64-v2/v3), evita passthrough para VMs migrables, desmonta medios locales y elige migración offline cuando sea necesario.

G) Locks, restos y estado medio-migrado

Cómo se manifiesta: La VM aparece como bloqueada; operaciones posteriores dicen “resource is locked”; la configuración existe en ambos nodos; discos existen en dos lugares con nombres similares.

Qué está pasando realmente: Una migración es una transacción con pasos de limpieza. Si aborta, la limpieza puede no ejecutarse. Puedes terminar con un lock que bloquea futuras operaciones y artefactos en el destino que confunden el próximo intento.

Ruta de reparación: Identifica dónde está realmente corriendo la VM, luego elimina locks obsoletos y borra solo los artefactos que puedas probar que es seguro borrar. “Probar” significa: comprueba referencias de volumen, VMIDs y contenido de almacenamiento—dos veces.

Tareas prácticas: comandos, qué significa la salida y la decisión que tomas

Estos son los pasos que uso en producción. Cada tarea incluye un comando, cómo se ve lo “bueno” y lo “malo”, y qué decides a continuación. Ejecútalos en los nodos origen y destino según corresponda.

Task 1: Obtén el fallo exacto del registro de tareas de 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

Significado: El registro de la tarea normalmente contiene una línea que importa. Aquí es un desajuste de ID de almacenamiento.

Decisión: Deja de depurar la red. Arregla las definiciones de almacenamiento o haz una storage migration/backup-restore.

Task 2: Verifica quorum y membresía del clúster

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

Significado: Quorate: Yes significa que las escrituras de clúster están permitidas. Si es “No”, las migraciones son una mala idea.

Decisión: Si no hay quorum: arregla la red/tiempo del clúster o restaura el quorum. No “forces” migraciones como solución a menos que disfrutes el split-brain sorpresa.

Task 3: Revisa la salud del enlace de 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

Significado: Los enlaces deberían ser OK. Enlaces con flapping causan retrasos en pmxcfs y fallos “aleatorios”.

Decisión: Si un enlace está caído: arregla la red antes de migrar. La estabilidad de corosync no es opcional.

Task 4: Confirma que pmxcfs está montado y responde

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

Significado: Si /etc/pve no está montado, no estás en un estado de clúster saludable.

Decisión: Arregla pmxcfs/corosync antes que nada. Migrar con un filesystem de configuración roto es la manera de ganarte trabajo el fin de semana.

Task 5: Comprueba si la VM está bloqueada (y por qué)

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

Significado: Un lock indica una operación en curso o una operación abortada que no limpió.

Decisión: No elimines locks a ciegas. Primero determina dónde está realmente corriendo la VM (Task 6). Si está estable y vas a limpiar, entonces puedes desbloquear.

Task 6: Determina dónde está realmente corriendo la VM

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

Significado: La vista de recursos del clúster debería mostrar un nodo propietario. Si muestra “unknown” o cambia, tu clúster es inestable.

Decisión: Si la VM corre en el origen, trata los artefactos del destino como sospechosos. Si está en el destino, deja de intentar “re-migrar” hasta alinear configs y discos.

Task 7: Limpiar un lock obsoleto (solo después de verificar la realidad)

cr0x@server:~$ qm unlock 101

Significado: Unlock remueve el lock de operación, no el problema subyacente.

Decisión: Si desbloquear es necesario para proceder con la limpieza (borrar volúmenes parciales, reintentar la migración), hazlo. Si desbloqueas para “hacer desaparecer el error”, para y vuelve a leer el registro de la tarea.

Task 8: Valida que las definiciones de almacenamiento coincidan entre nodos

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%

Significado: La columna Name (ID de almacenamiento) debe existir tanto en origen como en destino para los discos de la VM. Mismo ID, backend compatible.

Decisión: Si local-lvm existe en origen pero no en destino: o lo defines en destino (si corresponde) o mueves los discos a un almacenamiento compartido primero.

Task 9: Comprueba los volúmenes de disco referenciados por 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

Significado: El almacenamiento mixto es común. También es una trampa común de migración: un disco es compartido y el otro no.

Decisión: O mueves scsi0 a almacenamiento compartido (storage migration) o aceptas una migración offline con transferencia de discos.

Task 10: Verifica espacio libre donde aterrizaría el disco

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)

Significado: Para thin pools, vigila Data% en el pool y en el LV específico. Un uso alto del pool significa que la próxima escritura podría fallar a mitad de migración.

Decisión: Si el uso del pool es alto: libera espacio, extiende el pool o no migres aún. “Disco lleno durante migración” es un generador clásico de estados parciales.

Task 11: Revisa la salud de Ceph antes de culpar a 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

Significado: La migración en vivo con Ceph depende de I/O estable en Ceph. Si Ceph está degradado, tu VM puede estar bien, pero las migraciones y reinicios pueden convertirse en ruleta.

Decisión: Si Ceph no está saludable: arregla Ceph primero y luego migra. La migración no es el lugar para descubrir que estabas a un OSD de un día malo.

Task 12: Valida la red de migración y el MTU (el asesino silencioso)

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

Significado: Si se configuran jumbo frames, deben funcionar extremo a extremo. Si ves “Frag needed” o pérdida de paquetes, espera problemas en la migración.

Decisión: Si el MTU no coincide: o arreglas la red o bajas el MTU a 1500 de forma consistente. MTUs mixtos son teatro de rendimiento con alto índice de bajas.

Task 13: Revisa el estado del firewall y las reglas (SSH funcionando no es prueba)

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

Significado: Si el firewall de Proxmox está habilitado, asegúrate de que el tráfico de migración esté permitido en las interfaces usadas. La GUI puede mostrarlo, pero la verdad por CLI es más rápida durante incidentes.

Decisión: Si las reglas bloquean puertos de migración: corrígelas. No “desactives temporalmente el firewall” a menos que también disfrutes escribir informes de incidente.

Task 14: Busca errores de migración del lado de QEMU en 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'

Significado: Este tipo de bloqueador es “obvio en retrospectiva” y el error de alto nivel lo oculta.

Decisión: Desmonta el ISO local o asegúrate de que la misma ruta/almacenamiento ISO exista en el destino.

Task 15: Valida configuraciones de compatibilidad de 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

Significado: cpu: host es rápido pero te ata a las características de la CPU del origen. Migrar a un nodo con microarquitectura diferente puede fallar o forzar un reinicio.

Decisión: Para clústeres con CPUs mixtas, estandariza un modelo de CPU base para VMs migrables.

Task 16: Inspecciona el estado de replicación (usuarios de replicación ZFS)

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

Significado: Si la replicación está desactualizada o falla, migraciones que asumen “disco ya presente” abortarán o iniciarán la versión incorrecta del disco.

Decisión: Arregla errores de replicación primero; no uses la migración como herramienta para depurar replicación.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “storage not available on target”

Causa raíz: El ID de almacenamiento referenciado en la config de la VM no existe en el destino, o existe pero es distinto (dir vs lvmthin vs zfs).

Solución: Alinea definiciones de almacenamiento entre nodos (pvesm status), o migra los discos a almacenamiento compartido primero, o realiza migración offline con movimiento de discos.

2) Síntoma: Migración aborta tras iniciar, con “connection reset”

Causa raíz: Desajuste MTU, firewall bloqueando el stream de migración o enlace congestionado que hace que QEMU venza el tiempo.

Solución: Prueba MTU con ping -M do, verifica reglas de firewall, mueve migraciones a una red dedicada o reduce tráfico durante la ventana.

3) Síntoma: VM permanece bloqueada tras el fallo

Causa raíz: La limpieza no se completó; el lock se mantuvo en la configuración.

Solución: Verifica dónde corre la VM (pvesh get /cluster/resources), luego qm unlock <vmid>. Limpia discos parciales solo después de probar que no están en uso.

4) Síntoma: “no quorum” o el clúster muestra nodos como unknown

Causa raíz: Fallo en enlace de corosync, red partida o problemas de sincronización horaria que llevan a inestabilidad de membresía.

Solución: Restaura la comunicación de corosync. No migres hasta que pvecm status muestre quorum y estabilidad.

5) Síntoma: La migración falla solo para algunas VMs

Causa raíz: Esas VMs usan cpu: host, dispositivos en passthrough, ISOs locales o modelos de dispositivo especiales incompatibles con el destino.

Solución: Estandariza modelos de CPU, quita hardware no migrable de esos invitados, asegura accesibilidad de medios en ambos nodos o realiza migración offline.

6) Síntoma: Migración “cuelga” en alto porcentaje por mucho tiempo

Causa raíz: La tasa de páginas sucias excede el ancho de banda de migración; la memoria cambia más rápido de lo que puede copiarse.

Solución: Reduce la actividad de escritura del invitado (temporalmente), aumenta ancho de banda de migración o cambia a migración offline para esa ventana de workload.

7) Síntoma: Migración aborta y el destino tiene volúmenes residuales

Causa raíz: La copia de disco se completó parcialmente; el destino ahora tiene volúmenes huérfanos o datasets parciales.

Solución: Identifica volúmenes pertenecientes al VMID, confirma que no están referenciados por ninguna config de VM y elimínalos. Si hay dudas, consérvalos y cambia el plan a restaurar desde backup/replicación.

Broma corta #2: “Simplemente reinténtalo” no es una estrategia; es cómo conviertes un error en un evento recurrente de calendario.

Tres mini-historias del mundo corporativo (anonimizadas)

Mini-historia 1: El incidente causado por una suposición equivocada

Tenían un clúster Proxmox de dos nodos que soportaba herramientas internas. Nada sofisticado: un par de docenas de VMs, local LVM-thin en cada nodo y backups nocturnos. Alguien pidió mantenimiento en el nodo A, así que el ingeniero on-call decidió “simplemente migrar en vivo todo al nodo B”.

La suposición fue simple: “La migración es mover cómputo”. En otro entorno habían usado migración en vivo con almacenamiento compartido y olvidaron que en este clúster el disco vivía localmente. La primera migración lanzó “migration aborted” y el ingeniero lo interpretó como “un fallo de red” y lo intentó de nuevo. Y otra vez.

Cada intento creó artefactos parciales de disco en el destino. LVM-thin es eficiente hasta que deja de serlo: la metadata creció, el thin pool empezó a llenarse y VMs no relacionadas en el nodo B empezaron a tener pausas de I/O. El problema de migración se convirtió en un problema de plataforma.

Eventualmente pararon y miraron la config de la VM. local-lvm no era un almacenamiento compartido; eran dos islas separadas con el mismo nombre en la conversación humana, no en la realidad de Proxmox. La solución fue aburrida: dejar de hacer migraciones en vivo, planear una migración offline con movimiento de almacenamiento o restaurar desde backup en el otro nodo.

La lección real fue operacional: la migración es primero una decisión de topología de almacenamiento y luego una decisión de cómputo. Si no sabes dónde están los bloques, no sabes qué estás moviendo.

Mini-historia 2: La optimización que salió mal

Otra compañía construyó una red “vía rápida” para migraciones Proxmox y tráfico de Ceph. Jumbo frames activados, bonding configurado, VLAN separada, todo. Los gráficos se veían bien. Los operadores se sentían bien. Aquí es donde se complica la trama.

Un switch en la ruta tenía un puerto configurado con MTU 1500 debido a una plantilla errónea. La mayor parte del tráfico funcionaba. SSH funcionaba. El clúster Ceph funcionaba mayormente porque era resiliente y porque paquetes pequeños eran comunes. Pero las migraciones en vivo fallaban intermitentemente a mitad de stream con errores de socket vagos.

Los ingenieros persiguieron fantasmas: versiones de Proxmox, upgrades de kernel, opciones de QEMU. Algunos intentaron “simplemente desactivar el firewall.” No ayudó. Incluso alguien culpó a una carga de trabajo específica porque “ensucia la memoria demasiado rápido.” Eso fue parcialmente cierto, pero no la causa raíz.

La pista llegó de una simple sonda MTU. ICMP grande con “do not fragment” fallaba a través de la red de migración. Arreglar el MTU en ese puerto del switch convirtió las migraciones de “cara o cruz” a aburridas.

Lo que salió mal no fueron los jumbo frames; fue el uso inconsistente de jumbo frames. Las optimizaciones que requieren consistencia perfecta en la infraestructura deben tratarse como cambios de producción, no como “sazonado de red”.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo que ejecutaba Proxmox con generaciones de CPU mixtas estandarizó los tipos de CPU de las VMs desde temprano. No usaron cpu: host para nada que pudiera migrar. Eligieron un modelo de CPU base y lo documentaron. Les costó algo de rendimiento pico. Les salvó repetidamente.

Una tarde un nodo empezó a lanzar errores ECC de memoria. El hardware estaba degradado pero todavía operativo. Necesitaban evacuar VMs rápidamente para evitar el tipo de corrupción que solo notas durante auditorías trimestrales. La migración en vivo era el plan y tenía que funcionar.

Porque ya habían estandarizado la compatibilidad de CPU, no se quedaron atascados en “el destino no puede soportar características solicitadas”. Porque los IDs de almacenamiento eran consistentes entre nodos, no perdieron tiempo creando mappings de almacenamiento de emergencia. Tenían una red de migración dedicada que probaban trimestralmente con una sonda MTU y una corrida de iperf.

La evacuación tuvo éxito. El postmortem fue casi sin drama. La “movida heroica” fue una checklist que venían siguiendo desde hace meses: modelos de CPU consistentes, nombres de almacenamiento consistentes, validación periódica de la ruta de migración.

La confiabilidad es mayormente repetición. La parte emocionante es opcional.

Listas de verificación / plan paso a paso (recuperación limpia y prevención)

Paso a paso: Recuperar limpiamente tras una migración abortada

1. Deja de reintentar. Extrae el registro de la tarea e identifica la primera línea de error accionable.
2. Confirma la realidad de la VM. ¿Dónde está corriendo? ¿Qué nodo la posee según recursos del clúster?
3. Estabiliza el clúster. Si quorum o corosync están inestables, arréglalo primero.
4. Revisa locks. Si la VM está bloqueada por migración y necesitas proceder, desbloquea solo después de saber qué nodo es autoritativo.
5. Revisa la topología de almacenamiento. ¿Los discos están en almacenamiento compartido? ¿Existen los IDs en ambos nodos?
6. Revisa artefactos de disco en el destino. Identifica volúmenes/datasets huérfanos; no borres nada que no puedas atribuir.
7. Elige el método de migración correcto:
   • Almacenamiento compartido sano → la migración en vivo es razonable.
   • Almacenamiento local involucrado → planifica storage migration o migración offline.
   • Replicación presente → asegura que la replicación esté actual y consistente.
8. Reintenta una vez, con intención. Mismo error dos veces significa que no cambiaste las condiciones. No colecciones errores como cromos de intercambio.

Lista de prevención: hacer que “migration aborted” sea menos frecuente

• Estandariza IDs de almacenamiento entre nodos. Mismos nombres, mismos tipos, mismas expectativas.
• Modelo de CPU base para cargas migrables. Evita cpu: host salvo que la VM esté diseñada para ello.
• Separa redes cuando sea práctico: management, corosync, storage, migración. Al menos aísla la contención de ancho de banda.
• Valida MTU extremo a extremo (trimestralmente, después de cambios de switch, tras firmware). Los jumbo frames son un contrato.
• Monitorea la salud del almacenamiento (Ceph, ZFS, SMART). Las migraciones amplifican señales débiles.
• Documenta VMs no migrables (passthrough, restricciones de licenciamiento, dispositivos especiales) para que el on-call no lo descubra durante un incidente.
• Practica la migración de forma programada. Si solo migras en emergencias, estás haciendo chaos engineering sin beneficios.

Preguntas frecuentes

1) ¿Por qué Proxmox muestra solo “migration aborted” sin una razón clara?

Porque la tarea de alto nivel envuelve múltiples subsistemas. La línea accionable suele estar antes en el registro de la tarea o en journald para pvedaemon/qemu.

2) ¿Puedo migrar en vivo una VM usando local-lvm?

No como un simple movimiento de cómputo. Si los discos son locales al nodo origen, necesitas disponibilidad del disco en el destino (almacenamiento compartido, replicación o copia de disco). De lo contrario Proxmox abortará.

3) ¿Es seguro ejecutar qm unlock tras una migración fallida?

Es seguro después de confirmar dónde está realmente corriendo la VM y qué artefactos existen. Desbloquear no es destructivo, pero puede permitir que tú (o la automatización) realices acciones destructivas a continuación.

4) ¿Por qué la migración falla al 90–99% y luego aborta?

Eso suele ser la fase final de conmutación o convergencia. Causas comunes: tasa de páginas sucias demasiado alta, inestabilidad de la red o el destino falla al recrear un dispositivo/feature de CPU.

5) ¿“SSH funciona” significa que la red de migración está bien?

No. SSH es el plano de control. La migración de QEMU es un stream de plano de datos que puede ser bloqueado por reglas de firewall, problemas de MTU o diferencias de enrutamiento aun cuando SSH sea perfecto.

6) ¿Cuál es la forma más rápida de saber si es un problema de almacenamiento?

Revisa las líneas de disco en la config de la VM y compáralas con pvesm status en el destino. Si un ID de almacenamiento referenciado no existe o no es compartido, es un problema de almacenamiento.

7) ¿Cómo manejo discos residuales en el destino tras una storage migration fallida?

Identifica volúmenes por VMID, confirma que no estén referenciados por ninguna config de VM en destino u origen y luego elimínalos. Si hay incertidumbre, consérvalos y recupera vía backup/restore para evitar borrar la única copia buena.

8) ¿Por qué las configuraciones de CPU rompen la migración?

La migración en vivo requiere que el destino ofrezca una CPU virtual compatible. Usar cpu: host expone características específicas del host; si el destino no puede igualarlas, QEMU puede negarse a migrar o la VM puede no arrancar de forma segura.

9) ¿Los problemas de Ceph pueden aparecer como “migration aborted” aunque las VMs parezcan estar bien?

Sí. La migración estresa el almacenamiento con operaciones de metadata, reconexiones y a veces picos concurrentes de I/O. Un clúster Ceph ligeramente degradado puede “funcionar” hasta que le pides hacer algo ambicioso simultáneamente.

10) ¿Cuándo debo dejar de intentar migración en vivo y pasar a offline?

Cuando la carga tiene una alta tasa de páginas sucias, cuando la red está restringida, cuando el almacenamiento es local y necesita copia de todos modos, o cuando estás en un incidente y necesitas determinismo más que elegancia.

Siguientes pasos (qué hacer después de arreglarlo)

Después de que la migración tenga éxito—o después de elegir el camino offline correcto—haz estos seguimientos prácticos:

1. Anota la causa raíz en tus notas operativas. El próximo aborto parecerá “nuevo” a menos que lo etiquetes.
2. Normaliza IDs de almacenamiento y modelos de CPU en todo el clúster. Es una de esas tareas aburridas que paga el alquiler cada mes.
3. Prueba la red de migración con una sonda MTU y una prueba de throughput en una ventana de poca actividad. Hazlo recurrente, no un descubrimiento heroico.
4. Audita las configs de VM en busca de ISOs locales, dispositivos en passthrough y uso de “host CPU”. Decide qué VMs están destinadas a ser migrables y configúralas en consecuencia.
5. Limpia artefactos de migraciones abortadas: volúmenes obsoletos, snapshots antiguos y jobs de replicación sobrantes. Hazlo con evidencia, no con corazonadas.

El objetivo no es eliminar las fallas. El objetivo es hacer las fallas legibles, recuperables y menos frecuentes. “migration aborted” se vuelve aburrido una vez que tu clúster, red y almacenamiento dejan de sorprenderse entre sí.