Migrar a Proxmox y reutilizar la cabina: el snapshot es lo que no viaja

En casi todos los proyectos de salida de VMware que nos llegan hay una línea del presupuesto que nadie discute: la cabina se queda. Está pagada, le quedan tres años de soporte y funciona. Es la decisión más barata de todo el plan. También es la que decide si, dentro de seis meses, alguien de tu equipo podrá hacer un snapshot antes de aplicar un parche.

No es una sorpresa escondida ni un fallo. Está escrito, en inglés llano, en la primera línea de la sección que trata exactamente esto en la documentación 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 fabricante abre el capítulo de tu cabina recomendándote otra cosa, y acto seguido te explica cómo hacerlo con la tuya. El resto del capítulo se lee distinto después de esa frase.

Dónde vivía el snapshot y dónde vive ahora

En vSphere, el snapshot es una función del hipervisor. Salvo excepciones conocidas —RDM en modo físico, discos marcados como independientes, multi-writer, passthrough—, le das al botón y funciona: da igual si el datastore está sobre una cabina de gama alta, sobre una de hace ocho años o sobre un NFS. La capacidad viaja con el hipervisor, no con el hierro de debajo. Esa uniformidad es tan cómoda que ha dejado de percibirse como una decisión de arquitectura y ha pasado a ser una expectativa: claro que puedo hacer un snapshot.

Proxmox reparte ese trabajo de otra manera, y lo dice sin rodeos en la misma 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.» El snapshot no lo decide el hipervisor: lo decide el plugin de almacenamiento. Y sobre almacenamiento de bloque, «functionality like snapshots are provided by the storage layer itself».

Con ZFS local, con Ceph RBD o con LVM-thin local eso no da ningún problema: las tres capas de abajo saben hacer snapshots. El problema aparece en el caso concreto que estás planificando, que es el de siempre: un LUN grande de tu cabina, por Fibre Channel o iSCSI, compartido entre todos los nodos. Ahí Proxmox usa LVM thick para repartir espacio en el LUN, y la documentación pone la desventaja en una línea: «Snapshots are not possible by default…»

Esa frase es el artículo entero. El resto es qué hacer con ella.

Las siete opciones, con la letra tal cual

La documentación encabeza la lista con una fecha —«As of Proxmox VE 9.2 (May 2026), there are at least the following options»— y ese at least es honesto: la lista no pretende ser cerrada. Son estas siete, con sus ventajas y desventajas tal como las publica el fabricante:

1. El plugin del fabricante de tu cabina. «Your storage vendor may provide a custom Proxmox VE storage plugin. Such plugins could potentially provide snapshot capability.» Dos condicionales en diecisiete palabras: may provide y could potentially. Es la primera pregunta que hay que hacerle a tu proveedor de almacenamiento, por escrito, antes de firmar nada del proyecto de virtualización.
2. Un LUN grande con LVM-thick, configuración por defecto. Ventaja: «Low maintenance burden, as new guest disks can be created on the Proxmox VE side.» Desventaja: «Snapshots are not possible by default…» Es la opción a la que llega todo el mundo por inercia, porque es la que funciona a la primera.
3. El mismo LUN con «Allow Snapshots as Volume-Chain» activado. Esta es la que arregla lo anterior, y viene con 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.» Volvemos a ella en la sección siguiente, porque merece una propia.
4. Sistemas de ficheros en red: NFS o SMB/CIFS. Aquí sí hay snapshots, con qcow2 y por defecto internos. Y hay una desventaja que a mucha gente le cambia el diseño entero: «Snapshots of containers are not possible (as containers cannot use qcow2).» Si tu plan incluía mover cargas a contenedores LXC, ese renglón es tuyo.
5. Un LUN por cada disco de cada máquina. La propia documentación lo marca «(not recommended!)», con signo de exclamación incluido. La ventaja es real —«Snapshots often possible on the SAN side»— y el precio también: «High maintenance burden, as you have to manually create one LUN on the SAN side per guest disk.» Con treinta máquinas y dos discos cada una son sesenta LUN creados a mano, y una petición más a la cabina cada vez que alguien pide un disco nuevo.
6. ZFS over iSCSI. «Requires a storage box with ZFS and SSH support and supported iSCSI management tooling.» Tres requisitos que una cabina clásica de fabricante no cumple; sí los cumple una cabina montada sobre ZFS. Es decir: no es una opción para la cabina que ya tienes, es una opción para la que comprarías.
7. Montar a mano un sistema de ficheros en clúster. Es técnicamente posible, Proxmox es Debian y explica cómo hacerlo. Y luego escribe la frase que cierra la conversación con dirección: «Not a supported setup», reforzada más abajo con «Please note that unsupported file systems are out of scope of the technical enterprise support.» Traducido: el día del incidente estás solo.

