Cómo migrar de VMware ESXi a Proxmox VE (paso a paso): VMs, discos, VLANs, tiempo de inactividad

Qué estás migrando realmente (no son solo VMs)

Un entorno ESXi es un conjunto de acuerdos que no escribiste: qué VLANs existen, qué NICs son trunks, qué datastores son “lo bastante rápidos”,
qué VMs pueden ejecutar hardware virtual antiguo y cuáles han estado haciendo snapshots silenciosamente desde el último trimestre.
Proxmox ejecutará tus cargas, pero no preservará esos acuerdos a menos que los reconstruyas deliberadamente.

Piensa en la migración como cuatro mudanzas independientes:

• Semántica de cómputo: exposición del modelo de CPU, comportamiento NUMA, tipo de controlador de disco, firmware (BIOS vs UEFI), arranque seguro, temporizadores.
• Semántica de almacenamiento: thin vs thick, snapshots, orden de escritura, profundidad de cola, TRIM/discard, alineación, ajustes de caché.
• Semántica de red: etiquetas VLAN, MTU, LACP, aprendizaje de MAC, modo promiscuo (rara vez necesario, a menudo “habilitado por accidente”).
• Semántica operativa: backups, restauraciones, supervisión, ventanas de mantenimiento y cómo haces rollback cuando una VM no arranca.

Tu objetivo no es “hacer que arranque”. Tu objetivo es “volverlo aburrido otra vez”. Aburrido es una característica.

Hechos y contexto que cambian decisiones

Estos son los pequeños y concretos antecedentes y comportamientos que importan en la planificación. Ignóralos y los aprenderás de la forma cara.

1. VMDK es más antiguo que la mayoría de tus herramientas. Los formatos de disco virtual de VMware evolucionaron junto a VMFS y cadenas de snapshots; las VMs de larga vida suelen arrastrar supuestos heredados (como tipos de controlador).
2. QCOW2 no se diseñó como “formato de rendimiento”. Es flexible (snapshots, compresión), pero raw sobre ZFS o LVM-thin puede ser más simple y rápido para muchas cargas de producción.
3. Virtio se volvió el estándar de facto por rendimiento en KVM porque la emulación es cara. Si dejas NIC y disco en equivalentes e1000/IDE “por seguridad”, lo pagarás siempre.
4. OVF/OVA se pensaron para portabilidad, pero la portabilidad real depende de drivers. Exportar un appliance no garantiza que arranque limpio en hardware virtual distinto.
5. Los snapshots de ESXi no son backups, y la estructura de archivos lo demuestra. Una cadena de discos delta se comporta como una torre Jenga: estable hasta que la empujas.
6. El modelo de clúster de Proxmox es simple a propósito. Está diseñado para que un equipo pequeño lo gestione sin una capa de gestión adicional; esa simplicidad se convierte en tu responsabilidad en diseño de red y almacenamiento.
7. Los bridges VLAN-aware en Linux están maduros. Esto no es 2008. Un bridge Linux con filtrado VLAN puede reemplazar muchos casos de uso de vSwitch limpiamente—si asignas las etiquetas correctamente.
8. ZFS tiene memoria larga. Te protegerá de la corrupción silenciosa, pero también preservará fielmente decisiones malas (como una recordsize incorrecta para bases de datos) hasta que lo ajustes.

Una cita para mantener la honestidad y justificar la paranoia en tu plan de cambio:
La esperanza no es una estrategia. — James R. Schlesinger

Inventario preflight: qué medir antes de tocar nada

Si no puedes listar tus VLANs, uso de datastores y firmware de arranque de las VMs, no estás migrando: estás apostando con pasos extra.
El trabajo de inventario no es glamoroso. Tampoco lo es una revisión de incidentes.

Qué inventariar (mínimo)

• Lista de VMs: nombre, CPU, RAM, discos, número de NIC, SO, criticidad, propietario, ventana de mantenimiento, RPO/RTO.
• Distribución de discos: qué VMDKs son thin, cadenas de snapshots y el datastore donde residen.
• Firmware: BIOS vs EFI. El arranque seguro importa más de lo que crees.
• Red: port groups, IDs de VLAN, puertos trunk, MTU, LACP, uplinks.
• Dispositivos especiales: passthrough USB, puertos serie, GPU, dongles, passthrough de NIC física.
• Dependencias temporales: fuentes NTP, controladores de dominio, servidores de licencias.
• Backups: qué se puede restaurar, qué tan rápido y si alguien lo ha probado este año.

Broma #1: Lo único más permanente que una regla de firewall “temporal” es un snapshot de VM “temporal”.

Decide por adelantado: migración en frío o parcial en vivo?

