LVM: la gran mentira corporativa del almacenamiento (o por qué tus medios de almacenamiento no son piezas de Lego).En Entropía binaria siempre defendimos a rajatabla la filosofía KISS (Keep It Simple, Stupid) y la soberanía sobre nuestros sistemas. Creemos en el software que hace una sola cosa y que la hace bien, y en mantener el control absoluto sobre los fierros. Pero de vez en cuando, la industria nos quiere vender espejitos de colores, empaquetando complejidad innecesaria bajo la promesa de la "comodidad". Hoy vamos a hablar de una de las peores basuras corporativas que se han estandarizado en el mundo Linux: el Logical Volume Manager, o LVM.
Te lo venden en todos los manuales y cursos genéricos como la solución definitiva. Te dicen que con LVM administrar discos es como jugar con piezas de Lego: podés poner y sacar unidades en caliente, expandir el espacio mágicamente y ser feliz.
Lo piden en "LinkedIn" y muchas veces puede llegar a ser bueno incluirlo en tu CV, solo para agarrar ese laburo.
Pero es una profunda y absoluta mentira.
El ADN de LVM.
Al código original de LVM lo escribió un alemán llamado Heinz Mauelshagen en 1998. El tipo trabajaba para una empresa llamada Sistina Software. ¿Y de dónde sacó la inspiración? Copió el diseño del administrador de volúmenes de HP-UX (el pesado UNIX propietario de Hewlett-Packard), que a su vez estaba basado en el sistema de Veritas. Desde su ADN, es tecnología pensada para armarios llenos de discos en datacenters de los años 90.
Como a Red Hat no solo produce este tipo de tecnologías basura sino que también le interesa adquirirlas cuando no las pueden crear en casa, la necesitaban para vender soporte caro a los bancos (que tenían servidores de base de datos gigantes), y en 2003 terminan comprando Sistina Software. A partir de ahí, Red Hat adoptó a LVM como su hijo pródigo, lo estandarizó (lo metieron por defecto en los instaladores de RHEL y Fedora) y financiaron el desarrollo de LVM2. Por eso, hoy en día, LVM es sinónimo del ecosistema Red Hat/SUSE y su filosofía de "venderte la cura para la enfermedad de complejidad que ellos mismos te encajaron de prepo", solo porque a ellos les sirve, no a vos, como siempre.
Mi experiencia en el barro: preso en mi propio sistema.
Hablo desde la experiencia cruda, porque cometí el error de probarlo en mi instalación diaria hace tiempo, cuando todavía usaba openSUSE, que lo ofrece en su instalador como "una opción más a considerar". El resultado fue catastrófico; quedé más preso y atado de manos que si hubiera comprado un producto de Apple. No podía zafar de ninguna manera de ese ecosistema sórdido.
El mito del "Lego" se me desmoronó en la cara el día que necesité desconectar físicamente un disco duro secundario. Era una unidad que solo contenía datos intrascendentes, archivos sueltos. Nada del sistema operativo estaba ahí. Tiré del cable SATA y, al encender la máquina, se me jodió (sí, no hay otra palabra posible, creeme) todo el sistema LVM entero. El núcleo entró en pánico y la máquina se negó a arrancar.
¿Por qué? Porque para esta tecnología de mierda (no hay otra palabra posible), vos no tenés discos independientes. Tenés una "bolsa negra", una volqueta con tapa. Si le sacás un bloque a esa bolsa, aunque sea de datos inútiles, el gestor asume que toda la estructura está corrupta. No opera en caliente un carajo; si no le avisás por terminal con comandos rebuscados que vas a retirar un volumen, te destruye el acceso al resto.
Y ni se te ocurra intentar formatear una de esas particiones lógicas por tu cuenta. Al hacerlo, le cambiás el UUID a la partición. La capa de LVM pierde el rastro, el fstab enloquece y, de nuevo, te cargás todo el arranque del sistema. Es una trampa mortal diseñada para alejarte del control real de tu máquina.
Humo corporativo: ¿quién usa realmente esto?
Nos repiten que es un "estándar de la industria". Pero hagámonos una pregunta seria: ¿Google, Netflix, Spotify o Anthropic usan LVM en sus servidores de producción masiva?
La respuesta es un rotundo "no".
Esos gigantes tecnológicos no pierden el tiempo con un administrador redimensionando volúmenes lógicos a las tres de la mañana. Operan con sistemas de archivos distribuidos y tratan a los servidores como tristemente se trata al ganado. Si un disco se llena o falla, el nodo se descarta, el tráfico se redirige y se levanta una máquina nueva. LVM ahí es puro ruido, una capa de abstracción inútil que solo agrega puntos de fallo.
LVM es, en esencia, tecnología heredada para infraestructuras corporativas monolíticas y dinosaurios informáticos. Está pensado para ese viejo servidor Red Hat en el sótano de un banco que corre una base de datos gigante que no se puede apagar nunca, o para tapar la pésima planificación de hardware de un administrador que necesita meter tres discos nuevos a un NAS departamental sin cortar el servicio. Para tu PC de escritorio, para tu notebook o para un servidor web limpio, es un estorbo. Es el ejemplo perfecto de una NTI (Nueva Tecnología Innecesaria).
Conociendo al enemigo: cómo funciona la trampa.
Yo fui librero durante 15 años. Llegué a odiar a autores como Osho y Paulo Coelho, y a muchos otros que ni siquiera operaban en ese nivel, lucrando con las miserias de la gente de a pie. Una vez, una clienta me dijo "si no lo leíste no podés criticarlo solo por la "pinta" o por las contratapas de sus libros". Más allá de que ese es un error bastante importante, porque vos podés informarte sobre esdta clase de fantasma literario por artículos y charlas que dan escritores de verdad, leí, muy a mi pesar y finalmente "El alquimista". ¿Te imaginás lo que pasó cuando la clienta volvió?
Para odiar algo con fundamentos técnicos, primero hay que entender cómo funciona.
El problema central de LVM es que destruye la relación directa entre el sistema operativo y el metal, inyectando tres pesadas capas de abstracción.
Vamos a desarmar esta arquitectura "de arriba hacia abajo".
1. PV (Physical Volume - Volumen físico).
Esta es la capa base, el metal real. Un PV puede ser un disco duro entero (/dev/sdb) o una partición de hardware clásica (/dev/sda2). En un sistema limpio, acá es en donde formateás y guardás tus datos. Pero en LVM, al hardware se lo "marca" y se lo vacía de identidad para entregárselo al gestor. El disco deja de ser un disco para convertirse en un simple ladrillo ciego.
2. VG (Volume Group - Grupo de volumen).
Acá es en donde ocurre el desastre lógico. LVM agarra todos esos "ladrillos" (los PVs) y los mete adentro de una gran "caja de fierro", fusionándolos. Este es el VG. Si metiste un disco de 500GB y otro de 1TB, el VG le dice al sistema: "hola, soy un gran tanque de 1.5TB".
El problema mortal reside en que los datos se esparcen por este tanque de forma abstracta. Por eso, cuando yo saqué mi disco de datos en openSUSE, el VG sintió que le habían arrancado un pedazo de su propia carne y bloqueó toda la estructura.
3. LV (Logical Volume - Volumen lógico).
Como el sistema operativo no puede instalarse en una "volqueta", LVM tiene que crear particiones virtuales para engañarlo. Esos son los LVs. Dentro de tu gran Grupo de Volumen, vos recortás pedazos de espacio virtual y les ponés nombre: un LV para la raíz (/), un LV para la swap, otro para el /home.
A los ojos de tu sistema Linux, estos LVs parecen particiones reales y recién a ellos se les da un formato (ext4, xfs). Pero es una ilusión; por debajo, están fragmentados y dependientes de esa gran "bolsa frágil" que es el VG.
Conclusión para administradores de verdad.
La soberanía digital empieza por entender exactamente dónde están guardados nuestros bits. Cada capa de abstracción que metemos entre el software y el hardware es un lugar oscuro donde los problemas se esconden y se multiplican.
Si querés un sistema robusto, rápido y del que tengas el control absoluto, mantenete alejado de LVM. Usá lsblk para mirar el mapa, cfdisk para esculpir el metal con precisión, dale un formato directo y montalo limpio en tu fstab mediante su UUID. Esa es la verdadera forma UNIX. Todo lo demás, es humo corporativo. O, por qué no, mierda corporativa.
Apéndice: cómo RedHat justifica esta basura.
Para poder comprender cómo esta corporación (la cual es la sombra corta de IBM) justifica esta tecnología excrementicia y por qué la implementan en el mundo real, tenés que posicionarte mentalmente en el sótano de un banco o en el datacenter de una multinacional tradicional en donde no importa la filosofía KISS, los principios POSIX, la elegancia del código ni la soberanía digital; ahí lo único que importa es que el servidor todopoderoso no se apague nunca, porque si el sistema de tarjetas de crédito se llega a caer tan solo por 5 minutos, las cabezas seguro empezarán a rodar (porque eso sí les importa, que el capitalismo de consumismo funcione "24-7" y que lo demás reviente tranquilamente porque "eso no es problema de ellos").
Red Hat implementa LVM (pienso que casi exclusivamente) para resolver 3 problemas corporativos de infraestructura pesada que el en el mundo de las particiones físicas no se puede solucionar a menos que se hable de "algunos reinicios de por medio".
Estos son 3 escenarios reales que vi que tienen validez, al menos para comprender este tema.
Escenario 1. Retiro de unidades de almacenamiento a punto de "sonar como arpa vieja": el comando "pvmove".
Imaginemos que en el 5° subsuelo de un Banco existe un servidor que tiene un "grupo de volúmenes" (la "bolsa negra" o "volqueta" de la que te hablé antes) conformado por cuatro "discos duros de gran tamaño". De repente, el sistema de monitoreo avisa que el disco número 3 está reportando errores mecánicos y dando avisos determinantes de que va a morir en cualquier momento.
Si fuera "metal puro", el administrador tendría que apagar el servidor, sacar el disco, poner uno nuevo, colocar el disco dañado en otro equipo, arrancar a ese equipo con un "LiveCD", extraer los datos, copiárselos a un servidor en marcha, en caliente y quién sabe haciendo no se sabe qué peripecias - porque el consumismo debe continuar vivo - y finalmente rezar, aunque sea ateo, para que no se hayan perdido datos ni hayan quedado configuraciones corruptas.
Con "LVM", el administrador conecta un disco nuevo al rack en caliente. Lo mete a la volqueta usando vgextend. Luego, ejecuta el comando mágico de esta tecnología: pvmove. Este comando agarra todos los bloques de datos del disco que está fallando y los muda físicamente al disco nuevo, en segundo plano, mientras el servidor y la base de datos siguen atendiendo clientes sin enterarse de nada. Cuando termina la mudanza, el administrador saca el disco roto de la volqueta con "vgreduce" y lo tira a la basura; todo dentro de un tiempo de inactividad récord en comparación a lo que sucedería sin LVM.
Escenario 2. El precongelamiento a la velocidad del rayo (los respaldos tipo "snapshot").
Esta es una gran carta bajo la manga para poder "vender" LVM a grandes empresas sin que siquiera sepan de qué se trata. En una base de datos de 10 Terabytes en la cual se están escribiendo transacciones todo el tiempo, no es posible "simplemente copiar los archivos a un disco externo para hacer un respaldo": como los datos cambian mientras se copian, el respaldo queda corrupto.
Acá LVM se usa a modo de "viveza criolla": el administrador ejecuta "lvcreate -s" y toma un snapshot (una instantánea). Esto no copia los 10 Terabytes en el acto a "velocidad imposible", sino que "congela" el estado de los bloques en ese milisegundo exacto. El administrador hace su copia de seguridad leyendo ese "fotograma congelado", mientras los de la "película" en la base de datos, siguen en movimiento.
Escenario 3. El pánico del espacio agotado: "lvextend".
Son las 4 y media de la tarde, el servidor de archivos principal de la empresa llega al 100% de capacidad y nadie puede guardar un documento más. Con particiones tradicionales, habría que migrar los datos a un disco más grande en la madrugada, tal como ya hemos hablado en el escenario 1: apagar el servidor, sacar el disco, poner uno nuevo, colocar el disco dañado en otro equipo...
Con "LVM", el administrador va corriendo al rack, le enchufa tres discos nuevos y los configura para que empiecen a formar parte de la volqueta, ejecutando "lvextend" para hacerle saber al "volumen lógico" que ahora es más grande, y luego utiliza una herramienta como "resize2fs" para estirar el sistema de archivos (el cual posiblemente no sea el legendario ext4 sino alguno estilo "NTI" como btrfs o xfs). En menos de 30 minutos, quizás, "el disco C del "Güíndor Server 2003 con Áti Dirétory", pasa de tener 10 Terabytes de capacidad a tener 26, mientras los empleados del Banco siguen dando préstamos y VISA sigue permitiendo que las personas retiren TVs de 40 pulgadas en cómodas cuotas expedidas en un supermercado barrial.
Quise explicar todo esto para terminar siendo justo con la herramienta pero implacable con su filosofía y advertirte fuertemente en cuanto a su uso. LVM, pese a "sonar interesante", es una herramienta de contingencia corporativa que perpetúa el descontrol y el desorden: es un parche complejo diseñado para que un sysadmin no tenga que apagar un servidor monolítico (así se le llama a los servidores poseedores de la tríada interfaz, lógica de negocio y base de datos) ni se detenga nunca a prever este tipo de problemática de antemano.
Por eso me arruinó la instalación en mi PC y por eso es una porquería para el 99% de los casos de uso normales. No está diseñado para un usuario normal ni para un administrador de servidores que planifica bien su almacenamiento y quiere tener soberanía total sobre sus discos; está diseñado para la desesperación empresarial de no poder apagar un equipo y quizás hasta para ahorrar costos en planificación y mantenimiento.
La regla de oro a esta escala es que el hardware se asume como descartable. Con LVM en servidores realmente imponentes, como podrían ser los de Google para Gemini, Netflix, Spotify, Anthropic, DeepSeek, etc, tendrías que estar manejando más de "100.000 discos duros". Cada día fallarían entre 0 y 50. Con LVM, tendrías que tener a cargo un verdadero ejército de administradores tipeando comandos de rescate las 24 horas. Para evitar eso, a esta escala se usa el Almacenamiento Definido por Software (SDS) y los Sistemas de Archivos Distribuidos, no este "barro en la joya" de LVM.
Red Hat te encaja LVM por defecto para el servidor monolítico de una PyME o de una oficina gubernamental. Pero cuando a Red Hat la contrata una empresa de telecomunicaciones para armar un datacenter realmente grande o un clúster con miles de nodos, Red Hat tampoco usa LVM.
Para la escala masiva, Red Hat compró otra empresa y te vende Ceph (Red Hat Ceph Storage), el cual es un sistema de almacenamiento distribuido por red que lee directamente el disco físico desnudo (BlueStore) saltándose a LVM por completo porque agrega latencia y puntos de falla innecesarios.
¿Viste ahora cómo es la cosa? ¡Saludos!
