Fallos en la migración en caliente de Proxmox: qué verificar en red, flags de CPU y almacenamiento

Guion de diagnóstico rápido (qué comprobar primero)

Los fallos de migración en caliente parecen aleatorios porque pueden ocurrir en varias fases: verificaciones previas, establecimiento del canal de migración, transferencia pre-copy de RAM, conmutación stop-and-copy y limpieza post-migración. Tu trabajo es encontrar la fase y el cuello de botella rápido.

Primero: identifica la fase y el error real (no el resumen de la UI)

• Revisa el registro de tareas en la UI y luego ve directamente a los logs del journal en ambos nodos.
• Decisión: si no ves un error concreto en 2 minutos, estás mirando el log equivocado.

Segundo: confirma que tienes una ruta de red funcional para migración

• Verifica la conectividad nodo a nodo en las IPs reales usadas para migración (no “management”, no “lo que haga ping”).
• Revisa MTU, pérdida de paquetes, latencia y reglas de firewall.
• Decisión: si hay desajuste de MTU o pérdida intermitente, arregla la red antes de tocar ajustes de Proxmox. La migración es un flujo sostenido de alto rendimiento; encontrará cada debilidad.

Tercero: confirma compatibilidad del modelo de CPU y consistencia del tipo de máquina QEMU

• Compara la configuración de CPU de la VM frente a los flags de CPU del host.
• Decisión: si la CPU está configurada como host y los nodos no son idénticos, para. Establece un tipo de CPU compatible (p. ej., x86-64-v2/v3) y vuelve a probar.

Cuarto: confirma las suposiciones sobre almacenamiento (compartido vs local y qué debe moverse)

• ¿El disco está en almacenamiento compartido? Si no, ¿está habilitada la opción “with local disks” y hay ancho de banda y espacio?
• Decisión: si el disco de la VM es local y enorme, la migración en caliente puede “funcionar” pero ser prácticamente imposible en tu ventana. Planifica migración en frío o replicación.

Quinto: verifica la salud del clúster y la sincronización horaria

• Corosync y problemas de quórum pueden bloquear operaciones, y la deriva horaria puede crear síntomas extraños de TLS y autenticación.
• Decisión: si el clúster no está sano, no trates la migración como tu primer arreglo. Es una función que asume una base estable.

Verdad operativa: cuando falla la migración, las ganancias más rápidas provienen de verificar la ruta de red y las suposiciones sobre el modelo de CPU. El almacenamiento suele ser un incendio lento, no el asesino instantáneo “conexión cerrada”.

Hechos y contexto interesantes (por qué falla esto en la práctica)

1. La migración en caliente precede a la mayoría del “branding” cloud. La migración práctica de VMs fue tema de investigación en los 2000; el pre-copy se convirtió en el enfoque por defecto porque minimiza el downtime mediante copia iterativa de páginas sucias.
2. La migración de QEMU es un protocolo, no un truco mágico. Transmite estado de la VM (páginas de RAM, estado CPU, estado de dispositivos) sobre un canal que se comporta como cualquier conexión de larga duración: pérdida, MTU y firewalls pueden matarlo.
3. “Compatibilidad de CPU” es una promesa contractual. Si la CPU destino no soporta una instrucción que la VM usó, QEMU no puede reanudarla de forma segura. Por eso existen los modelos de CPU: para prometer menos y mover más.
4. Los flags de Intel y AMD no son sólo nombres de marketing. Elementos como AVX/AVX2, AES-NI y extensiones de virtualización aparecen como flags; el desajuste puede bloquear la migración cuando el tipo de CPU es demasiado específico.
5. El tipo de máquina importa. Los “machine types” de QEMU (como i440fx vs q35 y sus variantes versionadas) definen chipset y modelos de dispositivo. Los desajustes pueden romper la migración incluso si las CPUs parecen bien.
6. Los desajustes de MTU son el asesino silencioso de flujos de alto rendimiento. Un ping ICMP puede pasar mientras paquetes grandes se fragmentan o pierden; el tráfico de migración es grande y sostenido, así que choca rápido contra ese muro.
7. Ceph facilita y complica la migración a la vez. Facilita porque los discos son compartidos; complica porque si la red de Ceph está enferma, la migración se convierte en una prueba de estrés no programada.
8. La compresión y el postcopy existen porque el pre-copy tiene límites. Si una VM ensucia memoria más rápido de lo que puedes copiarla (piensa en bases de datos activas), el pre-copy puede entrar en un bucle hasta que expire o fuerce downtime.
9. Corosync no es el plano de datos de migración. Corosync gestiona mensajería de clúster y quórum; la migración usa canales separados (orquestación basada en SSH y sockets de migración QEMU). Pero un clúster roto aún puede bloquear acciones.