Y una línea que no es una opción pero se cuela con todas ellas: «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 en vSphere venía integrado de serie aquí es una tarea con nombre y apellidos, y con documentación del fabricante de la cabina por delante.

«Technology preview» es una palabra de contrato, no de manual

La opción 3 es la buena sobre el papel, y funciona: Proxmox la describió al presentarla en la 9.0 con bastante precisión. «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á escrito pensando exactamente en tu caso.

Lo que importa aquí no es la parte técnica, que es sólida, sino la etiqueta. Proxmox la marcó technology preview en la 9.0 (agosto de 2025) y sigue marcada igual en la documentación de la 9.2. Eso no es una lectura nuestra entre líneas: está en la hoja de ruta pública del producto, en la sección «Storage & Snapshots», como objetivo futuro: «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.»

Dos versiones después —la 9.1 y la 9.2—, quitarle la etiqueta sigue siendo un plan. Y la propia página avisa arriba, con todas las letras, de cómo hay que leerla: «The items below describe development directions and priorities. Not all are planned for immediate delivery.» Más abajo, en la misma lista, hay otro que vale la pena leer si tu cabina es de fibra: «Improve multipath integration and setup experience for Fibre Channel and iSCSI deployments.»

Lo que viene ahora es opinión nuestra, no de la documentación. «Technology preview» no es un juicio sobre si el código funciona —funciona, y la 9.1 trae una tanda de arreglos concretos que confirman que hay gente usándolo en producción—. Es una frase que hay que poder decir en voz alta en una reunión: la función que sostiene nuestro procedimiento de cambios está en preview. Si esa frase se puede decir sin que a nadie se le cambie la cara, adelante. Si no se puede decir, el problema no es técnico y no se arregla con más pruebas de laboratorio.

El detalle que le toca justo al parque viejo

Entre los arreglos de la 9.1 hay uno que no parece gran cosa hasta que piensas a quién le cae encima: «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ón de máquina QEMU no es la versión de Proxmox: es una propiedad de cada VM, y Proxmox la fija deliberadamente para no cambiarle el hardware virtual a un invitado que ya está instalado. En Windows lo hace de forma explícita, y lo dejó escrito al introducir la versión de máquina 9.2+pve1 —una nota de las de Proxmox VE 8.4, no de la serie 9—: «New Windows VMs are pinned to that machine version. Existing Windows VMs are already pinned to an earlier machine version…» Es decir: las máquinas que llevan años funcionando conservan la versión con la que nacieron. Son justamente las que menos te apetece tocar.

No decimos que tus VMs vayan a estar por debajo de la 10 —eso depende de cuándo y con qué versión de Proxmox se crearon, y no lo podemos saber desde aquí—. Decimos que es una comprobación de inventario, no una suposición, y que es de las baratas: sale de un qm config por máquina o de una consulta a la API, y se hace antes de decidir nada. Si el resultado es que veinte VMs heredadas están por debajo, no es que la opción 3 no las cubra: es que la propia nota de la 9.1 dice «fail early when attempting to start a VM with a lower machine version». No arrancan sobre esa storage hasta que se les cambie la versión de máquina, que es un cambio de hardware virtual y se planifica como tal.

Es el mismo patrón que ya nos encontramos con los drivers: la migración copia el disco entero sin perder un byte y luego Windows no arranca porque la controladora que espera no está. Lo que no viaja nunca es el dato; es la suposición que el invitado hizo el día que se instaló.

La salida que propone el propio fabricante (y por qué no es lo mismo)

La documentación tiene una sección titulada «Alternatives to Snapshots», y no propone otro snapshot. Propone cambiar de estrategia: «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.»

Y la propuesta tiene sustancia técnica, no es un consuelo: «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.» Copia incremental de verdad y arranque mientras se restaura. Funciona.

Aquí va nuestra objeción, y va marcada como opinión. Un snapshot y una restauración resuelven el mismo miedo pero no son el mismo control. El snapshot es una red de seguridad que se pone y se quita la misma persona que está aplicando el cambio, dentro de la misma ventana, y cuya vuelta atrás se decide en treinta segundos sin pedirle permiso a nadie. La restauración tiene otro RTO, a menudo otro dueño y casi siempre otra conversación. En cuanto deshacer un cambio deja de ser gratis para el que lo hace, se deshacen menos cambios: la gente aguanta con el sistema medio roto un rato más «a ver si se arregla». Eso no sale en ninguna tabla de funcionalidades y es, en nuestra experiencia, el efecto real.

Así que sí a Proxmox Backup Server —lo montamos en todos los clústeres, con snapshots o sin ellos—, pero no como sustituto silencioso del snapshot. Si vas a operar así, que sea una decisión dicha en voz alta y con el procedimiento de cambios reescrito, no un descubrimiento del primer martes de parches.

El árbol de decisión que firmamos

Cuatro ramas, por orden. No es una lista de buenas prácticas: es el orden en que preguntamos nosotros cuando entramos en un proyecto de estos.

1. ¿Tu cabina sabe hablar NFS y te sobra red para ello? Entonces la respuesta suele ser NFS, no un LUN. Snapshots con qcow2, camino recorrido por mucha gente, y una configuración que no arranca con una etiqueta de preview. El peaje está escrito y hay que aceptarlo con los ojos abiertos: sin snapshots de contenedores, y con el rendimiento de un sistema de ficheros en red, que no es el de un LUN en fibra. Si tus cargas pesadas son bases de datos, mídelo antes en lugar de discutirlo.
2. ¿El fabricante de tu cabina tiene plugin para Proxmox? Pregúntalo por escrito y pide dos cosas concretas: si el plugin implementa snapshots y en qué versiones de Proxmox está soportado. Esa respuesta cambia el proyecto entero y es gratis conseguirla. Si tarda tres semanas en llegar o llega en condicional, eso también es información.
3. Si te quedas en LUN + LVM-thick con volume-chain, trátalo como lo que está etiquetado que es. Eso significa cuatro cosas concretas, no una declaración de intenciones: inventario de versión de máquina QEMU antes de encenderlo; la función probada en un clúster de pruebas con el mismo modelo de cabina, no con un disco local; el apartado «mientras esto siga en preview hacemos X» escrito en el procedimiento; y Proxmox Backup Server operativo y con una restauración real cronometrada, no una prevista. Y ojo a la letra pequeña que ya trae hoy: con estado TPM, «the top-most snapshot cannot be removed while the VM is running».
4. Y si al hacer estas cuentas la cabina deja de salir a cuenta, dilo. Hay un punto en el que reaprovechar el hierro cuesta más en horas, en riesgo y en peajes operativos que lo que ahorra en la factura, y ese punto llega antes de lo que la gente espera. Ahí es donde empieza a tener sentido la primera frase de la documentación, la de «we generally recommend Ceph»: almacenamiento distribuido sobre los propios nodos, con snapshots nativos y sin cabina en el centro. Es más cambio y más inversión inicial, y no siempre es la respuesta —lo hemos desaconsejado en clústeres pequeños—, pero deja de arrastrar una decisión de 2019 durante otros cinco años. Y trae su propia letra pequeña, que también hemos contado: rotar una clave de Ceph no se termina reiniciando la VM.

