¿Dónde está vMotion? La verdadera curva de aprendizaje al pasar de VMware a Proxmox
La pregunta de migración con la que empieza todo
Cuando los administradores de VMware empiezan a explorar Proxmox, la conversación casi siempre arranca con la misma pregunta: ¿qué sustituye a las funciones de VMware de siempre, como vMotion, los switches distribuidos, DRS y la red del clúster?
En los entornos VMware, esas herramientas determinan cómo diseñan los administradores la infraestructura. Quítalas y cambia todo el modelo mental.
Hace poco, un ingeniero retrató justo ese momento mientras planificaba la transición de ESXi y vCenter a Proxmox. Su entorno iba a tener tres o cuatro hosts, y uno de los nodos llevaba hardware especializado que necesitaba passthrough PCIe. Como esas VMs dependen de dispositivos físicos, moverlas entre hosts podía causar problemas serios.
La pregunta del ingeniero era sencilla pero reveladora: ¿esos hosts deberían ir igualmente a un clúster, o convenía diseñar la infraestructura de otra manera? Eso desató una discusión sorprendentemente detallada sobre cómo aborda Proxmox la virtualización en comparación con VMware.
La migración en vivo existe, con otra filosofía
Una de las primeras respuestas despejó la mayor preocupación: sí, Proxmox admite migración en vivo. Las máquinas virtuales y los contenedores pueden moverse entre hosts de un clúster sin apagarse, de forma muy parecida a vMotion de VMware. Eso sí, la capa de automatización se comporta de otra manera.
En los entornos VMware, Distributed Resource Scheduler analiza constantemente el uso de recursos de los hosts y puede reequilibrar las cargas de trabajo automáticamente. Proxmox sigue un enfoque más ligero. Cluster Resource Scheduling, que los administradores suelen llamar CRS, se centra sobre todo en los eventos de alta disponibilidad y no en una optimización constante. Los administradores suelen crear grupos de prioridad de hosts y colocar las VMs en los nodos a propósito, y después el clúster mantiene la disponibilidad durante los fallos sin ir moviendo cargas de trabajo según la presión de CPU o de memoria.
A algunos ingenieros les gusta esta sencillez, y otros echan de menos el equilibrado automático de VMware. Solo esa diferencia ya suele marcar cómo diseñan los equipos sus clústeres Proxmox.
Los switches distribuidos se convierten en un rompecabezas de red
La red se convirtió enseguida en el segundo gran tema. Los administradores de VMware suelen apoyarse en los vSphere Distributed Switches para gestionar de forma centralizada las VLAN, los grupos de puertos y la configuración de red en varios hosts, y Proxmox no replica esa función tal cual.
Proxmox monta la red sobre primitivas de Linux como los bridges, el bonding y, de forma opcional, configuraciones de Open vSwitch. Para quien espera una "interfaz de switch" centralizada, esto puede resultar extraño al principio.
Varios ingenieros apuntaron que el sistema Software Defined Networking de Proxmox es lo más parecido. Los administradores crean una zona SDN, la asocian a un bridge de Linux compartido entre hosts y luego definen redes virtuales, llamadas VNets, que representan redes individuales respaldadas por VLAN. Una vez aplicada la política SDN, esas redes aparecen en todos los hosts del clúster.
En la práctica, las VNets funcionan de forma muy parecida a los grupos de puertos de VMware. Quien crea la VM simplemente elige la red que quiere al conectar una tarjeta de red virtual.
Algunos ingenieros siguen prefiriendo Open vSwitch
No todo el mundo estuvo de acuerdo en que SDN sea el mejor enfoque. Otro ingeniero sostuvo que Open vSwitch podría encajar mejor en organizaciones que gestionan muchísimas VMs o configuraciones de VLAN complejas. En ese modelo, las VLAN se configuran directamente en la capa del switch y no a través de la abstracción SDN de Proxmox.
Su razonamiento era sencillo. Algunos entornos tienen miles de VMs, y configurar las etiquetas VLAN una por una a nivel de VM se vuelve tedioso, así que un modelo de switch más tradicional puede reducir el trabajo operativo.
Esa opinión apunta a algo importante de la red en Proxmox: pueden funcionar varias arquitecturas, y no hay un único modelo prescrito.
La capa de red de Linux sigue a la vista
Otra parte de la discusión mostró cuánto influyen los conceptos de red de Linux en la infraestructura de Proxmox.
Un ingeniero describió un entorno de producción con seis interfaces físicas. Dos puertos de 1Gb iban en bond para el tráfico de gestión y conectados a switches distintos para tener redundancia. Dos interfaces de 25Gb llevaban el tráfico troncal de las máquinas virtuales, con varias VLAN, y otro par de conexiones de 25Gb estaba dedicado al almacenamiento compartido.
Su cadena de red iba de la interfaz física al bond de Linux, luego a la VLAN de Linux y después al bridge de Linux. Una vez configurado eso, quien crea las VMs simplemente elige el bridge que corresponde a la red que quiere.
El sistema funciona bien, pero exige a los administradores entender los fundamentos de red de Linux más a fondo de lo que piden muchos entornos VMware.
El passthrough de hardware añade otra restricción
La preocupación original sobre el passthrough PCIe también recibió respuestas prácticas. Las máquinas virtuales que usan passthrough de dispositivos con VFIO, como GPUs o tarjetas de red especializadas, no pueden migrar fácilmente entre hosts sin apagarse, y esa limitación existe en la mayoría de los hipervisores.
La solución propuesta era sencilla: dejar esas VMs fuera de las reglas de migración de alta disponibilidad. El clúster puede seguir gestionando los hosts con normalidad mientras las VMs que dependen del hardware se quedan fijadas a sus nodos concretos. Los administradores pueden seguir configurando el orden de arranque, los arranques retrasados y el comportamiento al apagar a nivel de host.
No difiere en lo esencial de cómo tratan cargas parecidas muchos entornos VMware.
La arquitectura de almacenamiento sigue condicionándolo todo
Otro ingeniero señaló que la arquitectura de almacenamiento puede ser, al final, lo que decida si tiene sentido montar un clúster.
La migración en vivo funciona mejor cuando varios hosts comparten el acceso a los mismos discos de VM. En los entornos VMware, eso suele significar almacenamiento SAN o NAS. Los entornos Proxmox a menudo sustituyen los appliances SAN por sistemas de almacenamiento distribuido como Ceph, donde los mismos nodos que ejecutan las máquinas virtuales aportan discos a un pool de almacenamiento compartido. El clúster replica los datos entre nodos automáticamente, así que las VMs pueden moverse entre hosts sin hardware de almacenamiento centralizado.
Ceph trae sus propias consideraciones de diseño, ya que el ancho de banda de la red, el equilibrio de los discos y la salud del clúster quedan muy ligados. Para equipos acostumbrados a entornos basados en SAN, ese cambio puede exigir otra mentalidad.
Lo que enseñó de verdad la discusión
Lo que empezó como una pregunta sencilla sobre switches distribuidos acabó cubriendo casi todas las partes centrales de una infraestructura de virtualización: migración en vivo, planificación del clúster, modelos de red, arquitectura de almacenamiento y passthrough de hardware.
También mostró que muchas de las funciones de las que dependen los administradores de VMware siguen existiendo en Proxmox. Están implementadas de otra forma y a menudo dejan ver más de la base Linux que hay debajo de la plataforma. VMware esconde la complejidad detrás de abstracciones pulidas, mientras que Proxmox deja a la vista las piezas.
A algunos ingenieros esa transparencia les da más control. Para otros, supone una curva de aprendizaje que va más allá de cambiar un hipervisor por otro.