Vuit emmagatzematges compartits a Proxmox, i només dos sense lletra petita

El 30 d'octubre, Lightbits va anunciar que Proxmox l'ha nomenat Solution Provider i va publicar un plugin d'emmagatzematge per a Proxmox VE. A la nota, Tim Marx, COO de Proxmox, ho resumeix així: «Proxmox VE supports a wide range of storage technologies, so organizations can build their infrastructure the way it best suits them». És cert i és amable. La taula de la documentació oficial diu el mateix amb menys cortesia: hi ha vuit tipus d'emmagatzematge compartit i, a la columna de snapshots, només tres hi arriben sense una nota al peu. Quan obres aquelles notes, en queden dos.

Això importa sobretot si véns de VMware amb una cabina pagada i amortitzada. La pregunta que arriba a la nostra taula gairebé sempre és la mateixa: «em val la meva SAN amb Proxmox?». La resposta curta és sí. La resposta útil és que et val amb una llista concreta de renúncies, i que la llista no és a cap nota de premsa: és a les notes al peu de la taula.

Les vuit files, i què amaga cada nota

La taula de tipus d'emmagatzematge de la documentació de Proxmox VE marca nou files amb «yes» a la columna de compartit. Una és Proxmox Backup Server, que ni tan sols puntua a la columna de snapshots: hi posa «n/a». En queden vuit, i aquesta és la lectura amb les notes ja obertes:

Les tres files netes de la taula principal són CephFS, Ceph/RBD i ZFS over iSCSI. CephFS cau tota sola així que mires la seva fitxa: no accepta imatges de disc, i la seva pròpia taula hi afegeix un avís que la general no mostra, «While no known bugs exist, snapshots are not yet guaranteed to be stable, as they lack sufficient testing». En queden dos. I d'aquells dos, un et demana una cabina capaç de ZFS i una clau SSH sense contrasenya desada a /etc/pve/priv/zfs/ perquè Proxmox hi creï els ZVOL. No és un defecte, és el seu disseny; però és una frase que convé llegir abans de signar l'arquitectura, no després.

La nota 2: el snapshot que atura la màquina

Si el teu emmagatzematge compartit és un NAS per NFS, els snapshots existeixen però els fa qcow2, no l'emmagatzematge. I la documentació és explícita sobre el preu: «Creating and deleting internal qcow2 snapshots will block a running VM and is not an efficient operation», amb un afegit que rarament es cita: «The performance is particularly bad with network storages like NFS» i, en discos de centenars de gigues o de teres, «these operations may take several minutes, or in extreme cases, even hours». Si el teu cas està afectat, la documentació recomana crear i esborrar els snapshots amb la VM apagada, comptant amb una tasca llarga. Aquella mateixa nota deixa oberta l'altra porta, i convé dir-ho: les cadenes de volums també valen en emmagatzematge de fitxer. Però allà continuen en vista prèvia, i d'això va l'apartat següent.

Traduït a la vida real: el botó de «snapshot abans d'actualitzar» que tothom dóna per gratuït pot ser una aturada de servei a la màquina més gran que tinguis, que acostuma a ser justament la que menys et pots permetre aturar. No és una queixa contra NFS, que funciona de meravella per a altres coses. És que aquell botó no costa el mateix a cada fila de la taula.

La nota 4: l'interruptor que només val per als discos de demà

Aquí hi ha la bona notícia de Proxmox VE 9, i és de debò bona. Es diu snapshot-as-volume-chain i és una bandera del backend LVM. Amb ella, el snapshot no el fa LVM (les instantànies natives del qual, diu la documentació, «interfere with all write operations within the entire volume group while the snapshot is active») sinó el mateix Proxmox, encadenant volums: l'estat actual es queda amb el nom del snapshot i s'arrenca un volum nou que apunta a l'anterior i només hi desa les diferències. Fa servir qcow2 únicament per encadenar, no per a les seves instantànies internes. I el que és rellevant: «Snapshots as volume chains provide vendor-agnostic support for snapshots on any storage system that supports block storage. This includes iSCSI and Fibre Channel-attached SANs». És a dir, la teva cabina.

