Resize LVM Ubuntu: los errores que cuestan horas

Redimensionar disco LVM Ubuntu en producción es una de esas operaciones que separa a los que saben de los que aprenden en el momento más inoportuno. Con LVM bien configurado, expandir almacenamiento tarda menos de cinco minutos sin bajar el servidor. Sin LVM, el mismo problema puede costar horas o un rebuild completo.

LVM vs particiones raw: Por qué la arquitectura importa

LVM (Logical Volume Manager) es una capa de abstracción sobre el almacenamiento físico que agrupa discos en Physical Volumes, los junta en Volume Groups, y de ahí crea Logical Volumes que el sistema operativo ve como dispositivos de bloque normales. Esta abstracción es lo que hace posible expandir almacenamiento sin interrumpir servicios.

Dos VMs con Ubuntu, misma aplicación, misma nube. Una volvió online con almacenamiento expandido en menos de cinco minutos. La otra estuvo caída durante horas y terminó con un rebuild completo. Según el análisis publicado en dev.to, la diferencia no fue habilidad del administrador sino una sola decisión de arquitectura en el setup inicial: usar LVM o no.

Con particiones raw tradicionales, cambiar el tamaño implica reparticionar, mover datos, y en el peor caso reinstalar. Con LVM, la misma operación es cinco comandos en secuencia.

Cómo el kernel mapea discos expandidos en capas

La arquitectura LVM tiene tres capas claras:

• Physical Volumes (PVs): los discos o particiones reales, inicializados con pvcreate.
• Volume Groups (VGs): pool de almacenamiento que agrupa uno o más PVs.
• Logical Volumes (LVs): los volúmenes que el sistema ve y monta, tallados del VG.

Cuando el disco virtual crece en el hipervisor, el kernel no lo detecta automáticamente. Necesita un rescan explícito. Una vez actualizado el PV con pvresize, los Physical Extents (PE) nuevos quedan disponibles en el VG. Desde ahí, lvextend los asigna al LV que quieras. La capa device-mapper del kernel maneja la traducción de I/O entre el LV y el almacenamiento físico subyacente, transparente para el filesystem que está arriba.

¿Y qué le pasa al filesystem cuando el LV crece? Nada, hasta que explícitamente le avisás. Ese es el paso que más se olvida. Complementá con tu herramienta de CI/CD favorita.

Error clásico: Límites de tabla de particiones (MBR vs GPT)

MBR tiene un límite duro de 2TB. Si tu disco virtual va a superar ese umbral, necesitás GPT obligatoriamente. Intentar expandir una partición MBR más allá de 2TB falla sin mensaje de error claro, lo que genera horas de debugging innecesario.

En VMware específicamente, hay otro gotcha: si tenés snapshots activos, el rescan del disco ampliado puede fallar con un error de snapshot limit. La solución es eliminar todos los snapshots antes de extender el disco en el hipervisor. No hay workaround: los snapshots y el resize simultáneo no se llevan bien.

Paso 1 y 2: Expandir en el hipervisor y forzar rescan sin reiniciar

Primero expandís el disco desde el panel del hipervisor (VMware, KVM, Hyper-V, lo que uses). Esto modifica el tamaño del archivo de disco virtual, pero el kernel de la VM todavía no lo sabe.

Para que el kernel reconozca el espacio nuevo sin reiniciar:

• echo 1 > /sys/class/block/sda/device/rescan
• Verificar con lsblk o fdisk -l que el disco muestra el nuevo tamaño.

Si el disco es sdb o nvme0n1, ajustá el path. Si el rescan falla, revisá primero que no haya snapshots activos en el hipervisor.

Eso sí: en algunos kernels más viejos (pre-3.x) este truco no funciona y sí necesitás reinicio. En Ubuntu 22.04 en adelante, funciona sin problemas. Para más detalles técnicos, mirá mejorar visibilidad en buscadores.

