Migrar a Proxmox i reaprofitar la cabina: l'snapshot és el que no viatja

A gairebé tots els projectes de sortida de VMware que ens arriben hi ha una línia del pressupost que ningú discuteix: la cabina es queda. Està pagada, li queden tres anys de suport i funciona. És la decisió més barata de tot el pla. També és la que decideix si, d'aquí a sis mesos, algú del teu equip podrà fer un snapshot abans d'aplicar un pedaç.

No és cap sorpresa amagada ni cap error. Està escrit, en anglès pla, a la primera línia de la secció que tracta exactament això a la documentació de Proxmox: «We generally recommend Ceph for shared storage. However, there may be scenarios where you want to use storage provided by a pre-existing NAS/SAN for shared storage in your cluster.»

El fabricant obre el capítol de la teva cabina recomanant-te una altra cosa, i tot seguit t'explica com fer-ho amb la teva. La resta del capítol es llegeix diferent després d'aquella frase.

On vivia l'snapshot i on viu ara

A vSphere, l'snapshot és una funció de l'hipervisor. Llevat d'excepcions conegudes —RDM en mode físic, discos marcats com a independents, multi-writer, passthrough—, prems el botó i funciona: tant li fa si el datastore és sobre una cabina de gamma alta, sobre una de fa vuit anys o sobre un NFS. La capacitat viatja amb l'hipervisor, no amb el ferro de sota. Aquella uniformitat és tan còmoda que ha deixat de percebre's com una decisió d'arquitectura i ha passat a ser una expectativa: és clar que puc fer un snapshot.

Proxmox reparteix aquella feina d'una altra manera, i ho diu sense embuts a la mateixa pàgina: «The storage plugins interact on a higher level with Proxmox VE (for example: create & delete disk images, take snapshot, …) and handle the low-level implementation for the individual storage types.» L'snapshot no el decideix l'hipervisor: el decideix el plugin d'emmagatzematge. I sobre emmagatzematge de bloc, «functionality like snapshots are provided by the storage layer itself».

Amb ZFS local, amb Ceph RBD o amb LVM-thin local això no dona cap problema: les tres capes de sota saben fer snapshots. El problema apareix en el cas concret que estàs planificant, que és el de sempre: un LUN gran de la teva cabina, per Fibre Channel o iSCSI, compartit entre tots els nodes. Allà Proxmox fa servir LVM thick per repartir espai al LUN, i la documentació posa el desavantatge en una línia: «Snapshots are not possible by default…»

Aquella frase és l'article sencer. La resta és què fer-ne.

Les set opcions, amb la lletra tal qual

La documentació encapçala la llista amb una data —«As of Proxmox VE 9.2 (May 2026), there are at least the following options»— i aquell at least és honest: la llista no pretén ser tancada. Són aquestes set, amb els seus avantatges i desavantatges tal com els publica el fabricant:

1. El plugin del fabricant de la teva cabina. «Your storage vendor may provide a custom Proxmox VE storage plugin. Such plugins could potentially provide snapshot capability.» Dos condicionals en disset paraules: may provide i could potentially. És la primera pregunta que cal fer al teu proveïdor d'emmagatzematge, per escrit, abans de signar res del projecte de virtualització.
2. Un LUN gran amb LVM-thick, configuració per defecte. Avantatge: «Low maintenance burden, as new guest disks can be created on the Proxmox VE side.» Desavantatge: «Snapshots are not possible by default…» És l'opció a la qual arriba tothom per inèrcia, perquè és la que funciona a la primera.
3. El mateix LUN amb «Allow Snapshots as Volume-Chain» activat. Aquesta és la que arregla l'anterior, i ve amb una etiqueta: «"Snapshots as Volume-Chain" was introduced as a technology preview in Proxmox VE 9.0 and can be enabled on thick-provisioned LVM storages.» Hi tornem a la secció següent, perquè es mereix una de pròpia.
4. Sistemes de fitxers en xarxa: NFS o SMB/CIFS. Aquí sí que hi ha snapshots, amb qcow2 i per defecte interns. I hi ha un desavantatge que a molta gent li canvia el disseny sencer: «Snapshots of containers are not possible (as containers cannot use qcow2).» Si el teu pla incloïa moure càrregues a contenidors LXC, aquella línia és teva.
5. Un LUN per cada disc de cada màquina. La mateixa documentació ho marca «(not recommended!)», amb signe d'exclamació inclòs. L'avantatge és real —«Snapshots often possible on the SAN side»— i el preu també: «High maintenance burden, as you have to manually create one LUN on the SAN side per guest disk.» Amb trenta màquines i dos discos cadascuna són seixanta LUN creats a mà, i una petició més a la cabina cada vegada que algú demana un disc nou.
6. ZFS over iSCSI. «Requires a storage box with ZFS and SSH support and supported iSCSI management tooling.» Tres requisits que una cabina clàssica de fabricant no compleix; sí que els compleix una cabina muntada sobre ZFS. És a dir: no és una opció per a la cabina que ja tens, és una opció per a la que compraries.
7. Muntar a mà un sistema de fitxers en clúster. És tècnicament possible, Proxmox és Debian i explica com fer-ho. I després escriu la frase que tanca la conversa amb direcció: «Not a supported setup», reforçada més avall amb «Please note that unsupported file systems are out of scope of the technical enterprise support.» Traduït: el dia de l'incident estàs sol.

