Migración de VMware a Proxmox: clústeres de dos nodos y Fibre Channel
Un equipo de TI que gestiona 10 clústeres y 21 hosts en sedes de todo el mundo está migrando toda su infraestructura VMware a Proxmox, y por el camino se encuentra con limitaciones de arquitectura y complicaciones de almacenamiento que no aparecen en la documentación de los fabricantes.
La infraestructura no es pequeña: 10 clústeres repartidos por ubicaciones de todo el mundo, 21 hosts en total y cargas de trabajo de producción gestionadas desde un único vCenter. El almacenamiento varía según la sede (cabinas Pure Storage, Dell PowerStore, Dell Unity), con algunas conectadas por Fibre Channel y otras por iSCSI.
El entorno fue evolucionando con el tiempo en lugar de seguir un plan de arquitectura unificado. Presupuestos de hardware distintos, la autonomía de cada sede y sucesivas generaciones de servidores crearon lo que un ingeniero describió como "el habitual mosaico empresarial".
Ahora el plan es pasarlo todo a Proxmox con la ayuda de una empresa colaboradora. Pero el equipo interno es nuevo en la plataforma y las preguntas se acumulan.
Los clústeres de dos nodos complican el quórum
VMware maneja clústeres de dos nodos sin problema, mientras que Proxmox exige una planificación más cuidadosa. Proxmox usa corosync para el quórum del clúster, y dos nodos solos crean riesgo de split-brain. Si un nodo falla, el host que queda no tiene quórum y no puede realizar operaciones de clúster.
La propuesta actual consiste en añadir una Raspberry Pi como dispositivo de quórum en cada clúster. Proxmox admite dispositivos de quórum externos, así que técnicamente es válido. Sin embargo, varios ingenieros cuestionaron el enfoque y sugirieron consolidar en clústeres de 3 a 7 nodos. Con 21 hosts en total, las cuentas salen.
El obstáculo es la geografía. Las sedes están repartidas por el mundo y las cargas de trabajo tienen que seguir siendo locales por motivos de latencia. El almacenamiento Fibre Channel no se extiende entre continentes, lo que descarta un único clúster consolidado.
"A veces no diseñas desde cero. Heredas", dijo un ingeniero.
La configuración del almacenamiento exige saber Linux
El almacenamiento, más que la computación, es el aspecto más complejo de la migración. La mezcla incluye cabinas Pure Storage, Dell PowerStore y Dell Unity, con IBM FlashSystem en algunos entornos. Algunas ubicaciones usan Fibre Channel a 16Gb y otras usan iSCSI con varias rutas activas. Aquí Proxmox se comporta de forma distinta a VMware.
La gestión de LVM pasa a ser necesaria
Con Proxmox, los LUN de Fibre Channel suelen requerir LVM (Logical Volume Manager). Eso significa que los administradores tienen que entender los comandos pvcreate, vgcreate, lvcreate, lvs y vgs.
Para equipos acostumbrados a la capa de abstracción de vCenter, esto supone un cambio. VMware oculta gran parte de la pila de almacenamiento Linux subyacente, y Proxmox la deja a la vista.
Un ingeniero que usa IBM FlashSystem sobre Fibre Channel de 16Gb dijo que "funcionó de maravilla, después de saber cómo funciona LVM". La salvedad es importante.
El thin provisioning confunde al monitoreo
En las cabinas Pure Storage, los LUN tienen thin provisioning y deduplicación a nivel de SAN, pero LVM, en el lado de Proxmox, los muestra como totalmente asignados.
El panel de Proxmox indica una asignación del 100% mientras la SAN muestra que el uso real sigue siendo bajo gracias a la deduplicación y al thin provisioning. Si no se entiende esta discrepancia, la planificación de capacidad se complica y pueden saltar falsas alarmas.
La configuración multipath debe ir antes del acceso a los LUN
Tanto con iSCSI como con Fibre Channel, la configuración de E/S multipath importa. Si MPIO no está configurado antes de reclamar los LUN en los nodos de Proxmox, pueden aparecer IDs de LUN duplicados.
Los ingenieros recomiendan automatizar con scripts la configuración de MPIO, aplicarla a cada nodo antes de acceder a cualquier LUN y convertirlo en procedimiento estándar. Cada LUN nuevo requiere una entrada WWID en la configuración de MPIO de cada nodo.
En los despliegues con varias NIC de almacenamiento activas, los ingenieros insistieron en probar escenarios de fallo desactivando un puerto para verificar que la E/S continúa.
Enfoques de migración: herramienta de importación o restauración desde copia
Proxmox incluye una herramienta de importación para VMs de VMware. Funciona montando el almacenamiento de ESXi a través de los hosts ESXi e importando VMs apagadas. Para VMs pequeñas funciona de forma aceptable. Para cargas de trabajo de producción grandes, algunos ingenieros dicen que es lenta.
Muchos equipos usan Veeam en su lugar: hacen copia de seguridad de la VM desde VMware, la restauran directamente en Proxmox, la encienden y, si hace falta, migran el almacenamiento después. Este enfoque es más rápido, conocido y ofrece una estrategia de marcha atrás.
"Cuando tocas producción en sedes de todo el mundo, la velocidad está bien. La seguridad está mejor", dijo un ingeniero.
Hay que desinstalar VMware Tools antes de migrar
No desinstalar VMware Tools antes de migrar VMs Windows puede crear problemas. El desinstalador puede fallar cuando la VM ya no está en ESXi, lo que deja un VMware Tools roto en la VM de Proxmox.
La secuencia correcta:
- Desinstalar VMware Tools
- Instalar los drivers VirtIO
- Instalar el agente QEMU
- Apagar la VM
- Convertir
- Encender en Proxmox
Siguiendo este proceso, las VMs suelen adaptarse al cambio de hipervisor sin problemas. Saltarse pasos puede suponer tener que limpiar drivers en el peor momento.
La configuración de red cambia tras la migración
Cuando las VMs pasan de VMware a Proxmox, cambia el hardware de la NIC virtual, y los sistemas operativos invitados a menudo lo tratan como hardware nuevo. Las configuraciones de IP estática pueden desaparecer. Windows puede asignar una interfaz nueva, y Linux puede cambiar los nombres de las interfaces.
El problema es predecible pero no evidente. Planificar la reconfiguración de red posterior a la migración, incluido documentar qué VMs tienen direcciones estáticas, evita confusiones cuando las VMs parecen perder la conectividad de red después de migrar.
Se prevé un despliegue de prueba de concepto
El equipo no planea una migración completa inmediata. Primero se desplegará un clúster de prueba de concepto, seguido de un entorno de preproducción y de migraciones controladas.
Aquí ese enfoque es una necesidad. Incluso con el apoyo de la empresa colaboradora e ingenieros con experiencia, Proxmox funciona de forma distinta a VMware. Pone Linux en primer plano y exige que los administradores asuman una parte mayor de la pila.
La arquitectura del clúster sigue en discusión
Hay una cuestión de arquitectura sin resolver: ¿debería el entorno usar menos clústeres y más grandes, o mantener clústeres agrupados por SAN, generación de hardware y geografía?
Menos clústeres y más grandes son más fáciles de gestionar y de actualizar de forma coherente. Pero con sedes repartidas por el mundo, los clústeres locales mantienen las cargas de trabajo cerca e impiden que la latencia de la WAN afecte al comportamiento de la HA. También aíslan el riesgo.
Un ingeniero señaló que los clústeres grandes concentran el riesgo durante las actualizaciones importantes. Si los 21 hosts están en un solo clúster y una actualización de Proxmox da problemas, todas las VMs se ven afectadas. Los clústeres más pequeños permiten actualizaciones escalonadas, probando primero en los clústeres menos críticos.
No hay una respuesta universal; la elección depende de entender las contrapartidas.
El cambio de plataforma refleja prioridades empresariales distintas
Esta migración supone pasar de un ecosistema comercial y muy abstraído a una plataforma abierta, transparente y nativa de Linux, lo que la convierte en algo más que un cambio de hipervisor. Los administradores ven más del sistema, configuran más componentes directamente y están más cerca de la infraestructura. A algunos equipos eso les da más autonomía, y a otros les resulta incómodo.
En entornos donde los costes de hardware importan, los modelos de licencias cambian y la flexibilidad es cada vez más importante, Proxmox se está consolidando como una plataforma empresarial viable, sobre todo cuando se despliega sobre almacenamiento empresarial como SAN de Pure Storage y Dell.
Consideraciones técnicas
Los equipos que planeen migraciones parecidas deberían vigilar:
- Decisiones de diseño del clúster tomadas antes de migrar, no después
- Configuración de MPIO antes de reclamar ningún LUN
- Cómo presenta LVM el almacenamiento con thin provisioning
- Desinstalación de VMware Tools antes de la conversión
- Instalación correcta de VirtIO y del agente QEMU
- Cambios de hardware en los adaptadores de red
- Pruebas de fallo de las rutas de almacenamiento
- Despliegue de una prueba de concepto
Nada de esto es glamuroso, pero es lo que separa una migración con éxito de una resolución de problemas de emergencia.
Dejar atrás una infraestructura consolidada
Los equipos que hacen esta transición muestran una confianza calculada, basada en el riesgo evaluado y no en un optimismo ciego. Proxmox ha dejado atrás la fase experimental y ejecuta cargas de trabajo de producción sobre almacenamiento empresarial en despliegues serios.
Aun así, sacar 10 clústeres repartidos por el mundo de una plataforma que ha sido la columna vertebral de la infraestructura durante años exige una preparación cuidadosa. Revisa tus procedimientos dos veces, asegúrate de que hay supervisión y luego ejecuta. En 2026, con los cambios de licencias de VMware impulsando las decisiones de migración, quedarse con la infraestructura existente no siempre es la opción de menor riesgo.