Con ESXi a Proxmox, la “migración en vivo” no es la ruta por defecto a menos que introduzcas herramientas intermedias de replicación.
Para la mayoría, el enfoque fiable es la migración en frío por VM (apagar, exportar/copiar, importar, arrancar).
Tu downtime está dominado por la copia del disco y la validación post-arranque.

Puedes reducir downtime con:

• Precarga de discos mientras la VM está en ejecución (copiar VMDK a staging y luego un sync final durante downtime).
• Replicación a nivel de aplicación (replicación de BD, sincronización de ficheros), luego cambiar endpoints.
• Paralelismo (varias VMs por ventana), pero no satures tu almacenamiento y te sorprendas luego.

Arquitectura objetivo en Proxmox: almacenamiento, tipos de CPU, modelo de red

Proxmox te da suficiente cuerda para construir una gran plataforma o un outage artesanal. Escoge una línea base y estandarízala.

Cómputo: elige compatibilidad primero, luego rendimiento

Para clústeres con hardware mixto, empieza con un tipo de CPU conservador (x86-64-v2 u otra línea base similar) para que las VMs puedan moverse entre nodos más tarde.
Si solo tienes un nodo por VM para siempre, claro, usa host para máximo rendimiento. Pero sé honesto sobre el futuro.

• Bus de disco: VirtIO SCSI (single) o VirtIO Block; evita IDE/SATA a menos que estés arrancando un SO antiguo.
• Modelo de NIC: VirtIO; mantiene e1000 solo para instaladores antiguos y quítalo después.
• Firmware: coincide con la VM origen (BIOS vs OVMF/UEFI). No “modernices” durante la migración a menos que te guste depurar dos veces.

Almacenamiento: elige un backend principal y mantente con él

Backends comunes de Proxmox en proyectos de migración:

• ZFS: integridad fuerte, snapshots, replicación; excelente si entiendes necesidades de RAM y amplificación de escritura.
• LVM-thin: simple, rápido, familiar; menos perillas; los snapshots existen pero se comportan diferente que en ZFS.
• Ceph: potente, pero migrar a Proxmox no es el momento para aprender almacenamiento distribuido desde cero.
• NFS/iSCSI: correcto para almacenamiento compartido; el rendimiento depende de la red y la configuración del servidor.

Toma de posición: si es tu primera migración a Proxmox y no tienes un equipo de almacenamiento, usa ZFS en mirror/RAIDZ
o LVM-thin sobre RAID por hardware. Deja Ceph para cuando puedas permitirte dominarlo.

Red: adopta bridges Linux y sé explícito

Proxmox usa la red de Linux debajo. Es buena noticia: es predecible, scriptable y depurable con herramientas estándar.
Tu migración depende de recrear los port groups de ESXi como bridges Linux con VLAN (o bridges separados), y luego adjuntar las NICs de las VMs con las etiquetas correctas.

VLANs, bridges, bonds: mapear la red de ESXi a Proxmox

ESXi oculta cierta complejidad detrás de “vSwitch” y “port group”. Linux te muestra los engranajes. Eso es una ventaja hasta que etiquetas mal el tráfico.

Traduce el modelo

• Uplinks de vSwitch en ESXi → bond de Linux (opcional) o una NIC física
• Port group con ID de VLAN → puerto de bridge en Proxmox con tag configurado, o bridge VLAN-aware + etiqueta VLAN por VM
• Comportamiento trunk/native VLAN → filtrado VLAN en bridge de Linux + la configuración del switch debe coincidir

Patrón recomendado: un bridge VLAN-aware por host

Crea vmbr0 conectado a tu trunk uplink (o bond), actívalo VLAN-aware y etiqueta por NIC de VM.
Esto mantiene estable la configuración del host mientras cambias etiquetas por VM durante la migración.

MTU y jumbo frames: decide con evidencias

Si necesitas MTU 9000 para almacenamiento (iSCSI/NFS/Ceph), configúralo end-to-end: switchports, NICs físicas, bonds, bridges e interfaces de VM según sea necesario.
Un único enlace en 1500 crea una pesadilla de “funciona a veces”. Esas son las mejores pesadillas: intermitentes.

Estrategias de migración de discos (elige tu dolor)

Hay tres maneras comunes de mover un disco desde ESXi a Proxmox. Ninguna es universalmente mejor; elige según tamaño, ancho de banda y cuánto odias el downtime.

Estrategia A: exportar OVF/OVA, importar en Proxmox

Mejor cuando: quieres un export empaquetado y tus VMs son sencillas.
Peor cuando: tienes discos enormes o quieres control fino sobre formatos y controladores de disco.

• Pros: contenedor estandarizado, fácil de archivar.
• Contras: puede ser lento; la importación puede no preservar cada matiz; aún necesitas validar drivers/controladores.

Estrategia B: copiar VMDK y convertir con qemu-img