I una línia que no és una opció però s'esmuny amb totes elles: «When using iSCSI/FC/SAS, there are often multiple redundant connections to the SAN. In this case, multipath should be configured as well.» El multipath que a vSphere venia integrat de sèrie aquí és una tasca amb nom i cognoms, i amb documentació del fabricant de la cabina per endavant.

«Technology preview» és una paraula de contracte, no de manual

L'opció 3 és la bona sobre el paper, i funciona: Proxmox la va descriure en presentar-la a la 9.0 amb força precisió. «A new property on thick-provisioned LVM storages enables support for snapshots as volume chains. With this setting, taking a VM snapshot persists the current virtual disk state under the snapshot's name and starts a new volume based on the snapshot. This enables VM snapshots on shared thick-provisioned LVM storages, as they are often used on LUNs provided by a storage box via iSCSI/Fibre Channel.» Està escrit pensant exactament en el teu cas.

El que importa aquí no és la part tècnica, que és sòlida, sinó l'etiqueta. Proxmox la va marcar technology preview a la 9.0 (agost de 2025) i continua marcada igual a la documentació de la 9.2. Això no és una lectura nostra entre línies: és al full de ruta públic del producte, a la secció «Storage & Snapshots», com a objectiu futur: «Bring "snapshots as volume chains" (tech preview since Proxmox VE 9.0) out of tech preview on LVM-thick, Directory, NFS, and CIFS storages, including support for online removal of the top-most snapshot.»

Dues versions després —la 9.1 i la 9.2—, treure-li l'etiqueta continua sent un pla. I la mateixa pàgina avisa a dalt, amb totes les lletres, de com cal llegir-la: «The items below describe development directions and priorities. Not all are planned for immediate delivery.» Més avall, a la mateixa llista, n'hi ha una altra que val la pena llegir si la teva cabina és de fibra: «Improve multipath integration and setup experience for Fibre Channel and iSCSI deployments.»

El que ve ara és opinió nostra, no de la documentació. «Technology preview» no és un judici sobre si el codi funciona —funciona, i la 9.1 porta una tanda d'arranjaments concrets que confirmen que hi ha gent fent-lo servir en producció—. És una frase que cal poder dir en veu alta en una reunió: la funció que sosté el nostre procediment de canvis està en preview. Si aquella frase es pot dir sense que a ningú li canviï la cara, endavant. Si no es pot dir, el problema no és tècnic i no s'arregla amb més proves de laboratori.

El detall que toca justament al parc vell

Entre els arranjaments de la 9.1 n'hi ha un que no sembla gran cosa fins que penses a qui li cau a sobre: «As "snapshot as volume chains" requires machine version 10 or higher, fail early when attempting to start a VM with a lower machine version.»

La versió de màquina QEMU no és la versió de Proxmox: és una propietat de cada VM, i Proxmox la fixa deliberadament per no canviar-li el maquinari virtual a un convidat que ja està instal·lat. A Windows ho fa de manera explícita, i ho va deixar escrit en introduir la versió de màquina 9.2+pve1 —una nota de les de Proxmox VE 8.4, no de la sèrie 9—: «New Windows VMs are pinned to that machine version. Existing Windows VMs are already pinned to an earlier machine version…» És a dir: les màquines que porten anys funcionant conserven la versió amb què van néixer. Són justament les que menys et ve de gust tocar.

No diem que les teves VMs hagin d'estar per sota de la 10 —això depèn de quan i amb quina versió de Proxmox es van crear, i no ho podem saber des d'aquí—. Diem que és una comprovació d'inventari, no una suposició, i que és de les barates: surt d'un qm config per màquina o d'una consulta a l'API, i es fa abans de decidir res. Si el resultat és que vint VMs heretades estan per sota, no és que l'opció 3 no les cobreixi: és que la mateixa nota de la 9.1 diu «fail early when attempting to start a VM with a lower machine version». No arrenquen sobre aquella storage fins que se'ls canviï la versió de màquina, que és un canvi de maquinari virtual i es planifica com a tal.