Paso 3 y 4: Ampliar Physical Volume y Logical Volume

Con el kernel viendo el disco más grande, sincronizás el PV:

• pvresize /dev/sda — detecta el espacio nuevo automáticamente.
• Verificar: pvdisplay debe mostrar el tamaño actualizado.

Luego extendés el LV. Tenés dos variantes según qué necesitás:

Comando	Qué hace	Cuándo usarlo
lvextend -L +10G /dev/vgname/lvname	Agrega exactamente 10GB	Cuando querés control preciso y tenés múltiples LVs
lvextend -l +100%FREE /dev/vgname/lvname	Usa todo el espacio libre del VG	Cuando ese LV es el único o querés asignar todo
lvextend -L 50G /dev/vgname/lvname	Fija tamaño total a 50GB	Cuando sabés el tamaño final que querés

Si tenés múltiples Logical Volumes en el mismo VG (ponele, uno para / y otro para /home), podés asignar selectivamente: extendés solo el que necesita espacio. El VG es el pool compartido y vos decidís cómo distribuirlo.

Paso 5: Crecer el filesystem online sin desmontar

Expandir el LV agranda el dispositivo de bloque, pero el filesystem que está montado arriba todavía ve el tamaño anterior. Este paso es el que más se olvida y el que hace que la gente piense que “no funcionó”.

Para ext4 y ext3:

• resize2fs /dev/vgname/lvname
• Funciona con el filesystem montado (online resize) en kernels 2.6+.

Para XFS:

• xfs_growfs /punto/de/montaje
• XFS usa el punto de montaje, no el dispositivo. Si montaste en /, es xfs_growfs /.

Subís el LV, corre el resize, subís df -h y el espacio apareció. Funciona bárbaro. El tema es que muchos llegan hasta el lvextend y dan por terminado el trabajo (spoiler: falta el paso más importante).

Una salvedad: el shrink (reducir tamaño) sí requiere desmontar primero, hace un fsck, reduce el filesystem, y después reduce el LV. El orden es el inverso al de expand, y en ext4 es soportado. En XFS directamente no podés shrink.

Verificación en cada capa y troubleshooting práctico

Si después de todo el proceso el espacio no aparece, hay que diagnosticar capa por capa. Los comandos son distintos para cada nivel: Esto se conecta con lo que analizamos en ejecutar scripts sin depender de API.

Capa	Comando de verificación	Qué chequeás
Filesystem	df -h	Espacio disponible como ve el OS
Logical Volume	lvdisplay	Tamaño del LV, porcentaje usado
Volume Group	vgdisplay	Free PE / Size disponible
Physical Volume	pvdisplay	Tamaño total del PV
Disco raw	lsblk o fdisk -l	Tamaño que ve el kernel

Tres casos típicos de troubleshooting:

• pvdisplay muestra tamaño viejo: faltó correr pvresize después del rescan del disco.
• vgdisplay muestra Free Size pero df -h no cambió: faltó lvextend o resize2fs.
• lvdisplay muestra tamaño nuevo pero df -h no: faltó el resize del filesystem (el paso más olvidado).

Si estás en un VPS o servidor dedicado en la nube y la operación de expandir te resulta un camino largo, donweb.com tiene planes con almacenamiento escalable que simplifican estas gestiones desde el panel, sin necesidad de meterte en la consola para cada resize.

Errores comunes al expandir particiones LVM

Usar resize2fs en un filesystem XFS

Son dos comandos distintos para dos filesystems distintos. resize2fs es para ext2/ext3/ext4. En XFS es xfs_growfs y recibe el punto de montaje, no el dispositivo. Confundir los dos da error inmediato.

No hacer rescan antes de pvresize

Si corrés pvresize sin haber hecho el rescan del kernel, el PV ve el tamaño viejo y no actualiza nada. El orden es estricto: rescan del kernel primero, después pvresize. Cualquier otro orden no funciona.