Mejor cuando: quieres control, tienes acceso al shell, quieres elegir raw vs qcow2 y te importa el rendimiento.

• Pros: transparente, scriptable, funciona sin herramientas sofisticadas.
• Contras: las cadenas de snapshots requieren cuidado; la conversión puede tardar; necesita planificación de espacio en disco.

Estrategia C: replicación a nivel de bloque o movimiento basado en almacenamiento

Mejor cuando: ya tienes replicación (BD, sincronización de ficheros) o almacenamiento compartido que puedes re-presentar.
Esto no suele ser una historia genérica de migración de VMs; es por aplicación.

Broma #2: El plan de migración que dice “simplemente convertiremos los discos” es como decir “simplemente aterrizaremos el avión”. Técnicamente correcto, emocionalmente incompleto.

Listas de comprobación / plan paso a paso (downtime y corte)

Fase 0: elige el piloto y define el éxito

• Elige 1–3 VMs representativas pero aún no críticas.
• Define “éxito” en términos operativos: arranque, conectividad de red, comprobaciones de salud de la app, trabajos de backup funcionando, monitorización en verde.
• Define rollback: apagar la VM en Proxmox, encender la VM en ESXi, revertir DNS o VIP si hace falta.

Fase 1: construir host(s) Proxmox con una línea base aburrida

• Instala Proxmox VE, actualiza y reinicia en el kernel esperado.
• Configura almacenamiento con un único pool/volume group principal; evita mezclar formatos sin razón.
• Configura un bridge VLAN-aware y confirma trunking con el equipo de red (o tu yo futuro).
• Configura NTP, DNS y un patrón de acceso de gestión que no dependa de un único jump host.

Fase 2: precargar datos (opcional pero poderoso)

• Copiar exportaciones de VM o VMDKs a un área de staging mientras la VM aún corre.
• Mide el throughput y estima downtime: tamaño del disco / MB/s observado + sobrecarga de conversión.
• Si el downtime es demasiado grande, para aquí y rediseña (replicación, mejor enlace, staging local, copia paralela).

Fase 3: ventana de downtime (por VM)

1. Deshabilita schedules/agentes que te pelearán (trabajos de backup, parches).
2. Apaga la VM limpiamente en ESXi.
3. Copia final de discos/archivos de exportación.
4. Convierte/importa en Proxmox y adjunta con firmware/controlador coincidente.
5. Arranca en una red aislada primero (opcional pero recomendado para apps críticas).
6. Valida: IP, rutas, DNS, salud de la app, integridad de datos, sincronización horaria, licencias, logs.
7. Corte final: mover VLAN/DNS/VIP, habilitar monitorización y backups.
8. Deja la VM en ESXi apagada pero intacta al menos hasta el siguiente día hábil.

Fase 4: estandarizar después del éxito

• Convierte NIC/disco a VirtIO si arrancaste con modelos legacy.
• Instala qemu-guest-agent y actívalo para apagados limpios e informe de IPs.
• Establece la política de backups en Proxmox y prueba la restauración (no negocies con la física después).

Cuaderno de tareas: comandos, salidas y qué decidir a partir de ellos

Pediste práctico. Aquí está práctico. Cada tarea incluye (1) comando, (2) qué significa la salida, (3) qué decisión tomas.
Ajusta nombres de host, VMIDs, nombres de almacenamiento e interfaces a tu entorno.

Tarea 1: confirmar salud y versiones del nodo Proxmox

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2.2 (running kernel: 6.8.12-4-pve)
pve-manager: 8.2.4 (running version: 8.2.4/2e1f9d1a)
pve-kernel-6.8: 6.8.12-4
qemu-server: 8.2.2
libpve-storage-perl: 8.2.3

Significado: Confirma kernel y stack QEMU. Las migraciones fallan de formas raras en combinaciones desajustadas de userland/kernel.

Decisión: Si el nodo está atrasado, actualiza ahora—antes de importar VMs y empezar a depurar fantasmas.

Tarea 2: comprobar capacidad de almacenamiento y tipo de sistema de ficheros en destino

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active         98.00 GiB       12.34 GiB       80.12 GiB   12.59%
rpool             zfspool active          3.64 TiB        1.02 TiB        2.62 TiB   28.02%

Significado: Muestra los storages disponibles en Proxmox y el espacio libre. Las importaciones requieren margen (la conversión puede duplicar espacio temporalmente).

Decisión: Si el espacio disponible es menor que 1.3–1.5× el disco más grande que vas a convertir, para y añade espacio o cambia estrategia (import raw, conversión en streaming o staging en otro sitio).

Tarea 3: verificar salud del pool ZFS antes de confiar en él

cr0x@server:~$ zpool status -x
all pools are healthy

Significado: ZFS no reporta errores ni vdevs degradados.

