Migramos nuestra operación de VMware a Proxmox: los tropiezos reales

La conversación sobre salir de VMware dejó de ser teórica. Nosotros la resolvimos en nuestra propia casa: apagamos el host de vSphere donde vivía toda la operación interna de IT Experts y hoy corre sobre Proxmox VE 9.2. No es un laboratorio ni una prueba de concepto: son los servidores con los que trabajamos todos los días, incluido el sistema que publica este artículo.

Esto no es una guía de "cómo migrar". Es la lista de lo que de verdad nos tropezó, con los números reales, porque ninguno de esos tropiezos aparece en la documentación del fabricante y todos aparecen a las dos de la mañana.

¿Cuánto downtime implica realmente mover una VM?

Mucho menos del que se planea. Para el servidor de nuestro CMS reservamos una ventana de cuatro horas de madrugada y la migración tomó minutos.

La razón es que el tamaño que importa no es el del disco virtual, sino el ocupado. Ese servidor tiene un disco de 480 GB aprovisionados y el sistema de archivos usa 13 GB. El importador de Proxmox trae los bloques que existen, no el contenedor vacío.

La lección práctica: antes de negociar la ventana con el negocio, revisa cuánto está ocupado de verdad. Nos pasó lo contrario también, y va en el siguiente punto.

¿Puedes confiar en lo que te dice el inventario de vCenter?

No del todo, y conviene descubrirlo antes y no durante. En nuestro caso, vCenter reportaba el disco de una VM como 0 KB, y al abrir el editor de configuración de otra mostraba 0 MB, con un error que impedía guardar. Conectando directo al host ESXi, el mismo disco aparecía con su tamaño correcto.

Era un problema de caché del inventario, no de los discos. Pero por unas horas nos hizo creer que había una falla de almacenamiento, y sobre esa confusión estuvimos a punto de dimensionar mal la migración.

La regla que sacamos: la fuente de verdad es el host o el sistema operativo invitado, nunca la vista agregada. Un lsblk dentro de la VM resolvió en cinco segundos lo que la consola no aclaraba.

¿Qué es lo primero que se rompe al arrancar en el otro hipervisor?

La red, y por una razón tonta: el nombre de la interfaz cambia. En VMware el adaptador se presentaba como ens33; en Proxmox, con virtio, aparece como ens18. Si la configuración de red nombra la interfaz vieja, el servidor arranca sin IP y solo se rescata por consola del hipervisor.

Se arregla antes de apagar, dejando la configuración atada a un patrón en vez de a un nombre fijo. En Ubuntu con netplan:

network:
  version: 2
  ethernets:
    lannic:
      match:
        name: "en*"
      dhcp4: false
      addresses: [10.x.x.x/25]
      routes:
        - to: default
          via: 10.x.x.1

Aplicar eso con la VM todavía en el hipervisor viejo no cambia nada: la interfaz actual también cumple el patrón. Y al arrancar del otro lado, la nueva interfaz se toma la configuración sin que nadie intervenga. En nuestro caso, el servidor levantó con su dirección correcta al primer arranque.

¿Por qué los respaldos empiezan a fallar después de migrar?

Aquí hay dos causas, y las dos nos tocaron.

La primera: el agente invitado. Las VMs traían VMware Tools, que en Proxmox no sirve. Sin el agente de QEMU instalado y habilitado, el respaldo no puede congelar el sistema de archivos antes del snapshot, y lo que obtienes es una copia equivalente a jalarle el cable al servidor. Una base de datos normalmente se recupera de eso, pero no es lo que quieres de tu respaldo de producción. En Windows se resuelve con los VirtIO Guest Tools; en Linux, instalando el paquete del agente y habilitando la opción en la VM, lo cual requiere apagado y encendido completo, no un reinicio desde dentro.

La segunda es más sutil y nos costó un día entero de diagnóstico: varias VMs dejaron de poder generar snapshots. No eran las mismas máquinas, no compartían host y no había problemas de espacio. Lo que compartían era una unidad de CD/DVD virtual con una imagen ISO montada desde un recurso de red que ya no existía.

Cuando el hipervisor va a crear un snapshot, valida todos los dispositivos conectados a la VM, incluida esa unidad. Si el archivo no es accesible, la validación falla y tumba la operación completa. El resultado es desconcertante: el respaldo falla en máquinas sanas, sin ninguna relación aparente entre ellas.

Por eso la práctica permanente es desconectar las unidades de CD/DVD de toda VM de producción que no esté en una instalación activa. No cuesta nada y elimina una dependencia invisible. Y si la ISO se necesita, que viva en un almacenamiento estable, no en un servidor que estás por dar de baja.

¿Qué cambia cuando ya tienes clúster?

Con dos nodos y almacenamiento compartido, movimos todas las cargas de un nodo al otro en menos de tres minutos, en caliente y sin cortar servicio. Ese es el momento en que el mantenimiento deja de necesitar ventana: se vacía un host, se le da servicio y se regresan las cargas.

Pero hay un detalle que conviene conocer antes de celebrar: un clúster de dos nodos no tiene quórum si pierdes uno. El nodo sobreviviente queda en minoría, las máquinas siguen corriendo pero el clúster se bloquea para operaciones, y la alta disponibilidad automática no puede actuar con seguridad. Se resuelve con un tercer nodo o con un árbitro externo (QDevice), que puede ser un equipo modesto en otro punto de la red.

Dicho de otro modo: dos nodos te dan migración en vivo y mantenimiento sin downtime, que ya es mucho. La alta disponibilidad real empieza en tres. Lo desarrollamos en qué necesitas de verdad para un clúster en alta disponibilidad.

La revisión de diez minutos que ahorra un día

Esto es lo que revisaríamos en cada VM antes de moverla, con lo aprendido:

¿Qué haríamos igual y qué distinto?

Igual: preparar la configuración de red antes de apagar, migrar primero la carga menos crítica para calibrar tiempos, y mantener el hipervisor viejo encendido unos días como plan de regreso.

Distinto: revisar las unidades de CD/DVD y los agentes invitados antes de migrar, no después del primer respaldo fallido. Son diez minutos de revisión que nos habrían ahorrado un día de diagnóstico.

Si estás evaluando el cambio, el orden que recomendamos está en salir de VMware, por dónde empezar y en el checklist para migrar sin drama. Y cuando termines, no des por bueno el respaldo hasta restaurarlo: un backup que nunca se probó no es un backup.

¿Tienes una migración en puerta y no sabes cuánto downtime pedir? Cuéntanos qué cargas tienes y te decimos qué esperar, con números.