Modelo mental: qué hace realmente la “migración en caliente”

Piensa en la migración en caliente como dos flujos que se ejecutan en paralelo:

• Plano de control: Proxmox coordina el movimiento: verifica que el nodo destino esté listo, bloquea la VM, configura túneles/puertos, inicia un proceso QEMU destino en modo “incoming” y luego pide al QEMU origen que migre.
• Plano de datos: QEMU transmite el estado de ejecución de la VM: páginas de memoria, estado vCPU, estado de dispositivos. El estado del disco solo se transmite si migras discos locales explícitamente (o haces migración de almacenamiento). Con almacenamiento compartido, los discos permanecen donde están; la VM simplemente apunta al mismo dispositivo de bloque desde otro nodo.

La mayoría de fallos “misteriosos” son uno de estos:

• Fallos de conectividad y negociación (SSH, firewall, IP errónea, MTU, TLS/certs, resolución de nombres).
• Fallos de compatibilidad (modelo de CPU, flags, tipo de máquina, diferencias en modelos de dispositivos, diferencias en firmware/UEFI).
• Fallos por rendimiento/latencia (la migración no puede mantenerse; el pre-copy no converge; la migración de almacenamiento se estanca; la VM ensucia RAM demasiado rápido).
• Guardrails operativos (clúster sin quórum, el nodo destino no tiene almacenamiento, memoria insuficiente, restricciones HA o recursos fijados).

Ahora vamos a diagnosticar eso con tareas concretas.

Tareas prácticas de verificación (comandos, salidas, decisiones)

Quieres comandos que respondan una pregunta cada uno. Ejecútalos en los nodos origen y destino salvo que se indique otra cosa. No “arregles” nada hasta que puedas explicar el fallo con una frase.

Tarea 1: Identificar la razón del fallo de migración en los logs del sistema

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

Qué significa: Esto es un fallo del plano de control. El exit code 255 de SSH suele indicar auth/host key/firewall/ruteo, no compatibilidad de QEMU.

Decisión: Deja de mirar CPU/almacenamiento. Arregla SSH y la conectividad nodo a nodo primero.

Tarea 2: Comprobar la configuración de la red de migración dedicada en Proxmox

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

Qué significa: Proxmox preferirá 10.10.10.0/24 para el tráfico de migración. Si esa red está rota o mal enrutada entre los nodos, la migración falla o se arrastra.

Decisión: Asegura que cada nodo tenga una IP estable en ese subred y que el ruteo sea correcto. Si no tienes una red de migración real, elimina la configuración o arregla la red.

Tarea 3: Verificar las IP que Proxmox cree que debe usar

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

Qué significa: Muchos clústeres dependen de una resolución consistente de nombres. Si pve2 resuelve a una IP de gestión pero la migración está configurada en otra red, puedes acabar con rutas asimétricas.

Decisión: Elige un esquema de nombres que no mienta. Asegura que el hostname usado para SSH coincida con la red deseada, o usa la configuración explícita de red de migración.

Tarea 4: Confirmar que SSH sin contraseña funciona entre nodos (el requisito aburrido)

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

Qué significa: El plano de control puede alcanzar el destino y ejecutar comandos.

Decisión: Si esto falla, arregla las claves SSH, known_hosts, ruteo o firewall antes que nada.

Tarea 5: Comprobar desajuste de MTU y configuraciones a medias de jumbo frames

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

Qué significa: Un nodo tiene MTU 9000 y el otro 1500. Eso no es “más o menos bien”. Es un fallo de migración esperando ocurrir.

Decisión: Estandariza MTU de extremo a extremo (NIC, puertos de switch, VLANs, bridges). Si no puedes garantizar jumbo en todas partes, usa 1500 y continúa con tu vida.

Broma #1: Los jumbo frames son como promesas ejecutivas—fantásticos cuando son end-to-end, pero un eslabón débil los convierte en un rumor caro.

Tarea 6: Validar la ruta de migración con paquetes grandes (no confíes en ping por defecto)

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

Qué significa: Los paquetes jumbo pasan con “do not fragment”. Buen indicio para un flujo de alto rendimiento.

Decisión: Si falla con “Frag needed” o pérdida de paquetes, arregla MTU y/o la configuración del switch antes de reintentar la migración.

