Migrar a Proxmox: la red no la guarda el clúster, la guarda cada nodo

En una migración de VMware a Proxmox, la conversación siempre empieza por los discos. Cuánto tardan, si el thin se mantiene, qué pasa con las instantáneas. Los discos son la parte fácil: llegan o no llegan, y te enteras el mismo día. Lo que no se ve es otra cosa, y es la que da guerra seis meses después: en vSphere la red virtual es un objeto del centro de datos y en Proxmox VE es un fichero de cada máquina. Te llevas el diseño de red. No te llevas el mecanismo que lo mantenía igual en todos los servidores.

El interés va por delante: vendemos migración de VMware a Proxmox y llevamos infraestructura y redes de clientes. También hemos escrito cuándo no migrar, así que aquí no hay entusiasmo que vender. El tema toca ahora por una razón de calendario: la tabla de ciclo de vida de Proxmox fija el fin de soporte de Proxmox VE 8 en agosto de 2026 —el mes, sin día—, y eso ha llenado el verano de gente moviendo máquinas con prisa, de VMware o de una rama a otra. Ya avisamos de que esa caducidad no te la va a decir apt. La de hoy tampoco te la dice nadie.

El fichero que el clúster no replica

Empecemos por la frase que lo explica todo, en el capítulo de configuración de red de Proxmox: «la configuración se puede hacer a través de la interfaz gráfica, o editando manualmente el fichero /etc/network/interfaces, que contiene toda la configuración de red». Toda. La de ese nodo. Y para que no quede duda de que no es un descuido de una plataforma sin clúster, Proxmox VE sí tiene un sistema de ficheros de clúster: pmxcfs, «un sistema de ficheros basado en base de datos para almacenar ficheros de configuración, replicados en tiempo real a todos los nodos del clúster usando corosync». La documentación lista lo que vive ahí: corosync.conf, datacenter.cfg, el cortafuegos, las reglas de alta disponibilidad, los certificados, y la configuración de cada máquina virtual en nodes/<NOMBRE>/qemu-server/<VMID>.conf. /etc/network/interfaces no está en esa lista.

Para medir el cambio conviene recordar de dónde vienes. La documentación de arquitectura del vSphere Distributed Switch dice que «la configuración de red que creas en vCenter Server (el plano de gestión) se empuja automáticamente a todos los host proxy switches (el plano de datos)». Hay un objeto, vive en un sitio, y ese sitio se encarga de que todos los hosts se parezcan a él. En Proxmox ese sitio no lo hereda nadie.

Aquí va una opinión nuestra, y la marcamos como tal porque no está en ninguna documentación: eso no es un olvido, es una decisión sensata. La red del nodo es lo que te permite llegar al nodo. Un fichero que se replica solo y en tiempo real a todas las máquinas es, aplicado a la red, la forma más eficiente inventada de quedarte fuera de un clúster entero con un solo error de tecleo. Proxmox lo deja fuera a propósito, y hasta pone una red de seguridad: «Proxmox VE no escribe los cambios directamente en /etc/network/interfaces; en su lugar escribimos en un fichero temporal llamado /etc/network/interfaces.new», que se aplica cuando tú dices, con el botón Apply Configuration, con ifreload -a o al reiniciar. La decisión es buena. La consecuencia hay que asumirla: lo que el software no sincroniza, lo sincronizas tú.

El nombre del puente es el contrato

En vSphere, la tarjeta de una máquina apunta a un port group: un objeto, con identidad propia, que existe en vCenter. En Proxmox, la línea de la tarjeta en la configuración de la VM es esta:

net0: virtio=BC:24:11:3A:7E:52,bridge=vmbr1,tag=30

vmbr1 es una cadena de texto. No hay ningún objeto detrás, ni un identificador único, ni nada que garantice que el vmbr1 de un nodo sea el mismo vmbr1 del de al lado. Se resuelve en el momento de arrancar, contra el fichero del nodo donde arranca. Y fíjate en el reparto: la referencia sí viaja con el clúster —esa línea está en /etc/pve, replicada en tiempo real— y la cosa referenciada, no. Sobre los nombres, la documentación es generosa hasta ser peligrosa: «normalmente vmbr[N], donde 0 ≤ N ≤ 4094, pero puedes usar cualquier cadena alfanumérica que empiece por un carácter y tenga como máximo 10 caracteres». Diez caracteres para nombrar algo de lo que depende que una máquina vea la red o no la vea.

