La conversación de migrar a Proxmox casi siempre empieza por el licenciamiento. Broadcom subió, el presupuesto no, alguien pide números. Los números salen bien —el ahorro es real— y el proyecto se aprueba.
Y entonces aparece la pregunta que nadie hizo en la junta: ¿a dónde se mueven las máquinas mientras conviertes el primer servidor?
Si tus hosts corren al 80% de memoria, la respuesta es que a ningún lado. Y el proyecto que ya se aprobó no se puede ejecutar como se planteó.
Un host es ESXi o es Proxmox, nunca los dos
No hay convivencia. Un servidor arranca un hypervisor y solo uno. Para convertir un host a Proxmox tienes que formatearlo, y para formatearlo tienes que vaciarlo antes.
Todo lo demás de una migración es un problema resoluble: la conversión de discos, los drivers VirtIO, el rediseño de las redes, la sustitución de vCenter. Todos tienen procedimiento y todos los hemos hecho. Este no es un problema. Es una restricción física, y se resuelve con hardware o no se resuelve.
La aritmética que decide el proyecto
Cuando vacías un host de un clúster de N, su carga tiene que repartirse entre los N−1 que quedan. Eso solo cabe si el uso por host está por debajo de (N−1)/N:
- 1 host — cero. Nunca se puede.
- 2 hosts — hay que estar por debajo del 50%.
- 3 hosts — por debajo del 66%.
- 4 hosts — por debajo del 75%.
- 5 hosts — por debajo del 80%.
Tres hosts al 80% son 240% de carga, y dos hosts dan 200%. No cabe, y no hay configuración que lo arregle.
Fíjate en la dirección del número, porque es contraintuitiva: el umbral sube con el tamaño del clúster. Un clúster de ocho nodos se vacía casi solo. Uno de dos o tres —que es la forma de casi toda la infraestructura industrial y de empresa mediana en México— casi nunca puede.
Y ojo con qué número usas. Para este cálculo sirve el promedio, pero si tus hosts se alarman en picos del 95%, la holgura real es menor que la que arroja el promedio. El pico es el que te va a encontrar a mitad de la migración.
Por qué la memoria y no el CPU
El CPU se sobresuscribe repartiendo tiempo. Cuatro vCPU por núcleo físico es normal y nadie se entera, porque los procesos se turnan en microsegundos.
La memoria no se turna. O está asignada o no está. Cuando se acaba, el hypervisor intenta recuperarla —ballooning, compresión, deduplicación de páginas— y cuando eso no alcanza, pagina a disco. Paginar la memoria de una máquina de producción a disco es una caída con pasos intermedios.
Por eso todo el dimensionamiento de una migración se hace sobre memoria. Nosotros lo tratamos igual al dimensionar CPU, RAM y disco para virtualizar: el CPU rara vez es el que te detiene.
Y una advertencia hacia el otro lado. La densidad de memoria que consigues hoy en ESXi no está garantizada en Proxmox: las dos plataformas reclaman memoria de forma distinta. Dimensiona el destino sobre consumo real más holgura, nunca sobre la sobresuscripción que ya traes.
Las cuatro fases, y dónde está el valor
Con holgura suficiente, una migración avanza por rotación:
- Punto de partida. Todos los hosts en ESXi, todas las cargas arriba.
- Liberar. Las máquinas de un host se mueven a los demás. Ese host queda vacío.
- Convertir. Se formatea, se instala Proxmox, se valida. Los otros hosts siguen intactos.
- Repetir. El clúster Proxmox crece mientras el de VMware se encoge, hasta que no queda nada del origen.
La fase que vale es la tercera, y no por lo que construye. Mientras el primer nodo Proxmox se levanta, los hosts ESXi que quedan siguen intactos y siguen corriendo. Si algo sale mal —un arreglo que no monta, una VM que no arranca, un driver que no convierte— el camino de regreso existe y está caliente.
Esa es la única fase que compra reversibilidad. Y solo existe si hay dónde aterrizar.
El caso de un solo host
Sin holgura, la fase de liberar desaparece y la secuencia se convierte en otra cosa: respaldar todo, formatear el único host que tienes, instalar Proxmox, restaurar.
Eso no es una migración. Es una restauración a ciegas con la producción detenida de principio a fin, y sin nada a qué volver si falla, porque el origen ya no existe: lo formateaste tú.
Ahí es donde el backup que nunca se probó restaurando deja de ser una métrica de madurez y se vuelve el único plan que tienes. Si nunca has restaurado ese respaldo completo, no sabes si tienes un plan o una carpeta de archivos.
Qué hardware hace falta, y de qué tamaño
Dos números, y ninguno es el que la gente supone.
Memoria: la carga de un host, no la del clúster. Tres hosts de 256 GB corriendo al 82% necesitan una zona de aterrizaje de unos 210 GB. Es lo que pesa el host que vas a vaciar, no la suma de todo.
Almacenamiento: lo usado, no lo provisionado. Y el rango va de una oleada al total, según se pueda liberar el arreglo original por etapas. Si tienes almacenamiento compartido, vaciar un host mueve cómputo y los discos se quedan donde están —pero el destino Proxmox necesita almacenamiento propio de todos modos, porque no puede montar el VMFS mientras ESXi lo tenga tomado. Sobre esa decisión escribimos aparte en Ceph contra almacenamiento compartido en Proxmox.
Un tercer número que conviene fijar antes de empezar: si el destino lleva Ceph, necesitas tres nodos para producción. Eso define la forma del clúster final desde el día uno, no al final. Está desarrollado en qué necesitas de verdad para un clúster Proxmox en alta disponibilidad, y la decisión de fondo —arreglo o hiperconvergencia— en hiperconvergencia contra servidores y SAN.
La salida obvia es comprar hardware. El problema es que es hardware para tres meses: una vez que el último nodo queda en producción, esa caja sobra.
Por eso en nuestras migraciones de VMware a Proxmox VE lo enviamos nosotros. Uno o dos DL380 Gen10 con 256 GB de memoria y una Synology con 48 TB disponibles, en sitio antes de que arranque la migración y de regreso cuando el último nodo entra a producción. El cliente no compra fierro para tirarlo.
Lo que no prometemos
La cabina temporal casi seguro rinde menos que tu SAN de producción. La zona de aterrizaje sostiene la operación; no la sostiene igual. Eso se mide antes y se dice antes, no se descubre en la semana dos.
Tampoco elimina la ventana de mantenimiento. La reduce y —esto es lo que importa— la vuelve reversible. Sigue habiendo cortes por oleada, y siguen teniendo que caber en las ventanas que tu operación permite.
Y durante la fase de conversión esa caja prestada es tu producción. Por eso enviamos dos cuando el tamaño lo justifica: un solo punto de falla sosteniendo toda la operación de un cliente no es una posición cómoda para nadie, empezando por nosotros.
Cómo saber en qué caso estás
Necesitas tres números que están a la vista en tu consola: cuántos hosts, cuánta memoria total, y a qué porcentaje promedio corren. Con eso sale el umbral y sale el dimensionamiento.
Nuestro VMware Migration Assessment lo calcula y te dice, con número, si necesitas zona de aterrizaje y de qué tamaño. Es gratuito y no pide registro para ver el resultado.
Si vas a ejecutar la migración por tu cuenta, el checklist para migrar de VMware a Proxmox sin drama cubre el resto del procedimiento, y en Proxmox VE para empresas está el panorama de la plataforma.
Pero calcula el umbral primero. Es el único número que puede convertir un proyecto aprobado en un proyecto que no se puede hacer, y es mejor saberlo antes de firmar que a mitad de la primera ventana.
Preguntas frecuentes
help ¿Cuánta holgura de memoria hace falta para migrar de VMware a Proxmox?
Para vaciar un host de un clúster de N, su carga tiene que repartirse entre los N−1 restantes, así que el uso de memoria por host debe estar por debajo de (N−1)/N. Con dos hosts es 50%, con tres 66%, con cuatro 75% y con cinco 80%. Con un solo host el umbral es cero: nunca se puede vaciar. Tres hosts al 80% suman 240% de carga contra 200% de capacidad en dos, y no hay configuración que lo arregle.
help ¿Por qué el límite lo marca la memoria y no el CPU?
El CPU se sobresuscribe repartiendo tiempo: cuatro vCPU por núcleo físico es normal y nadie lo nota. La memoria no se turna, o está asignada o no está. Cuando se agota, el hypervisor recupera con ballooning y compresión, y cuando eso no alcanza pagina a disco, que en producción es una caída con pasos intermedios. Además, la densidad de memoria que se logra en ESXi no está garantizada en Proxmox: conviene dimensionar el destino sobre consumo real más holgura.
help ¿Se puede migrar a Proxmox si solo tengo un servidor?
No con reversibilidad. Un host arranca ESXi o Proxmox, nunca los dos, así que con un solo servidor no hay a dónde mover las cargas mientras se convierte. La secuencia queda en respaldar, formatear, instalar y restaurar: toda la ventana es paro y no hay a qué volver si la restauración falla, porque el origen ya se formateó. La salida es habilitar hardware temporal donde aterricen las cargas durante la conversión.
help ¿Qué tamaño debe tener el hardware temporal de una migración?
La memoria se dimensiona sobre la carga de un host, no del clúster: tres hosts de 256 GB al 82% necesitan unos 210 GB. El almacenamiento se dimensiona sobre lo usado y no sobre lo provisionado, en un rango que va de una oleada al total según se pueda liberar el arreglo original por etapas. Si el destino lleva Ceph, se necesitan tres nodos para producción, y eso define la forma del clúster final desde el inicio.
help ¿El entorno temporal degrada el rendimiento durante la migración?
Normalmente sí. Una cabina temporal rinde menos que una SAN de producción, así que la zona de aterrizaje sostiene la operación pero no la sostiene igual. Es una degradación medible que conviene cuantificar antes de arrancar y no descubrir a mitad del proyecto. A cambio compra reversibilidad: mientras el primer nodo Proxmox se levanta, los hosts originales siguen intactos y el camino de regreso existe.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →