A gairebé tots els plans de migració que ens passen a revisar hi ha una línia que diu, més o menys: «si alguna cosa surt malament, tornem a VMware». I aquí s'acaba. No diu a què es torna exactament, ni qui ho decideix, ni amb quines dades, ni —sobretot— fins quan es pot tornar. Aquesta darrera part és la que caduca sola, en silenci, mentre el projecte avança i tothom continua creient que té pla B.
Aquest post no va de si migrar a Proxmox és bona idea —això ja ho vam contar amb els números a la mà quan vam explicar com vam migrar més de 500 màquines virtuals—. Va del que passa quan la migració resulta ser la part fàcil, i de l'altra meitat del pla: la que només es fa servir el pitjor dia, la que ningú no assaja i la que s'evapora sense que salti cap alarma.
«Tornar» no és des-migrar
Convé deixar clara una asimetria que el producte t'ensenya sense dir-ho. Proxmox VE porta un assistent d'importació des d'ESXi i vCenter integrat a la interfície web des de la versió 8.2, publicada el 24 d'abril del 2024. Està ben fet: es connecta al datastore com si fos un emmagatzematge més i s'emporta la màquina sencera. El que no existeix és el botó del costat. Proxmox no inclou cap assistent equivalent per tornar una màquina a ESXi: això són qemu-img, un OVF muntat a mà i una bona estona de feina. Dos anys i dues branques després, amb la 9.2 sobre la taula, aquell botó continua sense aparèixer.
Per això el rollback de debò, el que cap en una finestra de manteniment, consisteix a engegar un altre cop la màquina original, que continua apagada al seu lloc, al vSphere de sempre. No hi torna res. És un pla senzill i bo. Depèn de tres coses que ningú no escriu: que aquella màquina continuï existint, que el vSphere continuï sent un lloc on vulguis tornar, i que les dades generades mentrestant tinguin on anar. Les tres es van tancant pel seu compte.
La finestra es tanca per tres llocs
1. El contracte
Aquí cal separar dues situacions que la gent barreja. Si conserves llicència perpètua i el que se t'ha caducat és el suport (l'SnS), Broadcom ho diu al seu propi article de coneixement amb una claredat que s'agraeix: «els hosts ESXi i vCenter Server continuaran funcionant amb normalitat» i «no hi ha cap mecanisme automàtic d'aturada o desconnexió que es dispari per l'expiració del contracte de suport». El teu pla B sobreviu. El que perds és l'accés al portal per descarregar «nous pedaços, actualitzacions de seguretat i versions majors o menors», i la capacitat d'afegir hosts nous o fer una actualització de versió major.
Si estàs en subscripció —que és on ja és la majoria, perquè les perpètues van deixar de vendre's—, el venciment no és un avís, és un final. Les guies de llicenciament que circulen pel canal coincideixen en la mateixa frase: no hi ha període de gràcia al venciment de la subscripció, i renovar tard porta recàrrec —ChannelWeb ho va xifrar el 2025 en un 20 % sobre el cost del primer any, aplicat des de la data del venciment—. Aquí toca ser honestos: no hem trobat aquesta xifra en cap document públic de Broadcom, només en cobertures i en material de distribuïdors. És exactament el tipus de número que cal mirar al teu contracte abans de fonamentar-hi un pla.
2. L'hipervisor on tornes
Aquesta és la que més ens preocupa i la que menys apareix als plans. Un vSphere sense SnS actiu es queda congelat en l'últim pedaç que vas poder descarregar. El primer mes no ho notes. Al tercer, «tornem a VMware» ja vol dir «tornem a un hipervisor que fa un trimestre que no rep actualitzacions de seguretat, amb les màquines més crítiques de la casa a sobre». Això no és un pla de contingència: és canviar un risc per un altre sense haver-ho decidit. Si el teu pla B té data, escriu-la; i si la data ja ha passat, deixa d'anomenar-lo pla B.
3. El delta de dades
La tercera es tanca en hores, no en mesos. Mentre la màquina importada està apagada o en proves, el rollback és gratis: n'apagues una, n'encens l'altra, fi. En el moment en què el primer usuari desa un fitxer o la primera comanda entra a la base de dades, tornar deixa de ser «engegar la d'abans» i passa a ser «engegar la d'abans i reconciliar el que s'ha escrit mentrestant». Aquest canvi de naturalesa passa en un instant concret, i aquell instant gairebé mai no està marcat al pla. Hauria de tenir hora.
El que l'assistent no s'emporta
El wiki oficial de Proxmox és sorprenentment franc amb els límits de la importació. Val la pena llegir-lo sencer abans de planificar, perquè cada límit de l'anada és un motiu de tornada:
- ✗vSAN: «importar una VM amb discos suportats per un emmagatzematge VMware vSAN no funciona». El wiki apunta una drecera —moure abans els discos a un altre emmagatzematge—, però això és una migració d'emmagatzematge dins del mateix vSphere: surt del pla i es converteix en un projecte anterior al projecte.
- ✗Discos xifrats: «els discos de VM xifrats, per exemple mitjançant una Storage Policy, no es poden importar».
- ✗vTPM: ara com ara l'estat del TPM virtual no es pot migrar a Proxmox VE des de VMware. Traduït al que fa mal: si el convidat arrenca amb BitLocker ancorat al vTPM, moure el disc no n'hi ha prou. Cal suspendre o desactivar el xifratge abans, i aquesta maniobra s'ha de planificar —i desfer— amb la clau de recuperació al davant.
- !Snapshots: importar una VM que en tingui «pot ser significativament més lent». En una migració per lots, una sola màquina amb una cadena llarga de snapshots es menja la finestra sencera de les altres. El mateix wiki hi afegeix un altre avís de la mateixa família: importar a través d'una instància de vCenter «redueix dràsticament el rendiment». Quan la finestra està comptada, aquells dos detalls decideixen per tu.
- !Windows: cal instal·lar els controladors VirtIO abans de canviar el disc d'arrencada a VirtIO SCSI. És l'errada que més vegades ens hem trobat revisant migracions alienes, i és cent per cent evitable llegint l'ordre correcte.
- !Xarxa: el wiki recomana apuntar la configuració de xarxa del convidat per restaurar-la a mà i revisar reserves DHCP i adreces MAC. Detall que es paga car: hi ha llicències de programari de tercers ancorades a la MAC o a l'identificador de la màquina. Si això t'aplica, la teva finestra de tornada enrere també depèn d'un proveïdor que no ets tu.
I per damunt de tota la llista, l'advertència que el mateix wiki posa en negreta: «assegura't que la VM està encesa només a Proxmox VE o a VMware, però mai a totes dues alhora, per evitar la corrupció de disc». Sembla òbvia llegint-la amb calma un dimarts. No ho és a les dues de la matinada, quan alguna cosa va malament, hi ha pressa i la temptació és engegar la de VMware «un moment, per comparar».
El rollback d'urgència és el que trenca coses
La tornada enrere mal feta no falla pel disc: falla per tot el que hi ha al voltant de la màquina. Encens l'original al vSphere mentre la nova continua amunt a Proxmox i, durant els minuts que trigues a adonar-te'n, tens dues màquines amb el mateix nom i la mateixa IP, dos agents de còpia que informen el mateix servidor de backup, dos serveis autenticant-se amb el mateix compte i —aquesta és la dolenta— dos processos escrivint a la mateixa base de dades remota, que no és a cap de les dues i per tant no protegeix ningú. Cap d'aquestes quatre coses s'arregla apagant-ne una després.
Per això el pas u de qualsevol tornada enrere que escrivim no és «arrencar la de VMware». És apagar la de Proxmox i confirmar que està apagada. En aquest ordre, sempre, i amb una persona que ho confirma en veu alta abans que ningú toqui res a l'altra banda.
Les sis línies que sí que escrivim
Un pla de tornada enrere no ocupa un document. Ocupa sis línies, i si alguna no saps omplir-la, aquell buit és la troballa:
- 1El criteri d'aturada, mesurable. No «si va malament». Alguna cosa com «si el procés nocturn no tanca abans de les 04:00» o «si la latència del disc passa de X durant Y minuts». Escrit abans de començar, quan ningú no té son ni ganes que surti bé a qualsevol preu.
- 2Qui ho decideix i a quina hora. Una persona, amb nom, i una hora límit. Si a aquella hora no està validat, es torna. Sense reunió, sense «donem-li mitja hora més». Les mitges hores més són les que es mengen la finestra.
- 3La VM d'origen es queda apagada, no s'esborra — i amb la data d'esborrat posada al calendari. Aquella data és la teva finestra de tornada enrere. Mentre no existeixi, la finestra la decideix qui necessiti espai al datastore el mes que ve.
- 4Què passa amb el delta. Si acceptaràs escriptures a Proxmox abans de validar del tot, digues ara com les tornes: exportació, reintroducció manual o pèrdua assumida i acceptada per escrit per qui la patirà. Si no saps respondre, la resposta és no acceptar escriptures encara.
- 5L'assaig. La tornada enrere es prova sencera amb una màquina real i poc crítica, en una finestra real, abans de tocar la primera important. Si no s'ha executat mai, el que tens és una intenció escrita en un document.
- 6La data en què el pla B deixa d'existir. El dia que venç la subscripció, o el dia en què aquell ESXi acumula tants pedaços sense aplicar que tornar-hi ja seria pitjor. Aquesta línia no és a cap pla que hàgim revisat i és l'única que es compleix sense que ningú faci res.
Quan et diríem que no migris encara
No som resellers de Proxmox ni de VMware, i no venem llicències de cap de les dues. Això ens deixa dir l'evident: hi ha casos en què la resposta correcta és esperar. Si la teva renovació queda lluny i no tens ningú que vagi a operar l'hipervisor nou l'endemà de la festa, migrar només avança el problema. Si hi ha una càrrega crítica lligada a alguna cosa de vSphere que no has provat fora de vSphere, aquella càrrega va l'última, no la primera. I si no aconsegueixes escriure el criteri d'avortament de la línia 1, no estàs a punt per migrar: estàs a punt per fer una prova, que és una altra cosa i també està bé.
Hi ha una lectura de fons que ja vam fer amb dades fa unes setmanes, quan vam revisar què ha passat de debò dos anys després de Broadcom: el que està passant no és un èxode, és una reducció de dependència per fases. I una migració per fases es recolza, precisament, a poder desfer una fase sense arrossegar les altres. Quan la tornada enrere caduca, el que s'acaba és aquesta possibilitat: a partir d'aquí només queden onades que van cap endavant.
La línia que no deixem en blanc
Als plans que escrivim nosaltres, la línia 6 no es deixa en blanc: porta per defecte la data de la propera renovació de VMware menys trenta dies. El número no té res de màgic —trenta dies és el que triga a organitzar-se una finestra de tornada enrere amb gent de debò i nocturnitat de debò—, però obliga a la conversa un mes abans que la decisió es prengui sola. Perquè aquella data existeix l'escriguis o no. Si no la poses tu, la posa el venciment d'un contracte, un datastore que es queda sense espai o algú que necessita reaprofitar aquells hosts. I aquell dia ningú no t'avisa que acabes de quedar-te sense pla B.
Fonts: assistent d'importació des d'ESXi/vCenter i data de la versió 8.2 (24-abr-2024) — nota de premsa de Proxmox; límits de la importació (vSAN, discos xifrats, vTPM, snapshots, xarxa, VirtIO a Windows) i l'advertència de no engegar la VM a totes dues bandes — wiki oficial de Proxmox VE; comportament d'una llicència perpètua després del venciment de l'SnS i cites literals — article 429208 de Broadcom; absència de període de gràcia en subscripció i recàrrec per renovació tardana (dada de canal, no confirmada en document públic de Broadcom) — ChannelWeb i guies de llicenciament de distribuïdors. Imatge de portada: «One way sign», Karina Carvalho, CC0 1.0, via Wikimedia Commons.
Quina data té el teu pla de tornada enrere?
A everyWAN portem totes dues plataformes en producció des del 2015 i planifiquem migracions de VMware a Proxmox per fases, amb el rollback assajat abans de tocar la primera màquina que importa. I si en mirar-ho veiem que enguany et toca quedar-te on ets, t'ho diem igualment.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN