Migrar a Proxmox: la xarxa no la guarda el clúster, la guarda cada node

En una migració de VMware a Proxmox, la conversa sempre comença pels discos. Quant triguen, si el thin es manté, què passa amb les instantànies. Els discos són la part fàcil: arriben o no arriben, i te n'assabentes el mateix dia. El que no es veu és una altra cosa, i és la que dona guerra sis mesos després: a vSphere la xarxa virtual és un objecte del centre de dades i a Proxmox VE és un fitxer de cada màquina. T'emportes el disseny de xarxa. No t'emportes el mecanisme que el mantenia igual a tots els servidors.

L'interès va per davant: venem migració de VMware a Proxmox i portem infraestructura i xarxes de clients. També hem escrit quan no migrar, o sigui que aquí no hi ha entusiasme per vendre. El tema toca ara per una raó de calendari: la taula de cicle de vida de Proxmox fixa el fi de suport de Proxmox VE 8 a l'agost de 2026 —el mes, sense dia—, i això ha omplert l'estiu de gent movent màquines amb pressa, de VMware o d'una branca a una altra. Ja vam avisar que aquella caducitat no te la dirà apt. La d'avui tampoc no te la diu ningú.

El fitxer que el clúster no replica

Comencem per la frase que ho explica tot, al capítol de configuració de xarxa de Proxmox: «la configuració es pot fer a través de la interfície gràfica, o editant manualment el fitxer /etc/network/interfaces, que conté tota la configuració de xarxa». Tota. La d'aquell node. I perquè no quedi dubte que no és un descuit d'una plataforma sense clúster, Proxmox VE sí que té un sistema de fitxers de clúster: pmxcfs, «un sistema de fitxers basat en base de dades per emmagatzemar fitxers de configuració, replicats en temps real a tots els nodes del clúster fent servir corosync». La documentació llista què hi viu: corosync.conf, datacenter.cfg, el tallafoc, les regles d'alta disponibilitat, els certificats, i la configuració de cada màquina virtual a nodes/<NOM>/qemu-server/<VMID>.conf. /etc/network/interfaces no és en aquella llista.

Per mesurar el canvi convé recordar d'on véns. La documentació d'arquitectura del vSphere Distributed Switch diu que «la configuració de xarxa que crees a vCenter Server (el pla de gestió) s'empeny automàticament a tots els host proxy switches (el pla de dades)». Hi ha un objecte, viu en un lloc, i aquell lloc s'encarrega que tots els hosts s'hi assemblin. A Proxmox aquell lloc no l'hereta ningú.

Aquí va una opinió nostra, i la marquem com a tal perquè no és a cap documentació: això no és un oblit, és una decisió sensata. La xarxa del node és el que et permet arribar al node. Un fitxer que es replica sol i en temps real a totes les màquines és, aplicat a la xarxa, la manera més eficient inventada de quedar-te fora d'un clúster sencer amb un sol error de teclat. Proxmox el deixa fora expressament, i fins i tot hi posa una xarxa de seguretat: «Proxmox VE no escriu els canvis directament a /etc/network/interfaces; en lloc d'això escrivim en un fitxer temporal anomenat /etc/network/interfaces.new», que s'aplica quan tu ho dius, amb el botó Apply Configuration, amb ifreload -a o en reiniciar. La decisió és bona. La conseqüència s'ha d'assumir: allò que el programari no sincronitza, ho sincronitzes tu.

El nom del pont és el contracte

A vSphere, la targeta d'una màquina apunta a un port group: un objecte, amb identitat pròpia, que existeix a vCenter. A Proxmox, la línia de la targeta a la configuració de la VM és aquesta:

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

vmbr1 és una cadena de text. No hi ha cap objecte al darrere, ni un identificador únic, ni res que garanteixi que el vmbr1 d'un node sigui el mateix vmbr1 del del costat. Es resol en el moment d'arrencar, contra el fitxer del node on arrenca. I fixa't en el repartiment: la referència sí que viatja amb el clúster —aquella línia és a /etc/pve, replicada en temps real— i la cosa referenciada, no. Sobre els noms, la documentació és generosa fins a ser perillosa: «normalment vmbr[N], on 0 ≤ N ≤ 4094, però pots fer servir qualsevol cadena alfanumèrica que comenci per un caràcter i tingui com a màxim 10 caràcters». Deu caràcters per anomenar una cosa de la qual depèn que una màquina vegi la xarxa o no la vegi.