Asignar todo el espacio libre a un solo LV en un sistema con múltiples volúmenes

Usar -l +100%FREE sin pensar cuando tenés varios LVs le da todo el espacio disponible a uno solo. Si después necesitás expandir otro, no hay Free PE. Mejor asignar con -L +XG y dejar algo de margen en el VG para expansiones futuras.

Intentar hacer shrink de XFS

XFS no soporta shrink. Punto. Si necesitás reducir un volumen XFS, la única opción es hacer backup, reformatear, y restaurar. Muchos aprenden esto tarde.

Preguntas Frecuentes

¿Cómo redimensiono un disco LVM en Ubuntu sin desmontar?

Para expansión (crecer): el proceso completo se hace con el filesystem montado. Expandís el disco en el hipervisor, hacés rescan del kernel, corres pvresize, lvextend, y finalmente resize2fs (ext4) o xfs_growfs (XFS). Ninguno de estos pasos requiere desmontar. Para reducir (shrink) sí es necesario desmontar primero, y con XFS directamente no es posible. Lo explicamos a fondo en proteger tu infraestructura.

¿Por qué no veo el espacio libre después de ampliar el disco virtual?

Porque ampliar el disco en el hipervisor es solo el primer paso de cinco. El kernel necesita un rescan explícito para ver el nuevo tamaño, luego LVM necesita que el PV y el LV se actualicen, y finalmente el filesystem necesita su propio comando de resize. Si df -h no muestra el espacio, verificá capa por capa con pvdisplay, lvdisplay, y lsblk.

¿Cómo hago crecer un volumen lógico en Ubuntu sin perder datos?

Con LVM la expansión es no destructiva: lvextend -L +10G /dev/vgname/lvname agrega espacio al LV, y después resize2fs o xfs_growfs le avisa al filesystem. Nunca se toca la partición de arranque ni los datos existentes. El riesgo de pérdida de datos está en operaciones de shrink, no de grow.

¿Cómo expando un disco virtual en Ubuntu con LVM y múltiples volúmenes lógicos?

El espacio nuevo queda disponible en el Volume Group como Free Physical Extents. Podés asignarlo selectivamente al LV que necesite más espacio con lvextend -L +XG /dev/vgname/nombre_del_lv. El resto del VG queda disponible para otros LVs. Esta flexibilidad es una de las razones principales para usar LVM en sistemas con múltiples particiones.

¿Qué diferencia hay entre resize2fs y xfs_growfs?

resize2fs es para filesystems ext2, ext3, y ext4, y recibe el path del dispositivo (/dev/vgname/lvname). xfs_growfs es para XFS y recibe el punto de montaje (/, /home, etc.). Usarlos al revés da error. Para verificar qué filesystem tenés, df -T muestra el tipo de cada partición montada.

Conclusión

Redimensionar disco LVM Ubuntu tiene cinco pasos bien definidos y un orden que no es opcional. El proceso entero tarda menos de cinco minutos si sabés lo que estás haciendo, y el sistema no baja en ningún momento. La diferencia entre ese escenario y un rebuild de horas es haber configurado LVM desde el principio.

Lo que más falla en la práctica es el último paso: crecer el filesystem después de extender el LV. El disco tiene espacio, LVM lo asignó, pero df -h sigue mostrando el número viejo porque nadie corrió resize2fs. Ese comando de diez segundos es el que cierra el ciclo.

Si estás armando servidores nuevos y todavía dudás entre LVM y particiones raw, la respuesta práctica es LVM siempre, especialmente en entornos virtualizados donde el almacenamiento crece con el tiempo.

Fuentes

• dev.to – Resize VM Disk Ubuntu LVM: Common Mistakes and How to Fix Them
• Ubuntu Server Docs – About LVM
• RDR-IT – Ubuntu: Extend LVM partition and disk
• Packet Pushers – Ubuntu: Extend your default LVM space
• Analytics Lane – Redimensionar una partición de disco LVM en Linux