Decisión: Si ves DEGRADED/FAULTED, no importes VMs de producción aún. Repara el pool primero o estarás importando a un incidente en cámara lenta.

Tarea 4: estado base de interfaces de red y bridges

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
bond0            UP             3c:fd:fe:aa:bb:01
vmbr0            UP             3c:fd:fe:aa:bb:01

Significado: Confirma estado de enlace. Si tu bridge o uplink no está UP, tu “importación exitosa” se convertirá en “¿por qué no hace ping?”.

Decisión: Arregla problemas físicos/bond/bridge ahora; no empieces con una red rota y esperes que se arregle sola.

Tarea 5: confirmar modo de bond y negociación LACP (si usas bond)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
LACP rate: fast
Aggregator selection policy (ad_select): stable

Slave Interface: eno1
MII Status: up
Actor Churn State: none

Slave Interface: eno2
MII Status: up
Actor Churn State: none

Significado: Confirma 802.3ad y salud de enlaces. Estados de churn y “down” indican mismatch de switch o problemas de cableado.

Decisión: Si LACP no es estable, usa active-backup temporalmente y programa una corrección de red. El día de migración no es para depurar canales de switch.

Tarea 6: verificar filtrado VLAN y VLANs permitidas en el bridge Linux

cr0x@server:~$ bridge vlan show
port              vlan-id
bond0             1 PVID Egress Untagged
bond0             10
bond0             20
bond0             30
vmbr0             1 PVID Egress Untagged

Significado: Muestra qué VLANs están permitidas/filtradas en los puertos del bridge. Si falta VLAN 20, las VMs etiquetadas 20 estarán en silencio.

Decisión: Si no están las VLANs, arregla la configuración de VLAN del bridge y la del switch trunk antes del corte. Esto es una condición de éxito binaria.

Tarea 7: throughput base para planificación de copias (no adivines)

cr0x@server:~$ iperf3 -c 10.20.30.40 -t 10
Connecting to host 10.20.30.40, port 5201
[  5] local 10.20.30.11 port 50422 connected to 10.20.30.40 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  9.42 GBytes  8.09 Gbits/sec                  sender
[  5]   0.00-10.00  sec  9.41 GBytes  8.08 Gbits/sec                  receiver
iperf Done.

Significado: Tienes ~8 Gbit/s de throughput utilizable en esta ruta de prueba.

Decisión: Usa esto para estimar tiempo de copia. Si tu VM tiene un disco de 2 TB, no harás una “ventana rápida” sobre este enlace sin precarga o rediseño.

Tarea 8: copiar un bundle de VM exportada a Proxmox (staging)

cr0x@server:~$ rsync -ah --info=progress2 /mnt/stage/ESXI-EXPORTS/app01/ /var/lib/vz/import/app01/
         12.34G  12%   215.78MB/s    0:00:46
        101.22G 100%   238.11MB/s    0:07:14 (xfr#12, to-chk=0/14)

Significado: Confirma la tasa de transferencia sostenida real y la finalización.

Decisión: Si el throughput está muy por debajo de lo esperado, encuentra el cuello de botella antes de programar downtime (IO de disco, un solo hilo, sobrecarga de cifrado, ruta de red).

Tarea 9: convertir un VMDK a raw (a menudo mejor en ZFS/LVM-thin)

cr0x@server:~$ qemu-img info /var/lib/vz/import/app01/app01-disk1.vmdk
image: /var/lib/vz/import/app01/app01-disk1.vmdk
file format: vmdk
virtual size: 300G (322122547200 bytes)
disk size: 128G
cluster_size: 65536

Significado: Muestra tamaño virtual (visible al guest) vs bloques realmente usados (realidad de thin provisioning).

Decisión: Si el disco es thin pero lleno de bloques viejos, considera hacer trim dentro del invitado antes del export final. Puede reducir drásticamente el tiempo de copia.

cr0x@server:~$ qemu-img convert -p -O raw /var/lib/vz/import/app01/app01-disk1.vmdk /rpool/vmdata/app01-disk-0.raw
    (0.99/100%)

Significado: La conversión consume CPU e IO; el porcentaje indica progreso.

Decisión: Si el tiempo de conversión es inaceptable, evalúa importar como qcow2 temporalmente, o pre-convertir durante horas de oficina en almacenamiento de staging y luego mover el resultado.

Tarea 10: crear la estructura de VM en Proxmox con firmware coincidente

cr0x@server:~$ qm create 120 --name app01 --memory 8192 --cores 4 --sockets 1 --net0 virtio,bridge=vmbr0,tag=20 --scsihw virtio-scsi-single --ostype l26 --bios ovmf
create VM 120: success

Significado: Crea la VMID 120 con firmware OVMF (UEFI) y una NIC virtio etiquetada VLAN.

Decisión: Haz coincidir BIOS/OVMF con la VM origen. Si adivinas mal, obtendrás “no boot device” que parece un problema de disco pero no lo es.

Tarea 11: importar el disco en almacenamiento gestionado por Proxmox

cr0x@server:~$ qm importdisk 120 /rpool/vmdata/app01-disk-0.raw rpool
importing disk '/rpool/vmdata/app01-disk-0.raw' to VM 120 ...
Formatting '/rpool/data/vm-120-disk-0.raw', fmt=raw size=322122547200
Successfully imported disk as 'unused0:rpool:vm-120-disk-0'

Significado: El disco ahora está en el storage de Proxmox y adjunto como dispositivo sin usar.

Decisión: A continuación debes adjuntarlo como el dispositivo de arranque/controlador correcto. “Unused” significa que Proxmox lo importó pero no lo conectaste.

Tarea 12: adjuntar el disco importado y establecer orden de arranque

cr0x@server:~$ qm set 120 --scsi0 rpool:vm-120-disk-0 --boot order=scsi0 --efidisk0 rpool:1,format=raw
update VM 120: -scsi0 rpool:vm-120-disk-0 -boot order=scsi0 -efidisk0 rpool:1,format=raw

Significado: La VM ahora tiene su disco primario en SCSI (VirtIO SCSI) y un efidisk para variables OVMF.

Decisión: Si la fuente era BIOS (legacy), no agregues efidisk0; en su lugar mantén --bios seabios y configura el arranque en consecuencia.

Tarea 13: primer arranque con consola y triaje inmediato de logs

cr0x@server:~$ qm start 120
start VM 120: success

cr0x@server:~$ qm terminal 120
connected to qemu-server 120 (running)

Significado: Estás en la consola de la VM. Si se queda colgada temprano, aquí ves problemas del bootloader y drivers.

Decisión: Si el kernel del guest hace panic o Windows da BSOD, no cambies cinco ajustes al azar. Identifica primero mismatch de controlador/firmware.

Tarea 14: verificar que la VM ve su NIC y obtiene IP (vía guest agent)

cr0x@server:~$ qm guest cmd 120 network-get-interfaces
{
  "return": [
    {
      "name": "eth0",
      "ip-addresses": [
        {
          "ip-address": "10.20.20.51",
          "ip-address-type": "ipv4",
          "prefix": 24
        }
      ],
      "hardware-address": "BC:24:11:22:33:44"
    }
  ]
}

Significado: El guest agent está ejecutándose y reporta interfaces de red. Esto es oro durante los cortes.

Decisión: Si el guest agent no responde, puedes seguir pero pierdes visibilidad. Instala/activa el agente como parte de la estabilización.

Tarea 15: comprobar latencia IO del host durante conversión/import

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.12-4-pve (server)  12/28/2025  _x86_64_ (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.40    0.00    6.10   18.20    0.00   63.30

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1         20.00   880.00     0.00   0.00   2.10    44.00  420.00  51200.00    12.00   2.78  18.50   121.90   7.90  92.00

Significado: Alto %iowait y alto w_await indican presión en almacenamiento. %util cerca de 100% sugiere saturación.

Decisión: Si la latencia sube en horas de trabajo, limita las conversiones, mueve importes fuera de pico o usa staging en almacenamiento más rápido. No “fuerces” y luego expliques la lentitud general.

Tarea 16: validar etiquetado VLAN desde dentro de una VM (sanity check rápido)

cr0x@server:~$ ping -c 2 10.20.20.1
PING 10.20.20.1 (10.20.20.1) 56(84) bytes of data.
64 bytes from 10.20.20.1: icmp_seq=1 ttl=64 time=0.410 ms
64 bytes from 10.20.20.1: icmp_seq=2 ttl=64 time=0.392 ms

--- 10.20.20.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.392/0.401/0.410/0.009 ms

Significado: La VM alcanza su gateway en la subred esperada; VLAN y etiquetado de bridge probablemente correctos.

Decisión: Si no puede hacer ping al gateway, no depures la aplicación. Arregla L2/L3 primero: etiqueta VLAN, lista permitida en trunk, bridge o configuración IP.

Problemas de invitados Windows y Linux (drivers, arranque, qemu-guest-agent)

Los tipos de controlador no son cosméticos

Muchas VMs Windows en ESXi arrancaron durante años con LSI Logic SAS o controladores VMware Paravirtual.
En Proxmox probablemente quieras VirtIO SCSI por rendimiento. Pero si Windows no tiene el driver VirtIO instalado, no arrancará al cambiar.

Enfoque práctico:

• Arranca primero usando un controlador compatible (SATA puede ser una muleta temporal).
• Instala drivers VirtIO en Windows.
• Luego cambia el bus de disco a VirtIO SCSI y confirma el arranque.

Mismatch UEFI vs BIOS parece una falla de disco

Si la VM origen usaba EFI y la arrancas bajo SeaBIOS (o viceversa), a menudo obtienes “no boot device”.
La gente entonces reimporta discos, reconvierte y pierde un día. Coincide el firmware primero.

Sincronización horaria: evita relojes contrapuestos

ESXi tenía la sincronización horaria de VMware Tools en muchos entornos. Proxmox usa QEMU guest agent y servicios horarios estándar del SO.
Elige un método autoritativo (normalmente NTP/chrony en el guest) y desactiva el resto.

Trim/discard y la realidad del thin provisioning

Si migras discos thin y luego los almacenas en almacenamiento thin otra vez, has creado una pila “thin-on-thin”.
Puede funcionar, pero debes monitorizar uso físico real y asegurarte de que discard/TRIM esté soportado end-to-end.

Guion de diagnóstico rápido (encuentra el cuello de botella en minutos)

Cuando una migración “va lenta” o una VM está “laggy”, no debatas sensaciones. Toma medidas en este orden. Está optimizado para velocidad y señal.

Primero: ¿la red es el limitador?

• Ejecuta iperf3 entre el staging origen y Proxmox.
• Busca un enlace saturado, mismatch de duplex o un salto oculto a 1G.
• Confirma consistencia de MTU si esperas jumbo frames.

Segundo: ¿el almacenamiento destino está saturado o con alta latencia?

• Usa iostat -xz 1 en Proxmox durante la conversión/import.
• Busca %util cerca de 100% y await subiendo a decenas de ms para SSD/NVMe (o cientos para discos giratorios).
• Revisa ZFS: salud del pool, presión ARC y si estás forzando sync en todo.

Tercero: ¿CPU es el limitador (a menudo durante conversión)?

• Usa top o pidstat para ver si qemu-img está pegando un core.
• Si está limitado por CPU, paralelizar conversiones puede ayudar—pero solo si el almacenamiento lo soporta.

Cuarto: ¿el invitado está mal configurado (arranque y drivers)?

• Revisa firmware y bus de disco primero (OVMF vs SeaBIOS; VirtIO vs SATA).
• Luego modelo de NIC (VirtIO) y etiquetas VLAN.
• Sólo después persigue problemas a nivel de aplicación.

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

1) La VM arranca a “no boot device”

Síntoma: La VM se inicia y luego cae en la consola de firmware o gestor de arranque sin disco.

Causa raíz: Mismatch de firmware (BIOS vs UEFI) o orden de arranque incorrecto, o disco adjunto a un bus distinto al que espera el SO.

Solución: Coincide el firmware con la VM origen; establece el orden de arranque al disco correcto; adjunta el disco en SATA temporalmente si hace falta para arrancar, luego instala VirtIO y cambia.

2) La VM tiene link de red pero no alcanza al gateway