La fallada cara no és l'evident. L'evident —el pont no existeix al node de destí— es manifesta aviat i molesta poc. La cara és l'altra: el mateix nom als dos nodes, penjant de llocs diferents. Al node A, vmbr1 va sobre el bond de les dues targetes de 10 Gb amb MTU de 9000. Al node B, algú el va muntar en el seu dia sobre una targeta solta d'1 Gb amb MTU de 1500, «temporalment». La VM migra sense queixar-se, arrenca sense queixar-se, i a partir d'aquell moment va més lenta i perd paquets grans, i ningú no relaciona una cosa amb l'altra perquè al panell es veu exactament igual.

La llista oficial de requisits, i el que no hi és

Això es veu millor mirant què exigeix Proxmox per escrit per a una migració en viu. La secció Requirements del capítol de màquines virtuals té cinc punts:

• Que la VM no tingui recursos locals que no es puguin migrar. La documentació concreta quins: els dispositius PCI o USB en passthrough bloquegen la migració en viu, mentre que els discos locals s'envien al destí sense problema.
• Que els hosts siguin al mateix clúster Proxmox VE.
• Que hi hagi entre ells una connexió de xarxa que funcioni i sigui fiable.
• Que el host de destí tingui versions dels paquets de Proxmox VE iguals o superiors.
• Que les CPU siguin del mateix fabricant i amb capacitats semblants.

Llegeix la llista una altra vegada. El pont no hi apareix. I no hi apareix perquè, per al mecanisme de migració, no és un requisit: és un supòsit. La documentació assumeix que si has muntat un clúster, els teus nodes s'assemblen. És un supòsit raonable el dia u, quan els tres servidors són idèntics i els va instal·lar la mateixa persona la mateixa tarda. Deixa de ser-ho el dia que entra un quart node d'una altra marca, amb un altre nombre de targetes, comprat divuit mesos després.

I hi ha un cas en què aquell supòsit no el comproves tu: l'alta disponibilitat. Les regles d'HA viuen a /etc/pve/ha/, o sigui, replicades a tot el clúster; el gestor d'HA decideix a quin node es reinicia una màquina quan el seu desapareix, a les quatre de la matinada i sense preguntar. El que decideix on va la VM és del clúster. El que decideix si allà tindrà xarxa, no. Ja vam escriure que l'alta disponibilitat no evita la caiguda, l'escurça; això és el mateix argument per un altre costat. El failover no serveix de res si la màquina s'aixeca en un lloc on la seva VLAN no arriba.

La MAC canvia, i de la MAC en pengen coses

La guia oficial de migració a Proxmox VE despatxa això en una línia, a l'apartat Post Migration: «actualitza la configuració de xarxa. El nom de l'adaptador de xarxa el més probable és que hagi canviat». És veritat i es queda curta, perquè el nom és la conseqüència i no la causa. La causa és al capítol de màquines virtuals: «Proxmox VE generarà per a cada targeta una adreça MAC aleatòria, perquè la teva VM sigui adreçable en xarxes Ethernet». La targeta no es muda: se'n fabrica una de nova.

Les reserves de DHCP i les llicències lligades al maquinari ja les vam posar a la llista parlant del pla de tornada enrere, o sigui que no les repetim. El que aquella llista no deia és el que importa avui: que l'adreça no es conserva i es torna a sortejar, de manera que qui pitjor ho porta és el control d'accés per port del switch, el 802.1X, on una MAC nova no dona un error de xarxa sinó una negativa d'autenticació en un lloc que gairebé ningú no mira durant una migració.

La bona notícia és que la MAC és un paràmetre, no un destí. A la definició de net[n] hi ha macaddr=<XX:XX:XX:XX:XX:XX>, i es fixa amb qm set com qualsevol altra cosa. Es decideix abans de la migració, amb la llista de màquines que tenen alguna cosa lligada a l'adreça física al davant, no després, a base de descobrir-ho. I a l'hoste, si és Linux, el nom de la interfície canvia perquè el dispositiu és nou; el mecanisme documentat per clavar-lo és un fitxer .link de systemd amb [Match] MACAddress= i [Link] Name=. La documentació de Proxmox ho explica per a les targetes de l'amfitrió, però el mecanisme és de systemd i és el mateix dins d'un hoste Linux.

La targeta que arrenca no és la targeta que vols