És el mateix patró que ja ens vam trobar amb els drivers: la migració copia el disc sencer sense perdre un byte i després Windows no arrenca perquè la controladora que espera no hi és. El que no viatja mai és la dada; és la suposició que el convidat va fer el dia que es va instal·lar.

La sortida que proposa el mateix fabricant (i per què no és el mateix)

La documentació té una secció titulada «Alternatives to Snapshots», i no proposa un altre snapshot. Proposa canviar d'estratègia: «If an existing iSCSI/FC/SAS storage needs to be repurposed for a Proxmox VE cluster and using a network share like NFS/CIFS is not an option, it may be possible to rethink the overall strategy; if you plan to use a Proxmox Backup Server, then you could use backups and live restore of VMs instead of snapshots.»

I la proposta té substància tècnica, no és cap consol: «Backups of running VMs will be quick thanks to dirty bitmap (aka changed block tracking) and the downtime of a VM on restore can also be minimized if the live-restore option is used, where the VM is powered on while the backup is restored.» Còpia incremental de veritat i arrencada mentre es restaura. Funciona.

Aquí va la nostra objecció, i va marcada com a opinió. Un snapshot i una restauració resolen la mateixa por però no són el mateix control. L'snapshot és una xarxa de seguretat que posa i treu la mateixa persona que està aplicant el canvi, dins la mateixa finestra, i la tornada enrere de la qual es decideix en trenta segons sense demanar permís a ningú. La restauració té un altre RTO, sovint un altre amo i gairebé sempre una altra conversa. Quan desfer un canvi deixa de ser gratis per a qui el fa, es desfan menys canvis: la gent aguanta amb el sistema mig trencat una estona més «a veure si s'arregla». Això no surt en cap taula de funcionalitats i és, segons la nostra experiència, l'efecte real.

Així que sí a Proxmox Backup Server —el muntem a tots els clústers, amb snapshots o sense—, però no com a substitut silenciós de l'snapshot. Si operaràs així, que sigui una decisió dita en veu alta i amb el procediment de canvis reescrit, no un descobriment del primer dimarts de pedaços.

L'arbre de decisió que signem

Quatre branques, per ordre. No és una llista de bones pràctiques: és l'ordre en què preguntem nosaltres quan entrem en un projecte d'aquests.

1. La teva cabina sap parlar NFS i et sobra xarxa per fer-ho? Aleshores la resposta acostuma a ser NFS, no un LUN. Snapshots amb qcow2, camí recorregut per molta gent, i una configuració que no arrenca amb una etiqueta de preview. El peatge està escrit i cal acceptar-lo amb els ulls oberts: sense snapshots de contenidors, i amb el rendiment d'un sistema de fitxers en xarxa, que no és el d'un LUN en fibra. Si les teves càrregues pesades són bases de dades, mesura-ho abans en comptes de discutir-ho.
2. El fabricant de la teva cabina té plugin per a Proxmox? Pregunta-ho per escrit i demana dues coses concretes: si el plugin implementa snapshots i en quines versions de Proxmox està suportat. Aquella resposta canvia el projecte sencer i és gratis aconseguir-la. Si triga tres setmanes a arribar o arriba en condicional, això també és informació.
3. Si et quedes en LUN + LVM-thick amb volume-chain, tracta'l com el que està etiquetat que és. Això vol dir quatre coses concretes, no una declaració d'intencions: inventari de versió de màquina QEMU abans d'encendre-ho; la funció provada en un clúster de proves amb el mateix model de cabina, no amb un disc local; l'apartat «mentre això continuï en preview fem X» escrit al procediment; i Proxmox Backup Server operatiu i amb una restauració real cronometrada, no una prevista. I compte amb la lletra petita que ja porta avui: amb estat TPM, «the top-most snapshot cannot be removed while the VM is running».
4. I si en fer aquests comptes la cabina deixa de sortir a compte, digue-ho. Hi ha un punt en què reaprofitar el ferro costa més en hores, en risc i en peatges operatius que el que estalvia a la factura, i aquell punt arriba abans del que la gent espera. Allà és on comença a tenir sentit la primera frase de la documentació, la de «we generally recommend Ceph»: emmagatzematge distribuït sobre els mateixos nodes, amb snapshots natius i sense cabina al centre. És més canvi i més inversió inicial, i no sempre és la resposta —ho hem desaconsellat en clústers petits—, però deixa d'arrossegar una decisió del 2019 durant cinc anys més. I porta la seva pròpia lletra petita, que també hem explicat: rotar una clau de Ceph no s'acaba reiniciant la VM.