Síntoma: La interfaz está Up; la IP está configurada; falla el ping al gateway.

Causa raíz: Etiqueta VLAN incorrecta (o VLAN faltante en el trunk); bridge no VLAN-aware; switchport no trunkea la VLAN.

Solución: Valida la etiqueta VLAN por NIC de VM; confirma el filtrado VLAN del bridge; confirma la lista de VLANs permitidas en el switch. Prueba L2 con ARP y ping al gateway.

3) La copia de migración es “rápida al inicio, luego se arrastra”

Síntoma: La copia empieza a cientos de MB/s y luego cae a decenas.

Causa raíz: Pool ZFS alcanzando escrituras sync sin SLOG (si está forzado), presión ARC, o el destino se vuelve bound por latencia debido a escrituras aleatorias durante conversión.

Solución: Staging en almacenamiento local rápido; convertir fuera de pico; considerar raw en lugar de qcow2; monitorizar iostat y estadísticas de ZFS; evitar forzar sync salvo que sea necesario.

4) VM Windows pantallazo azul tras cambiar a VirtIO

Síntoma: Fallo de arranque/BSOD inmediatamente después de cambiar controlador de disco o modelo de NIC.

Causa raíz: Falta de drivers VirtIO o tipo de controlador de almacenamiento incorrecto.

Solución: Arranca usando SATA o un controlador compatible; instala drivers VirtIO; luego cambia y reinicia. Mantén un punto de rollback conocido.

5) Las VMs funcionan pero son misteriosamente más lentas que en ESXi

Síntoma: Mayor latencia, menor throughput, paradas intermitentes.

Causa raíz: Dispositivos emulados (e1000/IDE), modo de caché incorrecto, ajustes de energía del host o mismatch de recordsize en ZFS.