El fallo caro no es el evidente. El evidente —el puente no existe en el nodo de destino— se manifiesta pronto y molesta poco. El caro es el otro: el mismo nombre en los dos nodos, colgando de sitios distintos. En el nodo A, vmbr1 va sobre el bond de las dos tarjetas de 10 Gb con MTU de 9000. En el nodo B, alguien lo montó en su día sobre una tarjeta suelta de 1 Gb con MTU de 1500, «temporalmente». La VM migra sin quejarse, arranca sin quejarse, y a partir de ese momento va más lenta y pierde paquetes grandes, y nadie relaciona una cosa con la otra porque en el panel se ve exactamente igual.

La lista oficial de requisitos, y lo que no está en ella

Esto se ve mejor mirando lo que Proxmox exige por escrito para una migración en vivo. La sección Requirements del capítulo de máquinas virtuales tiene cinco puntos:

• Que la VM no tenga recursos locales que no se puedan migrar. La documentación concreta cuáles: los dispositivos PCI o USB en passthrough bloquean la migración en vivo, mientras que los discos locales se envían al destino sin problema.
• Que los hosts estén en el mismo clúster Proxmox VE.
• Que haya entre ellos una conexión de red que funcione y sea fiable.
• Que el host de destino tenga versiones de los paquetes de Proxmox VE iguales o superiores.
• Que las CPU sean del mismo fabricante y con capacidades parecidas.

Lee la lista otra vez. El puente no aparece. Y no aparece porque, para el mecanismo de migración, no es un requisito: es un supuesto. La documentación asume que si has montado un clúster, tus nodos se parecen. Es un supuesto razonable el día uno, cuando los tres servidores son idénticos y los instaló la misma persona la misma tarde. Deja de serlo el día que entra un cuarto nodo de otra marca, con otro número de tarjetas, comprado dieciocho meses después.

Y hay un caso en el que ese supuesto no lo compruebas tú: la alta disponibilidad. Las reglas de HA viven en /etc/pve/ha/, o sea, replicadas en todo el clúster; el gestor de HA decide a qué nodo se reinicia una máquina cuando el suyo desaparece, a las cuatro de la mañana y sin preguntar. Lo que decide dónde va la VM es del clúster. Lo que decide si allí tendrá red, no. Ya escribimos que la alta disponibilidad no evita la caída, la acorta; esto es el mismo argumento por otro lado. El failover no vale de nada si la máquina levanta en un sitio donde su VLAN no llega.

La MAC cambia, y de la MAC cuelgan cosas

La guía oficial de migración a Proxmox VE despacha esto en una línea, en el apartado Post Migration: «actualiza la configuración de red. El nombre del adaptador de red lo más probable es que haya cambiado». Es verdad y se queda corta, porque el nombre es la consecuencia y no la causa. La causa está en el capítulo de máquinas virtuales: «Proxmox VE generará para cada tarjeta una dirección MAC aleatoria, para que tu VM sea direccionable en redes Ethernet». La tarjeta no se muda: se fabrica una nueva.

Las reservas de DHCP y las licencias atadas al hardware ya las pusimos en la lista al hablar del plan de vuelta atrás, así que no las repetimos. Lo que aquella lista no decía es lo que importa hoy: que la dirección no se conserva y se vuelve a sortear, así que el que peor lo lleva es el control de acceso por puerto del switch, el 802.1X, donde una MAC nueva no da un error de red sino una negativa de autenticación en un sitio que casi nadie mira durante una migración.

La buena noticia es que la MAC es un parámetro, no un destino. En la definición de net[n] está macaddr=<XX:XX:XX:XX:XX:XX>, y se fija con qm set como cualquier otra cosa. Se decide antes de la migración, con la lista de máquinas que tienen algo atado a la dirección física delante, no después, a base de descubrirlo. Y en el invitado, si es Linux, el nombre de la interfaz cambia porque el dispositivo es nuevo; el mecanismo documentado para clavarlo es un fichero .link de systemd con [Match] MACAddress= y [Link] Name=. La documentación de Proxmox lo explica para las tarjetas del anfitrión, pero el mecanismo es de systemd y es el mismo dentro de un invitado Linux.

La tarjeta que arranca no es la tarjeta que quieres