Tarea 7: Revisar el estado del firewall y reglas relacionadas con migración

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

Qué significa: El firewall está en juego. La migración usa comúnmente SSH y puertos de migración de QEMU negociados por Proxmox. Reglas demasiado estrictas pueden romperlo.

Decisión: Si activaste el firewall recientemente, confirma las excepciones para clúster/migración. Desactívalo temporalmente a nivel de nodo solo para diagnóstico si la política lo permite, y luego implementa reglas adecuadas.

Tarea 8: Confirmar quórum del clúster y salud de corosync (porque las operaciones están condicionadas)

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

Qué significa: El clúster tiene quórum. Eso elimina toda una clase de problemas de “por qué todo está bloqueado”.

Decisión: Si no hay quórum, arregla primero la red del clúster. No intentes migraciones como solución alternativa; lo agravarás.

Tarea 9: Verificar la configuración de la VM para modelo de CPU y compatibilidad de migración

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

Qué significa: La CPU está configurada como host. Eso es genial para rendimiento y terrible para clústeres heterogéneos. También fíjate en que el tipo de máquina está versionado.

Decisión: Si el nodo destino tiene otra generación/proveedor de CPU, cambia el tipo de CPU a una línea base compatible y mantén los tipos de máquina alineados entre nodos.

Tarea 10: Comparar flags de CPU del host entre nodos (captura el desajuste rápido)

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

Qué significa: Diferentes proveedores. Con cpu: host, esta VM casi seguro fallará la migración (o será bloqueada) porque el modelo de CPU expuesto difiere.

Decisión: Usa un modelo de CPU común en la configuración de la VM. En Proxmox, elige una base como x86-64-v2/v3 (según tu flota) o un modelo QEMU nombrado soportado por todos los nodos.

Tarea 11: Confirmar que las versiones de QEMU coinciden lo suficiente (no mezcles eras mayores a la ligera)

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

Qué significa: Si el origen usa QEMU 8.1 y el destino algo más antiguo/nuevo con tipos de máquina o modelos de dispositivo incompatibles, puedes tener incompatibilidades de migración.

Decisión: Mantén los nodos en las mismas versiones mayores de Proxmox/QEMU. Haz upgrades rollings con una política: migra VMs fuera del nodo que se actualiza, no entre versiones incompatibles durante la actualización.

Tarea 12: Inspeccionar los detalles del intento de migración desde el registro de tareas

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

Qué significa: Falló la comprobación de gating del almacenamiento. Esto no es ancho de banda; es “pediste almacenamiento compartido pero no lo tienes”.

Decisión: O bien traslada discos a almacenamiento compartido primero, habilita la migración “with local disks” intencionalmente, o hace disponible el almacenamiento en el nodo destino.

Tarea 13: Determinar si los discos de la VM están en almacenamiento compartido o 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

Qué significa: Almacenamiento mixto. Un disco es local-lvm (local al nodo), el otro es Ceph (compartido). La migración en caliente sin mover discos locales fallará o estará bloqueada.

Decisión: Decide: traslada scsi0 a almacenamiento compartido (mejor) o acepta los costes/tiempo de migración de discos locales.

Tarea 14: Verificar que el nodo destino tiene memoria libre suficiente y no sorpresas 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

Qué significa: Tienes margen. Recuerda: la migración necesita memoria en el destino para recibir páginas, y la VM puede tener picos durante la conmutación.

Decisión: Si la memoria disponible es justa, no te la juegues. Migra otra VM primero o programa una interrupción controlada.

