Migrar de VMware a Proxmox: el plan de vuelta atrás caduca solo

En casi todos los planes de migración que nos pasan a revisar hay una línea que dice, más o menos: «si algo sale mal, volvemos a VMware». Y ahí se acaba. No dice a qué se vuelve exactamente, ni quién lo decide, ni con qué datos, ni —sobre todo— hasta cuándo se puede volver. Esa última parte es la que caduca sola, en silencio, mientras el proyecto avanza y todo el mundo sigue creyendo que tiene plan B.

Este post no va de si migrar a Proxmox es buena idea —eso ya lo contamos con los números delante cuando explicamos cómo migramos más de 500 máquinas virtuales—. Va de lo que pasa cuando la migración resulta ser la parte fácil, y de la otra mitad del plan: la que solo se usa en el peor día, la que nadie ensaya y la que se evapora sin que salte ninguna alarma.

«Volver» no es des-migrar

Conviene dejar clara una asimetría que el producto te enseña sin decirlo. Proxmox VE trae un asistente de importación desde ESXi y vCenter integrado en la interfaz web desde la versión 8.2, publicada el 24 de abril de 2024. Está bien hecho: se conecta al datastore como si fuera un almacenamiento más y se trae la máquina entera. Lo que no existe es el botón de al lado. Proxmox no incluye un asistente equivalente para devolver una máquina a ESXi: eso son qemu-img, un OVF montado a mano y un rato largo de trabajo. Dos años y dos ramas después, con la 9.2 encima de la mesa, ese botón sigue sin aparecer.

Por eso el rollback de verdad, el que cabe en una ventana de mantenimiento, consiste en encender otra vez la máquina original, que sigue apagada en su sitio, en el vSphere de siempre. Nada viaja de vuelta. Es un plan sencillo y bueno. Depende de tres cosas que nadie escribe: que esa máquina siga existiendo, que el vSphere siga siendo un sitio al que quieras volver, y que los datos que se han generado mientras tanto tengan a dónde ir. Las tres se van cerrando por su cuenta.

La ventana se cierra por tres sitios

1. El contrato

Aquí hay que separar dos situaciones que la gente mezcla. Si conservas licencia perpetua y lo que se te ha caducado es el soporte (el SnS), Broadcom lo dice en su propio artículo de conocimiento con una claridad que se agradece: «los hosts ESXi y vCenter Server seguirán funcionando con normalidad» y «no hay ningún mecanismo automático de apagado o desconexión que se dispare por la expiración del contrato de soporte». Tu plan B sobrevive. Lo que pierdes es el acceso al portal para descargar «nuevos parches, actualizaciones de seguridad y versiones mayores o menores», y la capacidad de añadir hosts nuevos o hacer una actualización de versión mayor.

Si estás en suscripción —que es donde está ya la mayoría, porque las perpetuas dejaron de venderse—, el vencimiento no es un aviso, es un final. Las guías de licenciamiento que circulan por el canal coinciden en la misma frase: no hay periodo de gracia al vencimiento de la suscripción, y renovar tarde lleva recargo —ChannelWeb lo cifró en 2025 en un 20 % sobre el coste del primer año, aplicado desde la fecha del vencimiento—. Aquí toca ser honestos: no hemos encontrado esa cifra en un documento público de Broadcom, solo en coberturas y en material de distribuidores. Es exactamente el tipo de número que hay que mirar en tu contrato antes de apoyar un plan encima.

2. El hipervisor al que vuelves

Esta es la que más nos preocupa y la que menos aparece en los planes. Un vSphere sin SnS activo se queda congelado en el último parche que pudiste descargar. El primer mes no lo notas. Al tercero, «volvemos a VMware» ya significa «volvemos a un hipervisor que lleva un trimestre sin actualizaciones de seguridad, con las máquinas más críticas de la casa encima». Eso no es un plan de contingencia: es cambiar un riesgo por otro sin haberlo decidido. Si tu plan B tiene fecha, escríbela; y si la fecha ya pasó, deja de llamarlo plan B.

3. El delta de datos

La tercera se cierra en horas, no en meses. Mientras la máquina importada está apagada o en pruebas, el rollback es gratis: apagas una, enciendes la otra, fin. En el momento en que el primer usuario guarda un fichero o el primer pedido entra en la base de datos, volver deja de ser «encender la de antes» y pasa a ser «encender la de antes y reconciliar lo que se ha escrito mientras tanto». Ese cambio de naturaleza ocurre en un instante concreto, y ese instante casi nunca está marcado en el plan. Debería tener hora.