Proxmox emula vmxnet3, la tarjeta paravirtualizada de VMware, y eso es una bendición el día de la migración: la máquina arranca con red sin tocar el invitado. La documentación es explícita sobre para qué sirve: «vmxnet3 es otro dispositivo paravirtualizado, que solo debería usarse al importar una VM desde otro hipervisor». Sirve para el trayecto y para nada más. Del modelo bueno dice: «el modelo virtio ofrece el mejor rendimiento con muy poca carga de CPU».

El coste de dejarlo «temporalmente» tiene un detalle que se pasa por alto y que sale caro en clústeres con tramas grandes. En la definición del parámetro mtu pone: «fuerza la MTU del dispositivo de red (solo VirtIO). Ponerlo a 1 o dejarlo vacío usará la MTU del puente». O sea que mientras la tarjeta siga siendo vmxnet3, la MTU por interfaz no es tuya: te comes la del puente. Si tienes red de almacenamiento, de copias o de Ceph con tramas de 9000, esa es exactamente la palanca que acabas de perder. Lo mismo pasa con multiqueue, que también es cosa de VirtIO. Así que la conversión se pone en el calendario del proyecto, con fecha, y no en la lista de «algún día».

Sin puente no te quedas sin red: te quedan otras

Este es el que más tiempo hace perder en una migración hecha con prisa por consola o por API, y está documentado literalmente: «si no especificas un puente, creamos un dispositivo de red kvm user (con NAT), que proporciona servicios de DHCP y DNS». Y da las direcciones: 10.0.2.2 de pasarela, 10.0.2.3 de DNS, 10.0.2.4 de SMB, y el DHCP reparte a partir de 10.0.2.15.

Por eso el síntoma no es «la máquina no tiene red». El síntoma es «la máquina tiene IP, resuelve nombres, sale a internet y no la ve nadie», que es el peor sitio donde estar durante una hora a las once de la noche. La regla práctica cabe en una frase: si en una máquina recién importada ves un 10.0.2.x, no busques en el cortafuegos ni en el switch; te falta el bridge=. La documentación añade además que el modo NAT «es mucho más lento que el modo puente y solo debería usarse para pruebas», y que no está en la interfaz web: solo por CLI y API. Lo cual explica bastante bien por dónde entra.

El SDN es la salida, y tiene letra pequeña

Proxmox no ignora nada de esto: para eso está el SDN, y desde la versión 8.1 viene instalado por defecto. La frase que importa es esta: «las configuraciones de SDN de Proxmox VE están en /etc/pve/sdn, que se comparte con todos los demás nodos del clúster a través del sistema de ficheros de configuración de Proxmox VE». Ahí está lo que faltaba. Además tiene cambios pendientes y aplicación conjunta —«los cambios nuevos no se aplican inmediatamente, sino que se registran como pendientes», para desplegarlos «como uno atómico»— y lleva la cuenta de lo desplegado en .running-config y .version. Es el plano de gestión que echabas de menos.

Y ahora la letra pequeña, que es donde se cae la gente que llega buscando el vCenter que ya no tiene. Mira lo que pide una zona de tipo VLAN, que es la que usarás si vienes de port groups con etiqueta: «el puente local u OVS switch, ya configurado en cada nodo, que permite la conexión entre nodos». Es decir: el SDN no elimina el fichero por nodo. Se apoya en él. Lo que hace, y no es poco, es reducir lo que tienes que mantener idéntico a mano a una sola cosa —el puente de abajo— y subir al clúster toda la capa de arriba, las VNets y las VLAN. Pasas de sincronizar veinte líneas por nodo a sincronizar una. Reduce muchísimo el trabajo manual. No lo elimina.

La segunda mitad de la letra pequeña la publica Proxmox en la misma página, en el apartado de estado de soporte, y conviene leerla antes de dibujar la arquitectura: el núcleo del SDN «está totalmente soportado», pero «la IPAM, incluida la gestión de DHCP para invitados virtuales, está en tech preview», y «el enrutado complejo vía FRRouting y la integración del controlador están en tech preview». Traducido a decisiones: la capa de VNets y VLAN, adelante. El DHCP de tus servidores, en el sitio donde ya funciona, no en una vista previa. Y si el diseño se va a QinQ, apunta la aritmética: hacen falta cuatro bytes más por el doble etiquetado, «tienes que reducir la MTU a 1496 si la MTU de tu interfaz física es 1500».

Antes de que suene a que VMware era el paraíso