Ara les tres frases que hi vénen, totes a la mateixa pàgina:

• Continua sent vista prèvia. «Snapshots as volume chains are currently a technology preview in Proxmox VE», diu el requadre. No és un advertiment decoratiu: al full de ruta de Proxmox, treure-la de vista prèvia a LVM-thick, directori, NFS i CIFS continua a la llista d'objectius, juntament amb poder esborrar en calent el snapshot més alt de la cadena.
• No arriba al que ja tens. «Enabling or disabling this flag only affects newly created virtual disk volumes». Aquesta és la frase del post. Si migres dues-centes màquines a la cabina i actives la bandera després, aquelles dues-centes continuen sense cadena. L'ordre de la migració decideix qui té snapshots.
• La teva comptabilitat d'espai menteix, llevat que la cabina hi ajudi. Els volums de snapshot són LVM gruixuts, i «Each snapshot will appear to use the full volume size on the PVE side, but the actual space usage on the underlying storage will be smaller» només si la cabina suporta aprovisionament fi i discard. Si no, el consum aparent és el real.

L'altra via: codi d'un altre dins de PVE::Storage::Custom

Tornem a la notícia del 30 d'octubre, perquè il·lustra una via que cada cop es fa servir més: el plugin de tercers. El de Lightbits connecta Proxmox al seu emmagatzematge per NVMe/TCP, està publicat amb llicència Apache 2.0 a GitHub, el seu repositori es va crear l'1 de juny de 2026 i acumulava quinze estrelles el dia que escrivim això. Tècnicament promet el que un vol: volums compartits, snapshot i rollback al mateix emmagatzematge, migració en viu sense copiar discos i HA. La nota de premsa l'anomena plugin «natiu».

I després hi ha el que el mateix projecte diu de si mateix al seu README, que és molt més informatiu que la nota: és un «open-source, community-driven project» mantingut «on a best-effort basis», i la relació amb el producte comercial la deixa per escrit sense embuts: «not part of the Lightbits LightOS commercial product» i «not covered by Lightbits LightOS support agreements or SLAs unless a separate written agreement explicitly states otherwise». Això no és un retret: és honestedat del fabricant, i s'agraeix. Però canvia la pregunta. Ja no és «rendeix?», que segurament sí. És «qui arregla això un dimarts a les tres de la matinada, i sota quin contracte?».

Hi ha un detall tècnic que ho fa concret, i és a la guia de problemes del mateix plugin. Proxmox versiona la interfície dels seus plugins d'emmagatzematge, i quan una actualització puja aquell número, el plugin de tercers comença a deixar anar a cada ordre el missatge «Plugin "PVE::Storage::Custom::LightbitsPlugin" is implementing an older storage API, an upgrade is recommended». El projecte declara compatibilitat amb libpve-storage-perl fins a 9.1.13 i API d'emmagatzematge 16. Dit d'una altra manera: quan actualitzis Proxmox, hi ha una peça més al camí crític dels teus discos que ha d'anar al ritme de l'hipervisor i que no manté ni Proxmox ni tu. A nosaltres això no ens frena, ho inventariem; el que no es pot és descobrir-ho el dia de l'actualització.

El que muntem nosaltres, i quan diem que no

Operem Proxmox VE amb emmagatzematge Ceph en producció, repartit en diversos centres de dades, i la fila neta de la taula coincideix amb el que veiem: Ceph/RBD et dóna compartit, snapshots i clons sense asteriscs, i et treu la cabina del camí crític. Aquesta és la part que venem i és certa.

I aquí va la part que no venem: Ceph no és la resposta per defecte. Demana nodes, demana xarxa dedicada i demana algú que l'entengui el dia que es posa en HEALTH_WARN. Ja vam escriure, sense adorns, per què un Ceph de tres nodes no es cura sol, aguanta: amb tres nodes no hi ha lloc on recol·locar les còpies quan en cau un. Si la teva realitat són tres màquines, una xarxa compartida i ningú de guàrdia, l'honest és la cabina que ja tens, amb la bandera de cadenes activada abans de moure el primer disc, i una llista escrita del que hi renuncies. Ho decidim cas per cas perquè no som revenedors de res: aquella decisió és exactament la feina de consultoria.