Solución: Usa VirtIO para NIC y disco; verifica ajustes de caché; asegura que el governor de CPU/gestión de energía sea sensato; ajusta propiedades del dataset ZFS donde corresponda.

6) Los backups no capturan silenciosamente las VMs nuevas

Síntoma: Los jobs de backup corren, pero la VM migrada no está incluida o falla.

Causa raíz: VM en un backend de almacenamiento no incluido en la configuración de backup, o snapshots no soportados/deshabilitados.

Solución: Reconciliar IDs de almacenamiento, horarios de backup y capacidades de snapshot. Prueba la restauración inmediatamente después del primer corte exitoso.

Tres microhistorias corporativas desde el campo

Microhistoria 1: el incidente causado por una suposición errónea (VLAN “por defecto”)

Una empresa SaaS mediana planeó una migración ESXi a Proxmox con lo que parecía una historia de red limpia:
“Todas las redes de VM están etiquetadas VLANs, trunks por todas partes, sin dependencia de native VLAN.” Esa frase debería haber venido con evidencia, pero no la hubo.

Durante el primer corte en producción, la VM arrancó, respondió en su puerto de aplicación desde algunos lugares y estaba completamente inaccesible desde otros.
El equipo on-call vio luces de enlace, configuración IP correcta y un arranque limpio. Hicieron lo clásico: culparon al firewall.
Unos cambios de reglas después, el radio de impacto creció, porque ahora estaban cambiando más variables sin tener la que importaba.

La causa raíz fue brutalmente simple: el port group de ESXi tenía ID de VLAN, pero el switch upstream también tenía una “native VLAN” que llevaba tráfico de gestión,
y algunos sistemas heredados dependían de tramas sin etiquetar que llegaban a la VM a través de una cadena de dispositivos intermedios.
En Proxmox, el bridge era VLAN-aware pero configurado con una lista permitida estricta que descartaba tráfico sin etiqueta.

La solución no fue “hacer que Proxmox se comporte como ESXi” deshabilitando el filtrado. La solución fue documentar qué tráfico debía ir etiquetado,
eliminar la dependencia accidental del comportamiento de native VLAN y luego configurar explícitamente el manejo de tráfico no etiquetado donde realmente se necesitaba.
Después de eso, las siguientes migraciones fueron aburridas. La primera no lo fue.

Microhistoria 2: la optimización que salió mal (thin-on-thin y sorpresa de capacidad)

Un equipo de TI corporativo estaba orgulloso de su eficiencia de almacenamiento. En ESXi usaban VMDKs thin en un array compartido, y “funcionaba bien”.
Al moverse a Proxmox con ZFS, mantuvieron el patrón: VMDK → qcow2 (thin) → ZFS (copy-on-write). Thin por todas partes. Eficiente por todas partes.

Durante unas semanas pareció un acierto. El tiempo de migración fue aceptable, los snapshots eran fáciles y los backups ligeros.
Luego llegó un job trimestral: una carga que escribía y reescribía grandes ficheros en sitio.
Copy-on-write más fragmentación más churn de metadata hizo lo que siempre hace cuando se provoca—la latencia subió y se quedó.

El equipo reaccionó añadiendo más snapshots (“así podemos revertir”). Eso aumentó presión de metadata y espacio.
Luego probaron compresión en datos ya comprimidos. La CPU subió, la latencia empeoró y los usuarios descubrieron nuevas formas de describir la lentitud.

La solución eventual fue aburrida y efectiva: mover discos hot de bases de datos a raw en un dataset dedicado con recordsize sensato,
minimizar frecuencia de snapshots en esos volúmenes y mantener thin donde realmente ayuda (plantillas, entornos dev, servidores de baja rotación).
La eficiencia no es gratis; es un trade-off. La factura llega como latencia.

Microhistoria 3: la práctica aburrida pero correcta que salvó el día (prueba de restauración y disciplina de rollback)

Una organización sanitaria tenía un plan de migración que hacía a algunos ingenieros poner los ojos en blanco: “Cada VM migrada debe pasar una prueba de restauración.”
No “tenemos backups”. No “los backups están en verde”. Una restauración real, arranque y validación en una red aislada.
Sonaba lento. Era lento. También les salvó.

Una VM—un appliance de un vendor antiguo con un bootloader frágil—se importó limpio pero falló en el primer reinicio tras un cambio de configuración.
Nadie había tocado el formato del disco; simplemente no volvió. El vendor culpó a la virtualización. La virtualización culpó al vendor.
El tiempo hizo lo que siempre hace durante un outage: se aceleró.

Como ya habían probado restauraciones en Proxmox, no tuvieron que inventar un procedimiento de recuperación bajo estrés.
Restauraron el último backup conocido a un nuevo VMID, conectaron las NICs con las etiquetas VLAN correctas y el servicio volvió.
La VM original quedó caída para peritaje sin bloquear operaciones orientadas a pacientes.