Sea cual sea la rama, la decisión se toma antes de mover la primera máquina, porque es la única de todo el proyecto que después sale cara de cambiar: mover treinta VMs de un LUN con LVM-thick a NFS no es cambiar una casilla, es repetir la migración entera. Es el mismo motivo por el que insistimos en escribir el plan de vuelta atrás antes de empezar y no cuando hace falta.

Cuándo quedarse la cabina es, sin discusión, lo correcto

Nada de lo anterior es un argumento para tirar una cabina que funciona. Hay dos situaciones que no salen en el árbol de decisión y que inclinan la balanza del lado de quedársela. Una: que la mayoría de tus VMs sean de las que nunca se parchean en caliente, porque tienen su propia ventana y su propia copia; ahí el snapshot que se pierde no lo usaba nadie. Dos: que el clúster sea pequeño y no haya ni presupuesto ni nodos para plantear almacenamiento distribuido en condiciones, que es más habitual de lo que parece.

Lo que no es defendible es no haberlo mirado. Y si al mirarlo sale que hoy no toca migrar, también es una respuesta válida: ya escribimos sobre cuándo NO migrar de VMware a Proxmox, y el almacenamiento compartido es uno de los motivos que aparecen ahí con nombre propio.

La cabina no se discutió porque estaba pagada. El snapshot se discutirá seis meses después, un martes por la tarde, con el parche a medio aplicar. Y para entonces ya no será gratis.

Lo que no afirmamos

No decimos que Proxmox sea peor que VMware en almacenamiento compartido, ni al revés: decimos que reparten el trabajo de forma distinta y que eso tiene consecuencias operativas concretas. No tenemos números comparativos de rendimiento entre NFS y LUN sobre la misma cabina, así que no damos ninguno; medirlo en tu hierro es parte del trabajo. No hemos probado los plugins de todos los fabricantes de cabinas y no podemos decir cuáles implementan snapshots. «Technology preview» es la etiqueta que pone Proxmox, no un juicio nuestro sobre la estabilidad del código, y la propia hoja de ruta avisa de que sus puntos no tienen fecha comprometida —así que tampoco afirmamos cuándo saldrá de preview—. No sabemos qué versión de máquina QEMU tienen tus VMs; por eso lo planteamos como comprobación y no como diagnóstico. Y no somos parte interesada: no revendemos licencias de Proxmox ni de VMware ni cabinas de nadie.

Nota de fuentes

Todo consultado el 18 de septiembre de 2026, descargando el texto original de las páginas y no una cobertura de segunda mano. Uno: el artículo «Migrate to Proxmox VE» del wiki oficial, secciones Storage, Storage boxes (SAN/NAS), Alternatives to Snapshots y Unsupported File Systems: de ahí salen la recomendación de Ceph, el encabezado «As of Proxmox VE 9.2 (May 2026), there are at least the following options», las siete opciones con sus ventajas y desventajas literales, la descripción del papel de los plugins de almacenamiento, la nota de multipath, la frase sobre el soporte empresarial y los sistemas de ficheros no soportados, y el párrafo de copias con dirty bitmap y live-restore. Dos: la página Roadmap de Proxmox VE, de donde salen el aviso de cómo leerla («Not all are planned for immediate delivery»), el objetivo de sacar snapshots as volume chains de tech preview, el punto de mejorar multipath en despliegues FC/iSCSI, y —del histórico de versiones de la misma página— la entrada de Proxmox VE 9.0 que introduce los snapshots como cadenas de volúmenes, la tanda de arreglos de la 9.1 con la línea de la versión de máquina 10 o superior, y —de la entrada de Proxmox VE 8.4, no de la serie 9— la nota sobre el anclaje de versión de máquina en invitados Windows. Lo que es opinión nuestra y va marcado como tal en el cuerpo: que la cabina es la decisión más barata y la que más cambia la operación diaria; la lectura de «technology preview» como una frase que hay que poder decir en una reunión; la diferencia de efecto real entre un snapshot y una restauración; el árbol de decisión de cuatro ramas; y la lista de casos en los que quedarse la cabina es lo correcto.

Imagen de portada: fotografía de una cabina de disco en rack, de Wikimedia Commons (CC BY-SA), recortada por nosotros. Los textos y la marca los añadimos encima.