Lo que el asistente no se lleva

El wiki oficial de Proxmox es sorprendentemente franco con los límites de la importación. Merece la pena leerlo entero antes de planificar, porque cada límite de la ida es un motivo de vuelta:

Y por encima de toda la lista, la advertencia que el propio wiki pone en negrita: «asegúrate de que la VM está encendida solo en Proxmox VE o en VMware, pero nunca en los dos a la vez, para evitar la corrupción de disco». Parece obvia leyéndola con calma un martes. No lo es a las dos de la madrugada, cuando algo va mal, hay prisa y la tentación es encender la de VMware «un momento, para comparar».

El rollback de urgencia es el que rompe cosas

La vuelta atrás mal hecha no falla por el disco: falla por todo lo que hay alrededor de la máquina. Enciendes la original en vSphere mientras la nueva sigue arriba en Proxmox y, durante los minutos que tardas en darte cuenta, tienes dos máquinas con el mismo nombre y la misma IP, dos agentes de copia reportando al mismo servidor de backup, dos servicios autenticándose con la misma cuenta y —esta es la mala— dos procesos escribiendo en la misma base de datos remota, que no está en ninguna de las dos y por tanto no protege a nadie. Ninguna de esas cuatro cosas se arregla apagando una de las dos después.

Por eso el paso uno de cualquier vuelta atrás que escribimos no es «arrancar la de VMware». Es apagar la de Proxmox y confirmar que está apagada. En ese orden, siempre, y con una persona que lo confirma en voz alta antes de que nadie toque nada en el otro lado.

Las seis líneas que sí escribimos

Un plan de vuelta atrás no ocupa un documento. Ocupa seis líneas, y si alguna no sabes rellenarla, ese hueco es el hallazgo:

Cuándo te diríamos que no migres todavía

No somos resellers de Proxmox ni de VMware, y no vendemos licencias de ninguna de las dos. Eso nos deja decir lo evidente: hay casos en los que la respuesta correcta es esperar. Si tu renovación queda lejos y no tienes a nadie que vaya a operar el hipervisor nuevo el día después de la fiesta, migrar solo adelanta el problema. Si hay una carga crítica atada a algo de vSphere que no has probado fuera de vSphere, esa carga va la última, no la primera. Y si no consigues escribir el criterio de aborto de la línea 1, no estás listo para migrar: estás listo para hacer una prueba, que es otra cosa y también está bien.

Hay una lectura de fondo que ya hicimos con datos hace unas semanas, cuando revisamos qué ha pasado de verdad dos años después de Broadcom: lo que está ocurriendo no es un éxodo, es una reducción de dependencia por fases. Y una migración por fases se apoya, precisamente, en poder deshacer una fase sin arrastrar las demás. Cuando la vuelta atrás caduca, lo que se acaba es esa posibilidad: a partir de ahí solo quedan olas que van hacia delante.

La línea que no dejamos en blanco

En los planes que escribimos nosotros, la línea 6 no se deja en blanco: lleva por defecto la fecha de la próxima renovación de VMware menos treinta días. El número no tiene nada de mágico —treinta días es lo que tarda en organizarse una ventana de vuelta atrás con gente de verdad y nocturnidad de verdad—, pero obliga a la conversación un mes antes de que la decisión se tome sola. Porque esa fecha existe la escribas o no. Si no la pones tú, la pone el vencimiento de un contrato, un datastore que se queda sin espacio o alguien que necesita reutilizar esos hosts. Y ese día nadie te avisa de que acabas de quedarte sin plan B.

Fuentes: asistente de importación desde ESXi/vCenter y fecha de la versión 8.2 (24-abr-2024) — nota de prensa de Proxmox; límites de la importación (vSAN, discos cifrados, vTPM, snapshots, red, VirtIO en Windows) y la advertencia de no encender la VM en los dos lados — wiki oficial de Proxmox VE; comportamiento de una licencia perpetua tras el vencimiento del SnS y citas literales — artículo 429208 de Broadcom; ausencia de periodo de gracia en suscripción y recargo por renovación tardía (dato de canal, no confirmado en documento público de Broadcom) — ChannelWeb y guías de licenciamiento de distribuidores. Imagen de portada: «One way sign», Karina Carvalho, CC0 1.0, vía Wikimedia Commons.