Tarea 15: Comprobar si la VM ensucia memoria demasiado rápido (el pre-copy puede no 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

Qué significa: La tasa de páginas sucias es alta. Si se mantiene, la migración podría no finalizar o extender el downtime más allá de tu umbral.

Decisión: Si no converge, limita la carga, habilita compresión de migración con cuidado o usa postcopy en casos específicos (con los riesgos entendidos).

Tarea 16: Validar la salud de Ceph si los discos de la VM están en Ceph (porque la migración lo estresa)

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

Qué significa: Ceph no está completamente feliz. Las slow ops pueden traducirse en picos de latencia de IO de VM durante la migración y pueden estancar la migración de almacenamiento.

Decisión: Si Ceph está degradado o lento, pospón migraciones pesadas. Arregla el subsistema de almacenamiento primero; no se “curará más rápido” bajo carga.

Broma #2: Si tu almacenamiento ya advierte sobre slow ops, añadir migración en caliente es como “probar” un paracaídas saltando dos veces.

Comprobaciones de red que detectan el 80% de los fallos

Cuando la migración falla rápido con errores de conexión, normalmente es red o SSH. Cuando falla lento (o se queda colgada en un porcentaje), suele ser rendimiento, pérdida o una VM que no converge. Tu trabajo es convertir “la red parece bien” en realidad medible.

Verifica qué IPs y rutas se usan realmente

Proxmox puede estar configurado para usar una red de migración, pero el ruteo de Linux decide cómo salen los paquetes de la máquina. Si tienes múltiples NICs/VLANs, confirma que la ruta al IP de migración destino usa la interfaz prevista.

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

Interpretación: Bien: está usando vmbr1 con una IP origen en la subred de migración.

Decisión: Si enruta por la NIC de gestión, arregla rutas o ajusta la configuración de red de migración para no saturar el enlace equivocado.

Mide pérdida y latencia como un adulto

La pérdida mata el rendimiento TCP; la jitter dificulta la convergencia. Usa mtr si está disponible, o al menos un ping decente. Para una red de migración en el mismo switch, quieres números aburridos.

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

Decisión: Cualquier pérdida en una LAN de centro de datos es una bandera roja. Arregla cableado, puertos de switch, offloads de NIC o congestión antes de culpar a Proxmox.

Valida ancho de banda (rápido y sucio)

Las migraciones son básicamente grandes copias de memoria más overhead. Si esperas mover una VM de 16–64 GB “rápido”, necesitas rendimiento real. Si no tienes iperf3, instálalo. Es una herramienta de diagnóstico, no un estilo de vida.

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

Decisión: Si obtienes 1–2 Gbps en un enlace “10G”, la migración se sentirá atascada. Arregla la red (configuración de bond, dúplex, switch, VLAN, drivers de NIC, offloads) antes de afinar QEMU.

Observa el tráfico en tiempo real durante la migración

No adivines si la migración está saturando un enlace. Observa.

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

Decisión: Si los drops aumentan durante la migración, has encontrado al villano. Las pérdidas no son “aceptables si son pequeñas”. Amplifican retransmisos y estancan el progreso.

Mantén los firewalls previsibles

En entornos muy controlados, el firewall de Proxmox es bueno—hasta que alguien lo activa sin modelar el tráfico. La migración usa:

• SSH del origen al destino para orquestación.
• Canales de migración QEMU (a menudo tunelados/gestionados por Proxmox; el comportamiento varía con la “migración segura”).
• Tráfico de almacenamiento (Ceph, NFS, iSCSI) que puede aumentar durante y después de la migración.

Lo que quieres es una política de firewall explícita: permitir nodo-a-nodo en redes de migración y estricta en todo lo demás. “Drop todo y ver qué se rompe” no es una estrategia de seguridad; es una estrategia de seguridad laboral para tu jefe de incidentes.

Flags de CPU y desajustes de tipo de máquina

La compatibilidad de CPU es la categoría de fallo “firme” más limpia. QEMU no puede teletransportar características de CPU. La migración requiere que el destino presente una CPU compatible con lo que el sistema operativo invitado ya vio.

La trampa común: cpu: host en un clúster mixto

host expone el modelo y características de la CPU del host al invitado. Es genial cuando fijas una VM a un nodo para siempre o cuando realmente tienes CPUs idénticas en el clúster. Es una pistola de mano en caso contrario.

En hardware heterogéneo, elige un tipo de CPU base para que el invitado vea una CPU virtual consistente en todas partes. Sí, puedes renunciar a algunas instrucciones. No, tu aplicación probablemente no lo notará. La alternativa es “la migración no funciona”, lo cual sí se nota.

Modelos de CPU base: elige uno y estandariza

Qué escoger depende de tu flota:

• x86-64-v2: base conservadora para compatibilidad amplia (buena cuando tienes nodos más antiguos).
• x86-64-v3: base más moderna con conjunto de instrucciones más amplio; buena cuando la flota es nueva y consistente.
• Modelos QEMU nombrados (p. ej., Haswell, Skylake-Server): útiles en flotas solo Intel, pero pueden ser demasiado específicos.

Tu objetivo no es rendimiento máximo; es movilidad predecible. Si necesitas máximo rendimiento para una VM especial, documenta que está fijada y no migrará entre todos los nodos.

Alineación del tipo de máquina no es opcional

Los tipos de máquina de QEMU como pc-q35-8.1 codifican versiones de chipset/modelo de dispositivo. Si tienes QEMU desalineado entre nodos, puedes encontrar un desajuste de estado de dispositivo durante la migración.

Política operativa: mantén el clúster en la misma versión de Proxmox tanto como sea posible. Durante actualizaciones, migra cargas fuera del nodo que se actualiza, actualízalo y luego vuelve a introducir las cargas. No dejes “medio clúster en nueva versión de QEMU” y esperes migraciones suaves para todas las combinaciones de dispositivos.

Passthrough PCI y vGPU: dolor especial

Si una VM usa dispositivos hostpci, la migración en caliente suele ser imposible a menos que tengas hardware y herramientas muy específicas. El estado del dispositivo no puede moverse de forma segura y el destino puede no tener la misma asignación física.

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

Decisión: Trata las VMs con passthrough como fijadas. Diseña el mantenimiento en torno a ellas (failover a nivel de app, ventanas programadas o migración en frío).

Una cita de fiabilidad para mantener en tu escritorio

La esperanza no es una estrategia. — Rudy Giuliani

Esta frase se repite en operaciones porque es brutalmente aplicable: no “esperes” que las CPUs coincidan, no “esperes” que la MTU sea consistente, no “esperes” que el almacenamiento sea compartido. Verifica.

Almacenamiento: compartido, local, Ceph, ZFS y la ruta de datos de migración

El almacenamiento es donde las migraciones van a morir lentamente. La red y la CPU matan la migración rápido; un diseño de almacenamiento deficiente la hace colgar, arrastrarse o “funcionar” con un downtime inaceptable.

Sabe qué estás migrando: estado de cómputo vs estado de disco

• Migración en caliente (almacenamiento compartido): mueve RAM+CPU+estado de dispositivos; los discos permanecen en el almacenamiento compartido (Ceph RBD, NFS, iSCSI, etc.). Rápido y predecible.
• Migración en caliente con discos locales: mueve RAM+estado y copia bloques de disco por la red. Esto puede ser brutal para discos grandes y VMs ocupadas.
• Migración de almacenamiento: copia discos entre almacenamientos; puede hacerse online en algunas configuraciones, pero sigue siendo I/O pesado.

Si no tienes almacenamiento compartido y esperas migraciones en caliente rápidas, no estás planificando; estás audicionando para un informe de incidentes.

Verifica definiciones de almacenamiento y disponibilidad en ambos nodos

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%

Qué significa: local-lvm está peligrosamente lleno. Si intentas migración de discos locales, puedes quedarte sin espacio a mitad de la copia.

Decisión: Si los thin pools están por encima de ~85–90%, trátalo como riesgo incidente. Libera espacio o expande antes de mover discos.

Específicos de ZFS: ZFS local no es almacenamiento compartido

ZFS es genial. ZFS local sigue siendo local. La migración en caliente requiere ya sea almacenamiento compartido o un mecanismo de movimiento de discos.

Si usas ZFS en cada nodo, el modelo mental correcto es: puedes usar replicación (ZFS send/receive) para pre-etapa de discos y luego hacer un corte controlado. Eso no es lo mismo que “migrar en caliente en cualquier momento”.

Específicos de Ceph: redes separadas, modos de fallo separados

Ceph suele usar una red “pública” (clientes) y quizá una red “de clúster” (replicación/backfill). El tráfico de migración es aparte. Pero operacionalmente colisionan porque la migración incrementa IO y carga CPU, lo que hace que un clúster Ceph marginal muestre su verdadera personalidad.

Antes de grandes eventos de migración, haz que Ceph sea aburrido:

• Todos los OSDs up/in.
• No tormentas de deep-scrub.
• No recuperaciones/backfills sobrecargadas.
• Latencia dentro de límites normales.

Migración de discos locales: decide si vale la pena

Si debes migrar discos locales online, al menos cuantifícalo:

• Tamaño del disco (asignado y real).
• Ancho de banda disponible entre nodos.
• Tasa de escritura de la VM (overhead copy-on-write).
• Tolerancia del negocio a rendimiento degradado durante la copia.

En muchos entornos de producción, la decisión correcta es: programa una ventana de mantenimiento y haz un movimiento en frío, o rediseña el almacenamiento para acceso compartido.

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

1) “Migration failed: can’t connect to destination”

