Respuesta corta: que la VM arranque no significa que esté migrada. Falta validar cuatro cosas: red en capa 2 y 3 con sus reglas de seguridad, rendimiento real del disco, logs de arranque sin errores nuevos, y los procesos críticos de la aplicación funcionando. Recién ahí se puede decir que está en producción.
El error más común de toda migración es confundir "arrancó" con "terminé".
Los cuatro controles
1. Red: capa 2, capa 3 y seguridad
Que tenga IP no alcanza.
- Capa 2: ¿está en la VLAN correcta? ¿La MAC cambió y eso rompe alguna reserva DHCP o licencia atada a MAC?
- Capa 3: ¿el gateway responde? ¿El DNS resuelve? ¿Las rutas estáticas se mantuvieron?
- Seguridad: las reglas de firewall que la protegían, ¿se replicaron? Si venías de NSX con microsegmentación, esto es un trabajo entero.
Un detalle que muerde: al cambiar de vmxnet3 a virtio-net, la interfaz cambia de nombre (eth0 → ens3, por ejemplo). Cualquier configuración que la nombre explícitamente —firewall, scripts, monitoreo— deja de aplicar en silencio.
2. Rendimiento del disco
No lo asumas: medilo, y comparalo contra lo que tenías.
`bash
hdparm -Tt /dev/vda
fio –name=test –rw=randrw –rwmixread=70 –bs=4k \
–size=1G –numjobs=4 –runtime=60 –group_reporting
`
Si el rendimiento está muy por debajo del original, casi siempre es una de tres: el disco quedó en emulación IDE/SATA en vez de virtio, falta el caché adecuado, o el almacenamiento de destino no está configurado como corresponde.
3. Logs de arranque
`bash
journalctl -b -p err # errores del último arranque
dmesg | grep -i -E "error|fail|warn"
systemctl –failed # servicios que no levantaron
`
En Windows: Visor de eventos, sistema y aplicación, filtrando por error en las últimas 24 horas.
Lo que buscás son errores nuevos, que no estaban antes. Por eso conviene tener una captura de estos mismos comandos de la VM original, antes de migrar.
4. La aplicación
Es lo único que le importa al negocio.
- ¿Los servicios están corriendo y escuchando en los puertos correctos?
- ¿Las conexiones a bases de datos externas funcionan?
- ¿Las tareas programadas se ejecutaron?
- ¿Los usuarios pueden hacer lo que hacían?
- ¿Las integraciones con otros sistemas responden?
Esta validación no la hace infraestructura sola: la hace con el dueño de la aplicación.
Lo que se olvida siempre
| Ítem | Por qué muerde |
|---|---|
| Backup | La VM nueva no está en el backup hasta que la agregás. Es lo primero. |
| Monitoreo | Los agentes pueden reportar como host nuevo, o dejar de reportar |
| Licencias atadas a hardware | Cambia la MAC o el UUID y la licencia deja de validar |
| Antivirus | Puede requerir reinstalación o reactivación |
| Documentación | Actualizar la CMDB o la planilla de inventario |
| DNS inverso | Si cambió la IP, revisar el PTR |
| Certificados | Los atados a nombre de host suelen sobrevivir; los atados a hardware, no |
El del backup es el más peligroso: la VM queda corriendo en producción sin respaldo, y nadie se entera hasta que hace falta.
Cuándo apagar la VM vieja
No enseguida. El criterio razonable:
- Día 0: VM nueva en producción, VM vieja apagada pero conservada
- Semana 1: monitoreo intensivo, comparación de métricas
- Semana 2: si no hubo incidentes, backup final de la vieja
- Semana 3-4: recién ahí, baja definitiva
Conservar la VM original apagada es tu rollback más rápido y barato. Borrarla el mismo día es la decisión que más se lamenta.
Preguntas frecuentes
¿Cuánto tiempo de observación conviene?
Dos semanas para cargas normales. Un mes para las críticas, sobre todo si tienen procesos que corren solo a fin de mes.
¿Qué hago si el rendimiento bajó?
Revisá en orden: controlador de disco (¿quedó en virtio?), configuración de caché, modelo de CPU (host-passthrough vs host-model) y el almacenamiento de destino. Casi siempre es el primero.
¿Puedo automatizar esta validación?
Sí, y a escala hay que hacerlo. Un script que chequee servicios, puertos, conectividad y rendimiento, ejecutado después de cada migración, elimina el "se me pasó".
¿Quién declara que está terminada?
El dueño de la aplicación, no infraestructura. Es lo que evita la discusión de "yo la migré bien" contra "no funciona".
En resumen
Reintegrar es más que importar. Cuatro controles —red, disco, logs y aplicación— más la lista de lo que siempre se olvida, con el backup a la cabeza.
Y una regla que vale por todas: la VM vieja se conserva apagada un par de semanas. Es el rollback más barato que vas a tener.
El marco completo de la preparación está en el artículo pilar de esta semana.
4 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.