Proxmox emula vmxnet3, la targeta paravirtualitzada de VMware, i això és una benedicció el dia de la migració: la màquina arrenca amb xarxa sense tocar l'hoste. La documentació és explícita sobre per a què serveix: «vmxnet3 és un altre dispositiu paravirtualitzat, que només s'hauria de fer servir en importar una VM des d'un altre hipervisor». Serveix per al trajecte i per a res més. Del model bo diu: «el model virtio ofereix el millor rendiment amb molt poca càrrega de CPU».

El cost de deixar-ho «temporalment» té un detall que es passa per alt i que surt car en clústers amb trames grans. A la definició del paràmetre mtu hi diu: «força l'MTU del dispositiu de xarxa (només VirtIO). Posar-lo a 1 o deixar-lo buit farà servir l'MTU del pont». O sigui que mentre la targeta continuï essent vmxnet3, l'MTU per interfície no és teva: et menges la del pont. Si tens xarxa d'emmagatzematge, de còpies o de Ceph amb trames de 9000, aquella és exactament la palanca que acabes de perdre. El mateix passa amb multiqueue, que també és cosa de VirtIO. Així que la conversió es posa al calendari del projecte, amb data, i no a la llista d'«algun dia».

Sense pont no et quedes sense xarxa: te'n queden altres

Aquest és el que més temps fa perdre en una migració feta amb pressa per consola o per API, i està documentat literalment: «si no especifiques un pont, creem un dispositiu de xarxa kvm user (amb NAT), que proporciona serveis de DHCP i DNS». I dona les adreces: 10.0.2.2 de passarel·la, 10.0.2.3 de DNS, 10.0.2.4 d'SMB, i el DHCP reparteix a partir de 10.0.2.15.

Per això el símptoma no és «la màquina no té xarxa». El símptoma és «la màquina té IP, resol noms, surt a internet i no la veu ningú», que és el pitjor lloc on ser durant una hora a les onze de la nit. La regla pràctica cap en una frase: si en una màquina acabada d'importar hi veus un 10.0.2.x, no busquis al tallafoc ni al switch; et falta el bridge=. La documentació hi afegeix que el mode NAT «és molt més lent que el mode pont i només s'hauria de fer servir per a proves», i que no és a la interfície web: només per CLI i API. Cosa que explica prou bé per on entra.

L'SDN és la sortida, i té lletra petita

Proxmox no ignora res d'això: per a això hi ha l'SDN, i des de la versió 8.1 ve instal·lat per defecte. La frase que importa és aquesta: «les configuracions d'SDN de Proxmox VE són a /etc/pve/sdn, que es comparteix amb tots els altres nodes del clúster a través del sistema de fitxers de configuració de Proxmox VE». Aquí hi ha el que faltava. A més té canvis pendents i aplicació conjunta —«els canvis nous no s'apliquen immediatament, sinó que es registren com a pendents», per desplegar-los «com un d'atòmic»— i porta el compte del que s'ha desplegat a .running-config i .version. És el pla de gestió que trobaves a faltar.

I ara la lletra petita, que és on cau la gent que hi arriba buscant el vCenter que ja no té. Mira què demana una zona de tipus VLAN, que és la que faràs servir si véns de port groups amb etiqueta: «el pont local o OVS switch, ja configurat a cada node, que permet la connexió entre nodes». És a dir: l'SDN no elimina el fitxer per node. S'hi recolza. El que fa, i no és poc, és reduir el que has de mantenir idèntic a mà a una sola cosa —el pont de sota— i pujar al clúster tota la capa de dalt, les VNets i les VLAN. Passes de sincronitzar vint línies per node a sincronitzar-ne una. Això és una millora enorme i no és una vareta.

L'altra part de la lletra petita la publica Proxmox a la mateixa pàgina, a l'apartat d'estat de suport, i convé llegir-la abans de dibuixar l'arquitectura: el nucli de l'SDN «està totalment suportat», però «la IPAM, inclosa la gestió de DHCP per a hostes virtuals, està en tech preview», i «l'encaminament complex via FRRouting i la integració del controlador estan en tech preview». Traduït a decisions: la capa de VNets i VLAN, endavant. El DHCP dels teus servidors, al lloc on ja funciona, no en una vista prèvia. I si el disseny va cap a QinQ, apunta l'aritmètica: calen quatre bytes més pel doble etiquetatge, «has de reduir l'MTU a 1496 si l'MTU de la teva interfície física és 1500».

Abans que sembli que VMware era el paradís