• Síntoma: Falla en segundos, exit code 255 de SSH en logs.
• Causa raíz: Mismatch de claves SSH, host keys cambiadas, firewall bloqueando SSH, IP/route equivocada.
• Solución: Valida ssh -o BatchMode=yes root@dest desde el origen en la IP de migración. Arregla ruteo/hosts/firewall; restablece la confianza SSH del clúster si hace falta.

2) Migración atascada en 0% o avanza muy poco

• Síntoma: El progreso no avanza; la UI muestra tarea en ejecución largo tiempo.
• Causa raíz: Ruta de red equivocada (usar mgmt 1G en vez de 10G), problemas de MTU provocando retransmisiones, pérdida de paquetes o problemas con stateful firewall tracking.
• Solución: Confirma ip route get y prueba throughput (iperf3). Valida pings grandes con -M do. Arregla MTU, rutas o deshabilita offloads problemáticos.

3) “CPU feature mismatch” / “host doesn’t support requested features”

• Síntoma: Falla rápido con errores relacionados a CPU; a menudo aparece solo en logs de QEMU.
• Causa raíz: VM usa cpu: host o un modelo de CPU demasiado específico; el destino carece de un flag requerido.
• Solución: Establece la CPU de la VM a una base del clúster. Mantén nodos en familias de hardware coherentes cuando sea posible.