No lo era. Los hosts de vSphere también se desincronizan del distributed switch; existe un estado documentado por el fabricante para eso, con su artículo de soporte y su mensaje de que la configuración del distributed switch en algunos hosts difería de la del vCenter Server. Cualquiera que haya sacado un host de mantenimiento con el vCenter caído sabe de qué hablamos. La diferencia no es que en VMware no haya deriva: es que en VMware hay contra qué comparar. Existe un objeto que dice cómo debería ser el mundo, así que la deriva tiene nombre, aparece en la interfaz y alguien la ve. En Proxmox no hay objeto. Hay tres ficheros que deberían parecerse. Si no se parecen, no hay nada que lo diga: sencillamente, un día una máquina va más lenta en un nodo que en otro.

Y hay un caso, además, en el que todo esto no va contigo: si tienes uno o dos nodos, un solo puente vmbr0 plano y ninguna VLAN, esto no es tu problema y no montes un SDN para tenerlo. Aquí no hay nada que comprar: la mitad de este artículo se resuelve con diff, y la documentación de Proxmox hasta te da la orden hecha para revisar un cambio antes de aplicarlo, diff -y /etc/network/interfaces /etc/network/interfaces.new. Lo que cuesta dinero no es la herramienta: es acordarse.

Lo que hacemos nosotros antes de dar el clúster por bueno

• Escribir la tabla de puentes antes de tocar nada. Nombre (máximo diez caracteres, y el mismo en todos los nodos), enlace físico o bond del que cuelga, si es VLAN aware, MTU, y en qué nodos existe. Si una fila tiene un hueco, ese hueco es un incidente futuro con fecha por poner.
• Listar qué máquinas tienen algo colgando de la MAC y fijarla a mano con macaddr= en esas, y solo en esas. Reservas de DHCP, autenticación por puerto, licencias atadas al hardware, listas blancas.
• Repasar tag= y trunks= máquina por máquina. En vSphere la VLAN estaba en el port group, o sea en un sitio; aquí está en la línea de la tarjeta de cada VM, o sea en trescientos. Es tedioso y no hay atajo honesto.
• Poner fecha al cambio de vmxnet3 a virtio, en el mismo documento del proyecto y no en la cabeza de nadie. Si hay tramas de 9000 en juego, la fecha es antes y no después.
• Meter en la monitorización la comparación de los ficheros de red entre nodos. Es un diff periódico que avisa cuando dos nodos dejan de parecerse. Cuesta una tarde y sustituye al objeto que Proxmox no tiene. Aplica aquí lo que ya escribimos sobre tu documentación de infraestructura, y no lo repetimos.
• Y la prueba que de verdad cierra el asunto: antes de dar el clúster por bueno, migrar en vivo una máquina de cada VLAN a cada nodo, y comprobar que después habla. No una máquina: una por cada combinación. Es la única forma de que el supuesto que no está en la lista de requisitos deje de ser un supuesto. Va en el mismo sitio del proyecto donde va el plan de vuelta atrás.

Nada de esto es un argumento contra Proxmox. Lo llevamos en producción con Ceph, en varios centros de datos, y no cambiaríamos. Es un argumento contra migrar un diseño sin migrar la disciplina que lo sostenía. En vSphere, la disciplina la ponía un producto que costaba dinero. En Proxmox la pones tú, y la buena noticia es que cabe en una tabla y en un diff programado. La mala es que si nadie la escribe, no existe, y el día que se note habrá pasado un mes desde que alguien tocó un cable en el nodo equivocado.

Fuentes. Documentación oficial de Proxmox VE, versión 9.2.4 (capítulos Network Configuration, Qemu/KVM Virtual Machines —secciones de red, migración y definición de net[n]—, Proxmox Cluster File System (pmxcfs) y Software-Defined Network) y wiki oficial Migrate to Proxmox VE. Ciclo de vida de Proxmox VE 8: tabla de la FAQ oficial de Proxmox. Arquitectura del vSphere Distributed Switch y estado de desincronización de hosts: documentación y base de conocimiento de Broadcom. Las citas entre comillas son traducción nuestra del original en inglés. Lo marcado en el texto como criterio nuestro —que dejar la red fuera del sistema de ficheros de clúster es una decisión deliberada y acertada, y que el fallo caro es el mismo nombre colgando de sitios distintos— es opinión de operador, no está en ninguna documentación y así se dice. No hemos medido nada aquí: no hay ninguna cifra de rendimiento propia en este artículo porque no la tenemos publicable.