No ho era. Els hosts de vSphere també es desincronitzen del distributed switch; existeix un estat documentat pel fabricant per a això, amb el seu article de suport i el seu missatge que la configuració del distributed switch en alguns hosts diferia de la del vCenter Server. Qualsevol que hagi tret un host de manteniment amb el vCenter caigut sap de què parlem. La diferència no és que a VMware no hi hagi deriva: és que a VMware hi ha contra què comparar. Existeix un objecte que diu com hauria de ser el món, o sigui que la deriva té nom, apareix a la interfície i algú la veu. A Proxmox no hi ha objecte. Hi ha tres fitxers que s'haurien d'assemblar. Si no s'assemblen, no hi ha res que ho digui: senzillament, un dia una màquina va més lenta en un node que en un altre.

I hi ha un cas, a més, en què tot això no va amb tu: si tens un o dos nodes, un sol pont vmbr0 pla i cap VLAN, això no és el teu problema i no muntis un SDN per tenir-lo. Aquí no hi ha res per comprar: la meitat d'aquest article es resol amb diff, i la documentació de Proxmox fins i tot et dona l'ordre feta per revisar un canvi abans d'aplicar-lo, diff -y /etc/network/interfaces /etc/network/interfaces.new. El que costa diners no és l'eina: és recordar-se'n.

Què fem nosaltres abans de donar el clúster per bo

• Escriure la taula de ponts abans de tocar res. Nom (màxim deu caràcters, i el mateix a tots els nodes), enllaç físic o bond del qual penja, si és VLAN aware, MTU, i a quins nodes existeix. Si una fila té un buit, aquell buit és una incidència futura amb data per posar.
• Llistar quines màquines tenen alguna cosa penjant de la MAC i fixar-la a mà amb macaddr= en aquelles, i només en aquelles. Reserves de DHCP, autenticació per port, llicències lligades al maquinari, llistes blanques.
• Repassar tag= i trunks= màquina per màquina. A vSphere la VLAN era al port group, o sigui en un lloc; aquí és a la línia de la targeta de cada VM, o sigui en tres-cents. És tediós i no hi ha drecera honesta.
• Posar data al canvi de vmxnet3 a virtio, al mateix document del projecte i no al cap de ningú. Si hi ha trames de 9000 en joc, la data és abans i no després.
• Ficar a la monitorització la comparació dels fitxers de xarxa entre nodes. És un diff periòdic que avisa quan dos nodes deixen d'assemblar-se. Costa una tarda i substitueix l'objecte que Proxmox no té. Aquí hi aplica el que ja vam escriure sobre la teva documentació d'infraestructura, i no ho repetim.
• I la prova que de debò tanca l'assumpte: abans de donar el clúster per bo, migrar en viu una màquina de cada VLAN a cada node, i comprovar que després parla. No una màquina: una per cada combinació. És l'única manera que el supòsit que no és a la llista de requisits deixi de ser un supòsit. Va al mateix lloc del projecte on va el pla de tornada enrere.

Res d'això no és un argument contra Proxmox. El portem en producció amb Ceph, en diversos centres de dades, i no ho canviaríem. És un argument contra migrar un disseny sense migrar la disciplina que el sostenia. A vSphere, la disciplina la posava un producte que costava diners. A Proxmox la poses tu, i la bona notícia és que cap en una taula i en un diff programat. La dolenta és que si ningú no l'escriu, no existeix, i el dia que es noti haurà passat un mes des que algú va tocar un cable al node equivocat.

Fonts. Documentació oficial de Proxmox VE, versió 9.2.4 (capítols Network Configuration, Qemu/KVM Virtual Machines —seccions de xarxa, migració i definició de net[n]—, Proxmox Cluster File System (pmxcfs) i Software-Defined Network) i wiki oficial Migrate to Proxmox VE. Cicle de vida de Proxmox VE 8: taula de la FAQ oficial de Proxmox. Arquitectura del vSphere Distributed Switch i estat de desincronització de hosts: documentació i base de coneixement de Broadcom. Les cites entre cometes són traducció nostra de l'original en anglès. El que està marcat al text com a criteri nostre —que deixar la xarxa fora del sistema de fitxers de clúster és una decisió deliberada i encertada, i que la fallada cara és el mateix nom penjant de llocs diferents— és opinió d'operador, no és a cap documentació i així es diu. No hem mesurat res aquí: no hi ha cap xifra de rendiment pròpia en aquest article perquè no en tenim de publicable.