4) “storage ‘local-lvm’ is not available on node …”

• Síntoma: Migración bloqueada antes de empezar; el log de tarea menciona almacenamiento no disponible.
• Causa raíz: Disco de VM en almacenamiento local del nodo; el nodo destino no tiene ese ID de almacenamiento (por diseño).
• Solución: Mueve discos a almacenamiento compartido primero, o migra con discos locales intencionalmente, o ajusta definiciones de almacenamiento si realmente querías compartido.

5) Migración completa pero la VM se pausa demasiado (“lo vivo se sintió muy offline”)

• Síntoma: Migración exitosa pero downtime de segundos o más; la aplicación sufre timeouts.
• Causa raíz: La VM ensucia RAM demasiado rápido; el pre-copy no converge; throughput de red insuficiente; picos de latencia de IO en almacenamiento (especialmente compartido bajo carga).
• Solución: Migra durante menor actividad de escritura, considera ajustar migración (compresión/postcopy) con precaución y arregla la latencia de almacenamiento subyacente.

6) La migración falla solo para ciertas VMs (otras migran bien)

• Síntoma: Algunas VMs migran; otras fallan consistentemente.
• Causa raíz: Esas VMs tienen passthrough, flags de CPU especiales, diferencias en huge pages o combinaciones específicas de machine type/dispositivo.
• Solución: Normaliza perfiles de hardware de VMs. Documenta excepciones (VMs fijadas). No finjas que todas las cargas son móviles.

7) La migración se rompe justo después de habilitar el firewall de Proxmox

• Síntoma: Migraciones que antes funcionaban ahora fallan; otro tráfico puede seguir OK.
• Causa raíz: Faltan permisos nodo-a-nodo para la red de migración o servicios relacionados; reglas stateful descartan flujos de larga duración.
• Solución: Implementa allowlists explícitas entre nodos en las redes de migración. Prueba migraciones como parte del despliegue del firewall.

Tres micro-historias corporativas desde el frente

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

La empresa tenía dos nodos Proxmox que “se veían iguales” en el rack: misma caja, mismo vendor, mismo número de NICs. Alguien los pidió con seis meses de diferencia y asumió que “mismo modelo” significaba “misma CPU”. No fue así. Uno vino con un stepping más nuevo y una línea base de microcódigo distinta, y el otro era otra familia de CPU por sustituciones en la cadena de suministro.

Configuraron la mayoría de VMs con cpu: host por rendimiento. Funcionó meses porque nunca migraron las cargas pesadas—hasta que una actualización de firmware en el nodo A requirió reboot y trataron de evacuar cargas. La primera migración falló al instante. La segunda también. Ahora tenían un nodo programado para mantenimiento y otro que no podía aceptar cargas.

En la llamada de incidente, la suposición de que “migrar es un botón” hizo perder tiempo. La gente persiguió latencia de Ceph, luego reglas de firewall, luego ajustes HA. La pista estaba en qm config todo el tiempo: cpu: host. Una comparación rápida con lscpu acabó con el misterio.

El arreglo no fue heroico. Cambiaron modelos de CPU de las VMs a una base soportada por ambos nodos, probaron migración en una VM y luego lo extendieron. El impacto en rendimiento fue insignificante. La lección quedó: si quieres movilidad, debes presupuestarla en la exposición de características de CPU.

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