Això encaixa a més amb el que explicàvem fa unes hores sobre quina ruta de sortida de VMware passava de debò pel VDDK: la ruta de sortida de VMware gairebé mai no es trenca per on es diu als fòrums, sinó per una peça concreta que ningú no va mirar a temps. A les migracions, la peça acostuma a ser l'emmagatzematge, i el moment en què es decideix no és quan falla, sinó quan es crea el primer volum.

Quatre comprovacions, avui, al teu clúster

Cap no triga més de cinc minuts i totes quatre es contesten mirant la màquina, no llegint:

# 1. ¿Qué tipos de almacenamiento tienes de verdad?
pvesm status

# 2. ¿Está la bandera de cadenas en tu storage LVM?
grep -A8 '^lvm:' /etc/pve/storage.cfg

# 3. ¿Tus discos YA creados la aprovechan? (lectura nuestra: raw = no)
qemu-img info /dev/<vg>/vm-<vmid>-disk-0

# 4. Si usas un plugin de terceros, ¿va al día?
#    (los dos números: el que exige PVE y el que declara el plugin)
perl -MPVE::Storage -e 'print PVE::Storage::APIVER(), " ",
  PVE::Storage::Custom::TuPlugin->api(), "\n"'

La tercera és la que acostuma a fer mal. Si els teus volums existents surten en raw i la bandera hi és, l'interruptor es va activar tard: la documentació diu que només afecta els volums nous. La nostra lectura, i la marquem com a lectura nostra, és que moure el disc a un altre emmagatzematge i tornar-lo a portar el recrea sota la bandera actual; comprova-ho en una màquina de proves abans de tocar producció, perquè allà ens hi juguem tots. I afegeix-hi una cinquena comprovació que no cap en una línia de consola: fes un snapshot de la VM més gran que tinguis, a l'emmagatzematge real, i cronometra'l. Aquell número, i no la taula, és la teva finestra de manteniment.

La frase del COO de Proxmox és certa: n'hi ha per triar. El que no hi ha és una fila sense cost. Triar emmagatzematge compartit no va de rendiment, perquè gairebé tots rendeixen; va de decidir quina part de la pila podràs reparar tu, quina repararà un contracte i quina no repararà ningú a les tres de la matinada.

Fonts. La taula de tipus d'emmagatzematge, les seves notes 2, 3 i 4, les fitxes per backend (iSCSI, CephFS, LVM, ZFS over iSCSI) i totes les frases sobre snapshot-as-volume-chain surten del capítol d'emmagatzematge de la documentació oficial de Proxmox VE, consultat el 2 de novembre de 2026. Els objectius pendents (treure les cadenes de vista prèvia, l'esborrat en calent del snapshot més alt i la millora de multipath per a FC i iSCSI) són al full de ruta de Proxmox VE, que també data Proxmox VE 9.2 el 21 de maig de 2026. L'anunci de Lightbits com a Solution Provider, la citació de Tim Marx i la llicència Apache 2.0 procedeixen de la nota de premsa publicada el 30 d'octubre de 2026. Les frases sobre el model de suport del plugin, el missatge de deriva d'API i la taula de compatibilitat (PVE 9.x, libpve-storage-perl fins a 9.1.13, API 16) són del README del repositori pve-lightbits; la data de creació del repositori i el recompte d'estrelles, de l'API pública de GitHub el 2 de novembre de 2026. Les citacions tècniques es reprodueixen en el seu anglès original perquè es puguin cercar literalment. La lectura comparada entre la taula general i les fitxes per backend és nostra, igual que la hipòtesi sobre recrear el volum, i van marcades com a tals al text. No tenim relació comercial amb Lightbits ni amb cap fabricant de cabines. La fotografia de la imatge social és «3PAR SAN in the server room», d'Alexis Lê-Quôc, CC BY-SA 2.0, via Wikimedia Commons.