Quan NO migrar de VMware a Proxmox

Migrar de VMware a Proxmox és part del que fem. I hi ha casos en què la resposta que donem és que no toca. No per prudència comercial: perquè els números no surten. Aquests són els cinc casos, i de passada els dos arguments amb què ja no es pot defensar que et quedis.

La conversa sobre si Proxmox «està a punt» encara es fa, a la majoria de reunions on arribem, amb una llista de mancances copiada d'una comparativa de fa tres anys. Hi ha una part d'aquesta llista que va caducar el maig d'enguany i una altra que continua igual de vigent. Separar-les és la meitat de la feina de decidir, i gairebé ningú la fa abans d'asseure's a mirar el preu de la renovació.

Convé, a més, treure's de sobre el marc èpic. Gairebé tres anys després de la compra, el moviment real de clients de VMware va ser molt més petit que el soroll: ho vam mirar amb les dades que hi havia a l'èxode que no va ser. La majoria d'empreses ni va fugir ni es va quedar tan tranquil·la; va renegociar i va continuar. Així que això no va de bàndols. Va de si en el teu cas concret surten els números.

Dues objeccions que ja no se sostenen

La primera: «no té DRS». Era certa. Va deixar de ser-ho el 21 de maig de 2026, amb Proxmox VE 9.2. La nota de premsa oficial ho descriu així: «operant en un nou mode dinàmic, el planificador de recursos del clúster (CRS) incorpora la utilització de recursos de nodes i convidats en temps real a cada decisió de col·locació». I hi afegeix que «el balancejador de càrrega integrat pot migrar automàticament convidats gestionats per la pila d'alta disponibilitat (HA) per reduir el desequilibri entre els nodes del clúster, respectant estrictament totes les regles d'HA definides per l'usuari».

Llegeix sencera la segona frase, perquè la part que importa és a la meitat: convidats gestionats per la pila d'HA. El balancejador mou allò que estigui donat d'alta com a recurs d'alta disponibilitat. Les màquines que tinguis simplement arrencades en un node, sense declarar a HA, es queden on són per molt desequilibrat que estigui el clúster. És coherent i està documentat; senzillament no és el que la gent entén quan llegeix el titular.

La segona: «no hi ha còpies de tercers serioses». Veeam dona suport a Proxmox VE des del 2024 i la versió 13.1, publicada el 29 de juliol de 2026, incorpora treballs de replicació per a la plataforma. Ara el matís honest, que és a les notes d'aquesta mateixa versió, a l'apartat de problemes coneguts: «un treball de replicació pot fallar si la màquina virtual d'origen té discos la mida dels quals no és múltiple de la mida de bloc utilitzada per l'emmagatzematge de destinació». Traduït: funciona, i té arestes. Es planifiquen abans, no es descobreixen el cap de setmana del tall.

El que de debò canvia: qui pren les decisions per tu

La diferència rellevant entre les dues plataformes no és una llista de funcions. És que vSphere arribava amb un munt de decisions ja preses —pel fabricant, per l'integrador, per qui el va muntar fa vuit anys— i Proxmox espera que les prenguis tu. Quan ningú les pren, queden preses igualment: al valor per defecte. I els valors per defecte són escrits a la documentació, a la vista de qualsevol.

La pàgina del manual de datacenter.cfg defineix el bloc crs. Tres coses d'allà convé mirar-les abans de signar res:

• ha=<basic|static|dynamic>, amb «default = basic». I basic és, literalment, «només s'utilitza el nombre de serveis». De fàbrica, el planificador reparteix comptant màquines: la base de dades que es menja el node sencer i la maquineta del servidor de llicències valen exactament el mateix.
• ha-auto-rebalance, amb «default = 0». Aquest balanceig automàtic del titular no s'activa sol. És una casella que algú ha de marcar, amb el seu llindar (ha-auto-rebalance-threshold, per defecte 30%) i la seva histèresi (ha-auto-rebalance-hold-duration, per defecte 3 rondes).
• ha-rebalance-on-start, amb «default = 0». Ni tan sols en arrencar un servei aturat es busca el node més adequat, tret que li ho demanis.

Res d'això és un defecte. Són valors conservadors, i per a un clúster acabat de muntar són els correctes: un balancejador que comença a moure màquines tot sol el primer dia és pitjor que un de quiet. El problema no és el valor, és la creença. Si algú va vendre la migració dient «ja té DRS» i ningú va tocar el fitxer, el clúster reparteix per nombre de màquines i ningú no ho sap fins que un node va ofegat i el del costat és mig buit.

L'objecció que continua dempeus: la xarxa de seguretat que no ve posada

Hi ha una funció de vSphere de la qual gairebé ningú parla a les comparatives i que trobem realment a faltar: l'admission control. La documentació de Broadcom descriu la política de slots com un mecanisme que calcula quantes màquines hi caben si fallen N amfitrions i que, quan la capacitat de commutació disponible baixa de la configurada, impedeix l'operació. No avisa: la impedeix. És a dir, vSphere et prohibeix arrencar la màquina que trencaria la teva pròpia N-1.

La documentació d'alta disponibilitat de Proxmox VE no descriu cap mecanisme equivalent. Hi ha regles d'afinitat de node i de recurs, hi ha prioritats, hi ha fencing amb watchdog. No hi ha res que reservi capacitat ni que et freni quan te la menges. De fet, la mateixa documentació et passa la pilota amb totes les lletres: en explicar què passa quan cau un node, diu que el gestor reparteix els serveis entre els que queden i que això apuja el nombre de serveis en aquests nodes, i hi afegeix «dissenyeu el vostre clúster de manera que pugui suportar aquests escenaris del pitjor cas». És una instrucció per a tu, no una funció del producte. Pots omplir el clúster fins a dalt i tot funcionarà perfectament fins al dia que caigui un node i descobreixis que el que hi havia dins no cap als que queden. Aquell dia no és una caiguda: és una fallada convertida en avaria per una decisió de disseny que ningú va prendre. El mateix que expliquem a l'HA de Proxmox no evita la caiguda, l'escurça, amb la diferència que aquí ni tan sols l'escurça.

Es resol, és clar. Es resol amb un full de càlcul, una revisió trimestral i una regla escrita de quanta RAM es deixa lliure per node. Però passa de ser una barrera de la plataforma a ser una disciplina de la casa, i les disciplines de la casa es relaxen a l'agost.

Els cinc casos en què diem que no

Cap dels cinc és un problema de Proxmox. Un és del calendari, un altre és del teu proveïdor de programari i els altres tres són de casa.

1. Quan la data la posa la renovació

És el cas més freqüent i el més car. Arriba l'oferta de renovació, el número cou, queden sis setmanes i algú decideix que es migra abans no expiri. Migrar amb la data imposada des de fora significa renunciar a l'única cosa que fa segura una migració: poder aturar-la. Nosaltres treballem amb tornada enrere preparada i amb una finestra en què l'origen continua encès i arrencable, i aquesta finestra caduca sola per contracte i per dades. Si la renovació se't menja la finestra, la recomanació honesta és renovar el període més curt que et deixin i migrar sense ganivet al coll.

2. Quan allò que sosté la facturació té matriu de suport

L'ERP, el sistema de gestió sectorial, el programari del laboratori, l'aplicació que valida les factures. Molts d'aquests fabricants publiquen una llista d'hipervisors sobre els quals donen suport, i aquesta llista no es negocia per fòrum ni per benchmark: es pregunta per escrit, amb el número de contracte al davant, i es desa la resposta. Si el teu proveïdor crític contesta que fora de la seva llista atén en mode best effort, això és una decisió de risc que correspon a direcció, no a sistemes. I no ho arregla que Proxmox rendeixi igual o millor, perquè el problema no era tècnic.

3. Quan ningú ha fet el càlcul de l'N-1

El càlcul és de primària i tot i així gairebé mai no està fet. Suma a cada node la memòria realment assignada a les màquines que té enceses —no la de l'últim inventari, la d'avui—, treu-li el node més carregat i comprova si aquesta suma cap als que queden deixant marge per al mateix sistema. A vSphere no calia fer-lo perquè el feia l'admission control; a Proxmox el fas tu o no es fa. Quan surt que no hi cap, hi ha tres sortides honestes: comprar un node més, apagar alguna cosa, o escriure al pla que davant la caiguda d'aquell node concret hi ha serveis que no arrenquen i dir quins. Totes tres són vàlides. Fer com si la pregunta no existís no ho és, i migrar un clúster sobreaprovisionat a una plataforma que no et frenarà és treure l'airbag i comprar un cotxe més nou.

4. Quan el problema no és l'hipervisor

Una sola sala. Còpies que mai s'han restaurat de debò. Un temps objectiu de recuperació que ningú ha cronometrat. Canviar d'hipervisor no arregla res d'això i consumeix el pressupost i les hores de la persona que podria estar arreglant-ho. Si la teva exposició real és aquí, l'ordre correcte és primer posar número a l'RTO i a l'RPO i provar un restore amb cronòmetre, i després ja parlarem de plataforma. És pitjor consell comercial i millor consell a seques.

5. Quan no hi ha qui ho mantingui a les tres de la matinada

Proxmox VE és Debian per sota, i això és un avantatge enorme el dia que cal mirar un log i un desavantatge el dia que ningú sap quin mirar. La plataforma tampoc no perdona l'oblit del cicle de vida: la branca 8 arriba a fi de suport a finals d'aquest mes d'agost i el gestor de paquets no t'avisarà pel seu compte. Si a l'empresa no hi ha ningú que vagi a llegir això, i tampoc no hi ha contractat qui ho faci, la migració es converteix en una plataforma nova sense amo. Això és pitjor punt de partida que un vSphere car però cuidat.

I quan sí, doncs

Quan els números a tres anys surten amb les hores de projecte dins i no només amb el preu de les llicències. Quan hi ha una finestra en què es pot aturar sense drama. Quan el programari crític està confirmat per escrit. Quan algú —de casa o de fora— es queda amb la plataforma després de la foto de fi de projecte. I quan es fa per capes: un grup de màquines poc crítiques primer, setmanes de convivència entre les dues plataformes, i l'origen encès fins que ja ningú no se'n recorda.

Treballem amb les dues plataformes des de fa molts anys i no venem llicències de cap, que és exactament per això que ens podem permetre escriure això. Quan la resposta és que et quedis, cobrem força menys. També dormim millor.

Nota de fonts

Les cites del mode dinàmic del CRS i del balancejador integrat són de la nota de premsa oficial de Proxmox Server Solutions sobre Proxmox VE 9.2 (21 de maig de 2026). Els valors per defecte de crs (ha=basic, ha-auto-rebalance=0, ha-rebalance-on-start=0, llindar 30, durada 3) són a la pàgina de manual datacenter.cfg(5) de la documentació de Proxmox VE. La frase sobre dissenyar el clúster per al pitjor cas és del capítol d'alta disponibilitat d'aquesta mateixa documentació. L'absència d'un mecanisme de reserva de capacitat és una lectura nostra d'aquest capítol: descriu regles d'afinitat, prioritats i fencing, i no descriu res equivalent a l'admission control. La descripció de la política de slots i que impedeix l'operació és de la documentació tècnica de Broadcom per a vSphere. La data de la 13.1 de Veeam (29 de juliol de 2026) i el problema conegut dels treballs de replicació són de les seves notes de versió oficials; el suport de Veeam a Proxmox VE ve del 2024, no d'enguany. El fi de suport de Proxmox VE 8 apareix com a «2026-08» a la taula de cicle de vida de la FAQ de Proxmox VE. Les cites en català són traducció nostra de l'original en anglès. Els cinc casos, l'ordre en què els posem i l'opinió sobre els valors per defecte són nostres, no de les fonts.