Otra organización se puso creativa con jumbo frames. Activaron MTU 9000 en hosts porque “10G es caro y debemos optimizar”. Pero el equipo de red solo habilitó jumbo en algunos puertos de switch. Algunos trunks VLAN seguían a 1500. Nadie tenía un diagrama end-to-end porque, claro, no lo tenían.

El tráfico normal parecía bien. El ping de gestión funcionaba. SSH funcionaba. Los paquetes pequeños no se quejaban. Luego intentaron migrar una VM con mucha memoria. Empezaba, transfería un poco, luego se estancaba y fallaba. A veces tenía éxito pero tardaba una eternidad. El equipo culpó a Proxmox, luego a QEMU, luego a Ceph, luego a sus decisiones de vida.

El avance vino de una prueba poco sexy: un ping grande con “do not fragment”. Falló. No “tal vez”. Falló. La ruta de migración tenía un camino que silenciosamente bloqueaba paquetes jumbo, provocando fragmentación, retransmisiones y rendimiento terrible.

Lo arreglaron estandarizando MTU en toda la ruta de migración. Y aquí viene el giro: tras el arreglo volvieron a MTU 1500. ¿Por qué? Simplicidad operativa. Eligieron rendimiento predecible sobre optimización teórica. Eso es lo que enseñan los sistemas en producción: la red más rápida es la que funciona todos los días.

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

Un equipo trató la migración en caliente como una función que debe probarse continuamente, no un botón que descubres durante un outage. Cada semana ejecutaban un pequeño conjunto de migraciones: una VM Linux, una Windows, una “ocupada” y una con UEFI. Registraban resultados y mantenían una línea base del tiempo de migración y downtime.

Era aburrido. Nadie se promocionó por “todo sigue funcionando”. Pero la práctica dio fruto cuando una actualización de firmware de switch introdujo pérdida intermitente en una VLAN. La primera señal no fueron usuarios quejarse—fue la comprobación semanal de migración mostrando una ralentización y fallos ocasionales.

Como tenían una línea base, pudieron decir “esto cambió” y demostrarlo con datos: pérdida en ping, caída en iperf y duplicación del tiempo de migración. El equipo de red lo tomó en serio porque la evidencia era sólida y reproducible.

Revirtieron el firmware, restauraron la base y luego actualizaron de nuevo con validación adecuada. No hubo incidente mayor. La práctica aburrida no solo “salvó el día”; evitó una emergencia a las 2 a.m. que habría involucrado demasiada gente y poco café.

Listas de verificación / plan paso a paso

Lista A: Antes de intentar migración en caliente en producción

1. Salud del clúster: pvecm status muestra quórum. Si no, detente.
2. Alineación de versiones: pveversion -v es consistente entre nodos (especialmente pve-qemu-kvm).
3. Red de migración: Decide si la usas. Si sí, confígúrala y verifica con pings grandes.
4. Confianza SSH: Nodo-a-nodo ssh -o BatchMode=yes funciona en las IPs de migración.
5. Política de CPU: Modelo base de CPU para cargas migrables; evita cpu: host salvo nodos homogéneos.
6. Política de almacenamiento: Almacenamiento compartido para VMs migrables, o plan documentado para discos locales.
7. Lista de excepciones: VMs con passthrough/vGPU/edge-case documentadas como fijas.
8. Capacidad disponible: El destino tiene memoria y CPU para la VM y el overhead de migración.

Lista B: Cuando una migración falla (plan modo incidente de 15 minutos)

1. Captura el error real: revisa journalctl -u pvedaemon y los logs de tareas.
2. Clasifica el fallo: conexión/auth vs compatibilidad CPU vs gating de almacenamiento vs lento/convergencia.
3. Sanidad de red: ip route get, ping -M do -s ..., iperf3 rápido si está permitido.
4. Sanidad de CPU: qm config VMID para tipo de CPU; lscpu para comparar nodos.
5. Sanidad de almacenamiento: qm config para localizar discos; pvesm status y (si Ceph) ceph -s.
6. Reintenta una vez tras un arreglo dirigido. No cinco veces. Reintentos repetidos crean ruido, contención de locks y a veces estado parcial.
7. Escala con evidencia: lleva la línea exacta de error y las salidas de comandos. “La migración falló” no es un ticket; es un estado de ánimo.

Lista C: Después de arreglarlo (para que se mantenga arreglado)