El postmortem no fue glamuroso. La lección: las pruebas de restauración no son pesimismo, son ensayo.
En entornos regulados, “podemos restaurar” es una capacidad, no una creencia.

Preguntas frecuentes

1) ¿Puedo migrar VMs de ESXi a Proxmox con downtime casi cero?

A veces, pero no de forma genérica. Para un downtime verdaderamente cercano a cero, usa replicación a nivel de aplicación (replicación de BD, sincronización de ficheros, clustering) y corta endpoints.
Los movimientos basados en conversión de disco suelen ser migraciones en frío a menos que introduzcas herramientas especializadas de replicación.

2) ¿Debo usar qcow2 o raw en Proxmox?

Si estás en ZFS o LVM-thin, raw suele ser la base de rendimiento más simple. qcow2 es útil cuando quieres sus características (snapshots internos),
pero puede añadir sobrecarga y complejidad. Escoge un estándar por clase de almacenamiento y no mezcles a la ligera.

3) ¿Cuál es la forma más limpia de manejar VLANs en Proxmox?

Un bridge VLAN-aware (vmbr0) en el trunk uplink y luego poner la etiqueta VLAN por NIC de VM. Escala, es explícito y conceptualmente refleja cómo funcionan los port groups.

4) ¿Necesito un clúster Proxmox para empezar?

No. Un nodo único está bien para un piloto. Pero si esperas migrar VMs entre nodos más adelante, planifica compatibilidad de CPU, almacenamiento compartido (o replicación)
y red consistente desde el inicio.

5) Mi VM Windows no arranca tras la importación. ¿Qué reviso primero?

Firmware (UEFI vs BIOS), luego controlador/bus de disco. Si cambiaste a VirtIO antes de instalar drivers, revierte a un controlador compatible, arranca, instala drivers y cambia de nuevo.

6) ¿Cómo estimo el downtime por VM?

Mide throughput de transferencia (iperf y rsync real), luego calcula: bytes del disco / bytes por segundo sostenidos + tiempo de conversión + arranque/validación.
Añade margen para sorpresas. Si intentas meter un movimiento de 2 TB en una ventana de 30 minutos, las matemáticas te dirán públicamente que no.

7) ¿Puedo mantener la misma IP y MAC?

Puedes mantener IPs si la VLAN/subred permanece igual. Las MACs se pueden fijar manualmente en Proxmox si es imprescindible,
pero hazlo solo cuando una licencia o política lo requiera; de lo contrario deja que Proxmox asigne y actualiza dependencias.

8) ¿Qué pasa con los snapshots durante la migración?

Colapsa o elimina snapshots innecesarios en ESXi antes de exportar/copiar. Las cadenas de snapshots ralentizan exportes e incrementan riesgo.
En Proxmox, establece una nueva política de snapshots/backups tras la estabilización; no importes equipaje viejo de snapshots salvo que haya una razón fuerte.

9) ¿Es seguro migrar y además “actualizar” hardware virtual (UEFI, VirtIO, nuevo modelo NIC)?

Es seguro cuando puedes permitirte depurar dos veces. Para sistemas críticos, migra primero con cambios mínimos, demuestra estabilidad y luego moderniza en una segunda ventana de cambios.

10) ¿Cuál es la validación mínima tras el corte?

Arranque, IP/subnet/gateway/DNS correctos, sincronización horaria, comprobaciones de salud de la app, logs suficientemente limpios para ver nuevos errores, monitorización y un job de backup exitoso (o al menos una copia manual).

Conclusión: pasos prácticos siguientes

Haz la migración como operador, no como apostador. Construye una línea base aburrida de Proxmox, inventaría el estate ESXi con intención,
y trata VLANs y elecciones de firmware/controlador de disco como datos de migración de primera clase, no como “detalles que arreglaremos después de que arranque”.

Pasos siguientes que rinden inmediatamente:

• Elige una VM piloto y ejecuta la ruta completa de migración en frío end-to-end, incluyendo prueba de backup y restauración.
• Estandariza un patrón de red (bridge VLAN-aware) y un patrón de almacenamiento (raw en ZFS o LVM-thin) para la mayoría de VMs.
• Escribe una hoja de corte por VM: firmware, bus de disco, etiqueta VLAN, plan de IP, pasos de validación del propietario, pasos de rollback.
• Programa migraciones en lotes que coincidan con throughput medido y latencia de almacenamiento, no con matemáticas de calendario deseadas.

Cuando termines, el mejor cumplido que puedes recibir es el silencio: no tickets, no “se siente más lento”, no fantasmas VLAN misteriosos.
Solo cargas haciendo su trabajo, en una plataforma que puedes explicar en una pizarra sin pedir disculpas.