Sigui quina sigui la branca, la decisió es pren abans de moure la primera màquina, perquè és l'única de tot el projecte que després surt cara de canviar: moure trenta VMs d'un LUN amb LVM-thick a NFS no és canviar una casella, és repetir la migració sencera. És el mateix motiu pel qual insistim a escriure el pla de tornada enrere abans de començar i no quan fa falta.

Quan quedar-se la cabina és, sense discussió, el correcte

Res de tot això és un argument per llençar una cabina que funciona. Hi ha dues situacions que no surten a l'arbre de decisió i que decanten la balança cap a quedar-se-la. Una: que la majoria de les teves VMs siguin de les que mai no es pedacen en calent, perquè tenen la seva pròpia finestra i la seva pròpia còpia; allà l'snapshot que es perd no el feia servir ningú. Dues: que el clúster sigui petit i no hi hagi ni pressupost ni nodes per plantejar emmagatzematge distribuït en condicions, que és més habitual del que sembla.

El que no és defensable és no haver-ho mirat. I si en mirar-ho surt que avui no toca migrar, també és una resposta vàlida: ja vam escriure sobre quan NO migrar de VMware a Proxmox, i l'emmagatzematge compartit és un dels motius que hi apareixen amb nom propi.

La cabina no es va discutir perquè estava pagada. L'snapshot es discutirà sis mesos després, un dimarts a la tarda, amb el pedaç a mig aplicar. I aleshores ja no serà gratis.

El que no afirmem

No diem que Proxmox sigui pitjor que VMware en emmagatzematge compartit, ni a l'inrevés: diem que reparteixen la feina de manera diferent i que això té conseqüències operatives concretes. No tenim números comparatius de rendiment entre NFS i LUN sobre la mateixa cabina, així que no en donem cap; mesurar-ho al teu ferro és part de la feina. No hem provat els plugins de tots els fabricants de cabines i no podem dir quins implementen snapshots. «Technology preview» és l'etiqueta que posa Proxmox, no un judici nostre sobre l'estabilitat del codi, i el mateix full de ruta avisa que els seus punts no tenen data compromesa —així que tampoc no afirmem quan sortirà de preview—. No sabem quina versió de màquina QEMU tenen les teves VMs; per això ho plantegem com a comprovació i no com a diagnòstic. I no som part interessada: no revenem llicències de Proxmox ni de VMware ni cabines de ningú.

Nota de fonts

Tot consultat el 18 de setembre de 2026, descarregant el text original de les pàgines i no una cobertura de segona mà. Un: l'article «Migrate to Proxmox VE» del wiki oficial, seccions Storage, Storage boxes (SAN/NAS), Alternatives to Snapshots i Unsupported File Systems: d'allà surten la recomanació de Ceph, l'encapçalament «As of Proxmox VE 9.2 (May 2026), there are at least the following options», les set opcions amb els seus avantatges i desavantatges literals, la descripció del paper dels plugins d'emmagatzematge, la nota de multipath, la frase sobre el suport empresarial i els sistemes de fitxers no suportats, i el paràgraf de còpies amb dirty bitmap i live-restore. Dos: la pàgina Roadmap de Proxmox VE, d'on surten l'avís de com llegir-la («Not all are planned for immediate delivery»), l'objectiu de treure snapshots as volume chains de tech preview, el punt de millorar multipath en desplegaments FC/iSCSI, i —de l'històric de versions de la mateixa pàgina— l'entrada de Proxmox VE 9.0 que introdueix els snapshots com a cadenes de volums, la tanda d'arranjaments de la 9.1 amb la línia de la versió de màquina 10 o superior, i —de l'entrada de Proxmox VE 8.4, no de la sèrie 9— la nota sobre l'ancoratge de versió de màquina en convidats Windows. El que és opinió nostra i va marcat com a tal al cos: que la cabina és la decisió més barata i la que més canvia l'operació diària; la lectura de «technology preview» com una frase que cal poder dir en una reunió; la diferència d'efecte real entre un snapshot i una restauració; l'arbre de decisió de quatre branques; i la llista de casos en què quedar-se la cabina és el correcte.

Imatge de portada: fotografia d'una cabina de disc en rack, de Wikimedia Commons (CC BY-SA), retallada per nosaltres. Els textos i la marca els afegim a sobre.