1. Estandariza modelos de CPU de VMs migrables en la flota.
2. Estandariza MTU en redes de migración, o estandariza en 1500.
3. Programa pruebas de migración regulares y registra duración/downtime.
4. Documenta VMs fijadas y por qué están fijadas.
5. Mantén versiones de nodos alineadas; evita clústeres mixtos por tiempo prolongado.

Preguntas frecuentes

1) ¿Necesito almacenamiento compartido para migración en caliente?

Si quieres migración en caliente rápida y fiable: sí, en la práctica. Sin almacenamiento compartido puedes migrar discos locales, pero estás haciendo una copia online gigante y llamándola “en caliente”. Puede ser aceptable para discos pequeños y VMs tranquilas, no para bases de datos productivas muy ocupadas.

2) ¿Por qué la migración funciona para algunas VMs pero no para otras?

Perfiles de hardware virtual diferentes. CPU configurada como host, passthrough de dispositivos, tipos de máquina distintos o args QEMU especiales pueden hacer una VM no migrable aun cuando el clúster esté sano.

3) ¿Es siempre malo usar cpu: host?

No. Está bien para VMs que viven en un único nodo con prioridad de rendimiento o clústeres verdaderamente homogéneos. Es malo cuando asumes uniformidad de hardware que no aplicas. Si quieres movilidad, elige un modelo base de CPU y cúmplelo.

4) ¿Cuál es la forma más rápida de detectar un problema de MTU?

Ping grande con “do not fragment” en la IP de migración: ping -M do -s 8972 target para MTU 9000. Si falla, los jumbo no funcionan end-to-end. Arréglalo o deja de usar jumbo.

5) ¿Por qué la migración se queda en cierto porcentaje?

A menudo es que el pre-copy no converge por alta tasa de páginas sucias, o el throughput de la red colapsa por pérdida/retransmisiones. Revisa qm monitor VMID --cmd "info migrate" y busca la tasa de páginas sucias y el estado de migración.

6) ¿Puedo migrar entre nodos con diferentes versiones de Proxmox/QEMU?

A veces, pero no es una práctica recomendable. La compatibilidad de migración es mejor cuando las versiones de QEMU y los tipos de máquina están alineados. En upgrades, evacua un nodo, actualízalo y vuelve a introducirlo—minimizando operación mixta.

7) ¿Cómo detecto si la migración usa la NIC equivocada?

ip route get <destination migration IP> te indica qué interfaz y qué IP origen se usará. Si no es tu bridge/NIC de migración, arregla rutas o la configuración de red de migración.

8) ¿Qué hay de las VMs Windows y UEFI—riesgos especiales?

UEFI en sí suele estar bien si ambos nodos lo soportan y la configuración de la VM es consistente. Los problemas suelen venir por diferencias de dispositivos, desajuste de tipos de máquina o cambios en la disposición del almacenamiento. Mantén firmware/tipo de máquina consistente y evita cambios ad-hoc de hardware.

9) ¿Debo habilitar compresión en migración?

Sólo cuando hayas medido un cuello de botella de red y tengas CPU disponible. La compresión intercambia CPU por ancho de banda. En hosts limitados por CPU, empeora todo, incluyendo la carga que intentas no perturbar.

10) ¿Y si tengo Ceph y la migración sigue fallando?

Entonces la falla probablemente no sea “disco compartido no disponible” sino red/CPU/firewall o salud de Ceph bajo carga. Revisa ceph -s y busca slow ops. Ceph puede estar técnicamente up y aun así ser operativamente miserable.

Conclusión: siguientes pasos para mantener la cordura

Cuando la migración en caliente de Proxmox falla, no la trates como un evento místico. Es un conjunto de prerrequisitos previsibles: ruta de red estable, exposición de CPU compatible y arquitectura de almacenamiento que coincida con tus expectativas.

Próximos pasos que realmente reducen incidentes futuros:

• Define una política de CPU para VMs (modelo base para cargas migrables) y aplícala.
• Haz la red de migración aburrida: MTU consistente end-to-end, rendimiento verificado, permisos explícitos en firewall.
• Deja de fingir que discos locales son compartidos. Si necesitas movilidad, diseña para almacenamiento compartido o un proceso de cutover por replicación.
• Realiza migraciones de prueba regularmente y mantiene una línea base. Si sólo pruebas durante incidentes, estás haciendo chaos engineering con clientes.

Si no haces otra cosa: verifica la ruta IP de migración y deja de usar cpu: host en clústeres con hardware mixto. Esos dos cambios eliminan una cantidad sorprendente de dolor.