¿Así que ya tienes LVM funcionando? ¿Y seguiste mi recomendación de dejar todo el espacio posible en el VG y tus LVs están justitos de espacio? ¿O te has quedado sin espacio en el VG? En este post veremos como ampliar el espacio disponible en los diferentes componentes del LVM.

Ampliar un PV

Aunque no es corriente que un dispositivo «físico» de almacenamiento pueda crecer, este caso se puede dar cuando se trata de una máquina virtualizada, en la que podríamos aumentar el tamaño su disco, o en una máquina en la que ampliemos una partición tradicional, o un RAID, usada como PV. Esta operación (la ampliación del PV), como las que siguen, se puede realizar sin problemas con todo el sistema corriendo, sin tener que parar ningún servicio o desmontar sistema de ficheros. Lo que se denomina «en caliente». Simplemente hay que indicarle al LVM que «estire» el tamaño del PV, hasta su nuevo tamaño completo, con el comando «pvresize DISPOSITIVO«. Veamos un ejemplo:

## Originalmente el PV tenía 400MB
# pvs
 PV VG Fmt Attr PSize PFree 
 /dev/vda3 multimedia lvm2 a-- 396.00m 356.00m
## Se amplia la partición a 500MB y se ejecuta pvresize
# pvresize /dev/vda3
 Physical volume "/dev/vda3" changed
 1 physical volume(s) resized / 0 physical volume(s) not resized
# pvs
 PV VG Fmt Attr PSize PFree 
 /dev/vda3 multimedia lvm2 a-- 496.00m 456.00m
## Ya tenemos 100MB más en el PV y por tanto en el VG

Ampliar un VG

Cuando nuestros LVs han consumido todo el espacio del VG no podremos seguir creciendo éstos cuando lo necesitemos. Para solventar esta situación podemos ampliar el VG añadiendo un PV nuevo. El comando vgextend es muy similar al de creación (vgcreate), simplemente hay que indicar el nombre del VG a ampliar y el (o los) PV(s) nuevo(s) a añadir:

## Inicialmente el VG multimedia tiene 50MB libres y 1 PV
# vgs
 VG #PV #LV #SN Attr VSize VFree 
 multimedia 1 1 0 wz--n- 496.00m 50.00m
## Recuerda "marcar" el dispositivo como PV primero
# pvcreate /dev/vda5
 Writing physical volume data to disk "/dev/vda5"
 Physical volume "/dev/vda5" successfully created
## Añadimos el nuevo PV al VG
# vgextend multimedia /dev/vda5
 Volume group "multimedia" successfully extended
## Ahora nuestro VG tiene 150MB libres y 2 PVs
# vgs
 VG #PV #LV #SN Attr VSize VFree 
 multimedia 2 1 0 wz--n- 592.00m 150.00m

Comentar que lo ideal es que los PVs que pertenezcan al VG tengan características de redundancia y velocidad similares. Si bien es verdad que a la hora de crear LVs podemos elegir de que PV podemos sacar su espacio, si no prestamos atención a esta posibilidad el LVM irá asignando espacio de los PVs según crea conveniente y podríamos acabar con parte de un LV sobre un PV con RAID y otra parte en otro PV sin él. No tendría mucho sentido. Lo mismo que si un PV es muy rápido y otro es lento. Esto no quiere decir que no podamos tener PVs completamente diferentes en un VG, y que podamos usarlos de forma selectiva. Por ejemplo un PV puede ser un RAID y sobre él tener un LV importante, y otro PV puede ser un disco simple que nos permita crear un snapshot del LV principal, quitando esta «carga» temporal del RAID.

Ampliar un LV

El caso más frecuente de ampliación que se nos presentará será el de ampliación de un Volumen Lógico. Si seguiste mi recomendación de no dar espacio en vano a los LVs, es decir dejando la mayor parte de espacio libre en el VG, cuando el espacio usado en el LV vaya creciendo tendremos que ir ampliando el LV. Gracias a que esta operación se realiza «en caliente» no supone ningún inconveniente realizarla en cualquier momento.

Podemos usar dos comandos para realizar esta tarea: lvextend y lvresize. Si bien la sintaxis de ambos es prácticamente idéntica, suelo usar lvextend que sólo amplia, evitando posibles errores con lvresize que acabaran en el LV más pequeño (y el sistema de ficheros jodido, digo… dañado). En ambos casos daremos el nombre del LV (/dev/NOMBRE_VG/NOMBRE_LV) como argumento y usaremos la opción -L para indicar el tamaño nuevo. Como argumento de la opción -L podemos usar el tamaño final (por ejemplo -L2G, para un tamaño final de 2G) o la cantidad que deseamos ampliar, poniendo un «+» delante de ésta (por ejemplo -L+1G, para ampliar un giga). Veamos un ejemplo:

## Nuestro LV tiene 40MB actualmente
# lvs
 LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
 musica multimedia -wi-ao-- 40.00m
## Pedimos una ampliación de 10MB
# lvextend -L+10M /dev/multimedia/musica 
 Rounding up size to full physical extent 12.00 MiB
 Extending logical volume musica to 52.00 MiB
 Logical volume musica successfully resized
## Como el tamaño de las extensiones físicas es de 4MB,
## el LVM ampliará 12MB (3 PEs) en vez de los 10M solicitados.
## El resultado final, 52MB
# lvs
 LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
 musica multimedia -wi-ao-- 52.00m

Aquí no acaba la tarea. Una vez ampliado el LV debemos ampliar el sistema de ficheros (si es que estamos usando el LV para un sistema de ficheros). Si nos fijamos, aunque hemos ampliado el LV, el espacio disponible en el sistema de ficheros siguen siendo los 40MB originales:

# df -h /mnt/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/multimedia-musica 39M 4.5M 33M 13% /mnt

En función del sistema de ficheros debemos usar un comando u otro:

## Para XFS
## xfs_growfs LV 
## o
## xfs_growfs PM (PM -> Punto de Montaje, p.e. /mnt)
##
## Para reiserfs
## resize_reiserfs LV
## o
## resize_reiserfs PM
##
## Para ext3/ext4
## resize2fs LV
## En nuestro caso:
# resize2fs /dev/multimedia/musica 
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/multimedia/musica is mounted on /mnt; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/multimedia/musica to 53248 (1k) blocks.
The filesystem on /dev/multimedia/musica is now 53248 blocks long
## Ahora ya tenemos los 52MB disponibles en el sistema de ficheros
# df -h /mnt/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/multimedia-musica 51M 4.7M 43M 10% /mnt

Como se puede observar en el ejemplo anterior, el sistema de ficheros está en todo momento montado y en uso. No hay escusa para dar espacio de más a un LV y dejar «seco» el VG, impidiendo usar el espacio libre para cualquier necesidad futura, como los snapshots que veremos en un futuro post.

$ exit

Si mis dibujos no te dejaron muy claro los conceptos básicos del LVM no te preocupes, ahora lo explicaré desde el principio con los comandos de gestión del LVM. Seguro que quedará más claro.

Empezar de cero a montar LVM en un sistema ya en marcha no es lo más común, ya que lo ideal es hacerlo en el momento de la instalación, pudiendo así incluir todos los discos por completo. Casi todas las distribuciones permiten hacerlo automáticamente, aunque el resultado final no suele ser ideal (ver Consideraciones finales). Cuando comprendas el funcionamiento podrás usar el instalador de tu distribución para crear una estructura LVM personalizada que tenga más sentido que la que propone el instalador sin preguntar.

Entregando dispotivos de almacenamiento al LVM (PV)

El primer paso para usar LVM es decidir que dispositivos de almacenamiento queremos usar. Pueden ser discos, dispositivos RAID por software, particiones, etc. Lo más importante en este paso es que al LVM le daremos el dispositivo para que lo gestione y, salvo raras excepciones, no volveremos a tocar el dispositivo directamente. Nada de darle una partición al LVM y luego crear un sistema de ficheros en ella. Dicho de otra forma, no le toques los PVs al LVM.

La forma de entregar un dispositivo al LVM es marcarlo como un Physical Volumen (PV). Cuando vayas a crear un PV asume que la información que contenga hasta ese momento ya no es tuya, dala por perdida. Así que cuidado con equivocarse con el nombre del dispositivo en el comando pvcreate. Este comando básicamente indica que desde su ejecución el dispositivo indicado como argumento pasa a ser de dominio del LVM. Ejemplos:

# Estos comando deben ser ejecutados con el usuario root
# Normanlment los usuarios no pueden jugar con los discos :-)
# Marcar el primer disco, por completo, como PV
pvcreate /dev/sda
# Marcar varias particiones como PV
pvcreate /dev/sda3 /dev/sdb1 /dev/sdc1
# Marcar un dispositivo RAID por software como PV
pvcreate /dev/md0

Una vez «marcado» un dispositivo como PV, podemos ver información del mismo con los comandos «pvs» y «pvdisplay«:

# pvcreate /dev/vda3
 Writing physical volume data to disk "/dev/vda3"
 Physical volume "/dev/vda3" successfully created
# pvs
 PV VG Fmt Attr PSize PFree 
 /dev/vda3 lvm2 a-- 400.00m 400.00m
# pvdisplay /dev/vda3
 "/dev/vda3" is a new physical volume of "400.00 MiB"
 --- NEW Physical volume ---
 PV Name /dev/vda3
 VG Name 
 PV Size 400.00 MiB
 Allocatable NO
 PE Size 0 
 Total PE 0
 Free PE 0
 Allocated PE 0
 PV UUID q2noaK-2apE-kkGe-MnNA-IzuE-ICDY-3MiKns

En este ejemplo cabe destacar el tamaño del PV, /dev/vda3, 400M, que están por completo libres y que en la columna «VG» (del comando «pvs«) o la fila «VG Name» (en «pvdisplay«) no hay ningún valor. Es decir, el PV está a disposición del LVM pero no pertenece a ningún VG, por lo que por ahora no podemos usarlo (Allocatable NO). Por ahora no entraré en la definición de PE, no quiero meter más conceptos y no es necesario a estas alturas.

Creando un Grupo de Volúmenes (VG)

Como comenté en la entrada anterior, un VG es una especie de disco duro virtual. Su tamaño viene dado por la suma del espacio de los PVs que lo componen. Y es del espacio disponible en el VG de donde crearemos los Volúmenes Lógicos (LVs, algo similar a las particiones). Son los LVs los que finalmente usaremos para crear sistemas de ficheros, espacio para swap, discos para máquinas virtuales, etc.

El comando de creación de un VG es extremadamente sencillo. Simplemente le daremos como primer argumento el nombre del VG que estamos creado y a continuación el/los dispositivo(s) (marcados como PVs previamente) que queremos que lo compongan:

# Creando un vg llamado "multimedia" con un PV
vgcreate multimedia /dev/vda3
  Volume group "multimedia" successfully created
# Creando un vg con más de un PV
vgcreate produccion /dev/sdb /dev/sdc /dev/sdd
  Volume group "produccion" successfully created

Importante en este punto es dar un nombre identificativo al VG. Una de las ventajas del LVM es que vamos a poder dar nombre significativos a nuestro almacenamiento. No pierdas esta ventaja llamando a los VGs algo como «vg00». Yo tengo VGs llamandos «raid» y «sinraid» en máquinas que tienen parte de los discos en RAID y otra parte no. Ese nombre me permite, a la hora de crear un LV, saber si mis datos estarán protegidos (y/o acelerados) por el RAID o están en un simple disco. Tengo máquinas que tiene un VG llamado «interno» (formado por los discos físicamente dentro de la máquina) y otro llamado «cabina», porque sus discos están en una cabina externa. Igualmente podríamos tener «producción» y «desarrollo», o «sistema» y «datos». Para gustos los colores, pero aprovecha el poder elegir el nombre 🙂 Huelga decir que es mejor evitar símbolos especiales (como espacios), acentos, eñes y esas cosas que podrían dar problemas en nombres de dispositivos.

Una vez creado el VG podemos ver información del mismo con los comandos «vgs» y «vgdisplay«:

# vgs
 VG #PV #LV #SN Attr VSize VFree 
 multimedia 1 0 0 wz--n- 396.00m 396.00m

# vgdisplay
 --- Volume group ---
 VG Name multimedia
 System ID 
 Format lvm2
 Metadata Areas 1
 Metadata Sequence No 1
 VG Access read/write
 VG Status resizable
 MAX LV 0
 Cur LV 0
 Open LV 0
 Max PV 0
 Cur PV 1
 Act PV 1
 VG Size 396.00 MiB
 PE Size 4.00 MiB
 Total PE 99
 Alloc PE / Size 0 / 0 
 Free PE / Size 99 / 396.00 MiB
 VG UUID xuYff2-maw7-0ldW-PiLv-xZ6F-NFa3-3gNPod

Con estos comandos podemos comprobar que nuestro VG se llama «multimedia», está compuesto de un PV, todavía no tiene ningún LV creado y dispone de 396MB libres. Las Physical Extensions (PE) son las unidades de asignación mínima del LVM. Por defecto son de 4MB (aunque se puede cambiar en la creación del VG). Es decir, cada vez que creemos un LV lo haremos en múltiplos de (por defecto) 4MB. Pero esto no es algo que os deba preocupar por ahora.

A por el producto final, Volúmenes Lógicos (LV)

Una vez tenemos un VG ya podemos crear los dispositivos que realmente usaremos. Los volúmenes lógicos (LV) pertenecen a un VG, del que toman su espacio. Pueden crearse, borrarse y crecer sin necesidad de reiniciar la máquina o parar servicios (bueno, para borrarlos hay que dejar de usarlos primero, obvio).

Un LV puede usar espacio de un solo PV, o de varios. En este último caso puede deberse a que vaya creciendo con el tiempo, y ya no quede espacio en el PV original, o que al crearlo hemos decidido que use varios PVs (por motivos de rendimiento, por ejemplo). Pero esto lo veremos en próximas entradas del blog. Por ahora nos centraremos en la creación de un LV simple.

Para crear un LV, con el comando lvcreate, debemos indicarle el VG al que pertenece (como argumento del comando), el tamaño (en PEs con la opción -l o en megas/gigas/teras con -L) y optionalmente, pero muy recomendable, el nombre que queremos darle (-n). Emplos:

# Un LV de 40MB en el VG multimedia para guardar música
lvcreate -L 40M -n musica multimedia

# O especificando el número de PEs (de 4MB por defecto)
lvcreate -l 10 -n musica multimedia

Una vez más, aprovecha para darle un nombre representativo del contenido que habrá en él. Desde este momento la forma de referirse al LV (para crear el sistema de ficheros, montarlo, o cualquier uso que le vayamos a dar) será: /dev/NOMBRE_DEL_VG/NOMBRE_DEL_LV. En este ejemplo: /dev/multimedia/musica. En realidad ese nombre es un enlace al dispositivo creado por el subsistema del kernel encargado del LVM, el Device Mapper. El nombre del dispositivo real puede variar y será del tipo /dev/dm-##. Por eso es importante usar /dev/VG/LV, que siempre apuntará al dispositivo real correcto. También podemos encontrarnos referencias en el sistema al LV como /dev/mapper/multimedia-musica, es decir /dev/mapper/VG-LV. Mi recomendación es que uses siempre /dev/VG/LV y así no hay líos 🙂

Al igual que en los pasos anteriores, podemos ver información sobre el LV creado con los comandos «lvs» y «lvdisplay«:

# lvs
 LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
 musica multimedia -wi-a--- 40.00m

# lvdisplay -m
 --- Logical volume ---
 LV Path /dev/multimedia/musica
 LV Name musica
 VG Name multimedia
 LV UUID KTtf7H-z5kt-68f6-8B8r-cNk0-OUBa-2cRFfe
 LV Write Access read/write
 LV Creation host, time curso, 2014-10-30 18:35:31 +0100
 LV Status available
 # open 0
 LV Size 40.00 MiB
 Current LE 10
 Segments 1
 Allocation inherit
 Read ahead sectors auto
 - currently set to 256
 Block device 253:0

 --- Segments ---
 Logical extent 0 to 9:
 Type linear
 Physical volume /dev/vda3
 Physical extents 0 to 9

Podemos ver el tamaño de nuestro LV (en megas o en LEs), el nombre que tiene, el VG al que pertenece, y si en «lvdisplay» añadimos la opción «-m» veremos en donde se encuentra localizado físicamente el LV (que PV(s) a usado el LVM para obtener el espacio del LV, destacado en negrita en el ejemplo anterior).

Ya está listo para usar. Podemos crear un sistema de ficheros en él y montarlo como cualquier otro dispositivo de almacenamiento:

# mkfs.ext4 /dev/multimedia/musica 
mke2fs 1.42.5 (29-Jul-2012)
....
# mount /dev/multimedia/musica /media/
# df /media/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/multimedia-musica 39663 4587 33028 13% /media

Consideraciones finales

Algo que considero fundamental para poder aprovechar plenamente la flexibilidad del LVM es mantener el máximo de espacio libre en el VG. Es decir, no dar espacio «a lo loco» a los LVs antes de que éstos lo necesiten. Me mata ver como en una intalación nueva todo el espacio del VG es asignado a uno o varios LVs que apenas usan dicho espacio. De nada sirve tener gigas y gigas de espacio libre en un LV. Y un VG sin espacio sin asignar tampoco sirve para mucho (al menos hasta que se aumente con un PV nuevo). Todo espacio libre que pueda estar en el VG nos va a permitir crecer los LVs que lo necesiten o crear LVs nuevos (aunque sólo los necesitemos temporalmente). Si tenemos un VG de 1T y hoy sólo necesitamos un LV que contendrá 100G de información, no le des mucho más (tal vez 150G o 200G), pero deja el resto en el VG para cuando sea necesario. Crecer un LV es sencillo y no causa interrupciones en el servicio, encojerlo es otra historia…

$ exit

El LVM (Gestor de volúmenes lógicos, Logical Volume Manager) es una de mis funcionalidades preferidas en Linux. En esta y posteriores entradas intentaré explicarlo de la forma más sencilla posible para que los que no lo usaron nunca se adentren en él.

De forma simplificada podríamos decir que LVM es una capa de abstracción entre un dispositivo de almacenamiento (por ejemplo un disco) y un sistema de ficheros. En realidad pueden existir múltiples capas, como cifrado con device-mapper, raid software con md, etc. por encima o debajo de LVM. Pero para empezar diremos que LVM estará entre nuestros discos físicos y los sistemas de ficheros (o swap, o almacenamiento de máquinas virtuales,…).

Las ventajas que tienen son múltiples, pero la inicial y más evidente es la flexibilidad frente al particionado tradicional. Pongamos (sin LVM) que creamos 4 particiones contiguas en un disco. Si en el futuro quisieramos aumentar alguna de las 3 primeras no podríamos hacerlo sin borrar las siguientes, lo que es complejo, peligroso y requiere de parada del servicio casi seguro. Pongamos que quisieramos ampliar la última, siempre tendríamos el límite del tamaño del disco. Pongamos que compramos un disco nuevo, y queremos ampliar el espacio de un sistema de ficheros existente en el disco anterior con el espacio nuevo, imposible salvo con «ñapas» de nuevos sistemas de ficheros y puntos de montaje. Con LVM todas esas limitaciones desaparecen. Podemos aumentar sus «particiones» (volúmenes lógicos en adelante) independientemente de que no haya espacio libre contiguo a éstas. Podemos aumentar sus volúmenes lógicos con espacio libre de diferentes discos físicos. E incluso podemos mover volúmenes lógicos entre dispositivos físicos. Y lo mejor de todo… ¡en caliente! Sin desmontar el sistema de ficheros, ¡sin parar un servicio! ¡Brujería! ¡Brujería!

Las ventajas no terminan ahí, y procuraré repasarlas todas en lo sucesivo. Pero empecemos hablando de nomenclatura. Para entender casi por completo el LVM debemos tener muy claros únicamente tres conceptos (y que el concepto es el concepto):

• Volumen físico/Physical Volume (PV). Un volumen físico (PV en adelante) es un dispositivo de almacenamiento, o más correctamente expresado un dispositivo de bloque. Puede ser un disco duro, una partición, una tarjeta SD, un floppy, un dispositivo RAID, un dispositivo loop (que convierte un fichero a un dispositivo de bloque), un dispositivo cifrado, ¡incluso un volumen lógico (LV) puede usarse de PV!. Para simplificar diremos que un PV es una fuente de almacenamiento, es decir un dispositivo que nos proporciona espacio. En el ejemplo más sencillo: el disco duro de nuestra máquina, o una partición en él. Un PV no hay que formatearlo, simplemente se le entregará al LVM «en crudo» y desde ese momento será gestionado por el LVM, no volveremos a tocarlo.

• Grupo de volúmenes/Volume Group (VG). Para poder usar el espacio/almacenamiento de un PV, éste debe pertenecer a un Grupo de volúmenes (en adelante VG). El VG será el centro del universo LVM. Podemos decir que un VG es una especie de disco duro virtual (ya veo a los puristas rasgándose las vestiduras). Un VG es un «disco» compuesto de UNO o más PVs y que crece simplemente añadiendo más PVs. A diferencia de un disco real, un VG puede crecer con el tiempo, sólo hay que «darle» un PV más. En una máquina con un sólo disco podemos crear un VG que esté compuesto por un sólo PV (el disco físico o una de sus particiones). Si con el tiempo nos quedamos sin espacio en el VG, compramos otro disco (PV), lo añadimos al VG y el resto es transparente para sistemas de ficheros, procesos o usuarios. ¡Magia negra!

 

• Volumen Lógico/Logical Volume (LV). Los volúmenes lógicos (en adelante LV) son «el producto final» del LVM. Son estos dispositivos los que usaremos para crear sistemas de ficheros, swap, discos para máquinas virtuales, etc… Por seguir con la analogía del «disco duro virtual» que es el VG, los LVs serían las particiones. Con los que vamos a trabajar realmente. A diferencia de «sus primas» las particiones tradicionales, los LVs pueden crecer (mientras haya espacio en el VG) independientemente de la posición en la que estén, incluso expandiéndose por diferentes PVs. Un LV de 1G puede estar compuesto de 200MB procedentes de un disco duro, 400MB de un RAID software, y 400MB de una partición en un tercer dispositivo físico. El único requisito es que todo los PVs pertenezcan al mismo VG. Por supuesto, aunque posible, no parece una combinación con mucho sentido 😛

 

Perdón por los dibujos, el día que repartían «venas artísticas» no fui al cole. La idea es visualizar los diferentes componentes. Que agrupamos PVs para dar forma (tamaño) al VG, y que con el espacio del VG podemos crear LVs. Los LVs de un VG pueden usar espacio de uno o varios PVs, por supuesto seremos nosotros los que decidamos de que PVs sacamos el espacio que compone un LV. El ejemplo actual no tiene mucho sentido ya que tenemos un LV (pensemos en una «partición») que tiene partes redundadas (el espacio que viene del RAID) y partes que no (el espacio asignado desde el disco o la partición), o partes más rápidas (posiblemente el RAID) y partes más lentas. En este VG (insisto, un tanto extraño) podríamos tener LVs que sólo usaran espacio del disco, y LVs que sólo usaran espacio del RAID, lo que tendría algo más de sentido. En cualquier caso lo normal es que los PVs que forman un VG tengas características (redundancia, velocidad) similares.

Otra ventaja del LVM que ya podemos ver es que los nombres de los componentes los elegimos nosotros, lo que facilita su comprensión. Al crear un VG o un LV, somos nosotros los que decidimos sus nombres. Por tanto nos alejamos de cosas «raras» como sda5, md3, etc. y pasamos a una nomenclatura que nos ayuda a comprender que hay en cada LV:

# Ejemplos de nombres para VGs y LVs
# Un VG para producción, posiblemente con RAID como PVs
# Los nombres de los LVs permiten saber que es lo que contienen
/dev/produccion/datos
/dev/produccion/aplicacion
# Un VG para desarrollo, tal vez sin RAID y con discos "baratos"
/dev/desarrollo/datos
# Una máquina con discos internos y con acceso a una cabina de discos
/dev/interno/raiz
/dev/interno/swap
/dev/cabina/web

Con estos términos claros podemos explicar mejor la flexibilidad del LVM con unos ejemplos:

• Un LV puede crecer siempre que haya espacio libre en el VG al que pertenece. El LVM se encarga de que lo que haya sobre el LV (frecuentemente un sistema de ficheros) vea todo el espacio continuo. Podemos crear inicialmente un LV usando espacio de un PV, pero si posteriormente queremos aumentarlo, aunque no quede espacio en el PV original, podemos usar espacio de cualquier PV que pertenezca al VG. Para el sistema de ficheros será transparente.
• Podemos cambiar el espacio asignado  de un PV a un LV a otro PV (que tenga espacio suficiente libre). Me explico, yo puedo crear un LV de 10G en un PV que sea un disco. Si posteriormente meto en el VG un PV que sea un RAID, podría mover los 10G que estaba usando del disco al RAID, en caliente y de forma transparente al sistema de ficheros y las aplicaciones que lo usan. De forma que si con el tiempo puedo mejorar el hardware de la máquina, no tengo porque volver a crear un sistema de ficheros, copiar los datos y cambiar el montaje. Con LVM simplemente digo: los 10G del LV que están en un PV los quiero mover a un PV diferente. Y el hará la mudanza sin interrumpir el funcionamiento del sistema.
• Para poder disfrutar al máximo de la flexibilidad del LVM es importante tener la mayor cantidad de espacio libre en el VG (volveré a este tema más tarde), pero tarde o temprano nos quedaremos sin espacio en un VG (porque usemos todo el espacio de sus PVs). Bien, esto, que tradicionalmente es bastante complicado de gestionar, con LVM es tan sencillo como darle otro PV al VG. Añadimos un disco (PV) a la máquina y lo asignamos al VG, que pasa a tener todo ese espacio nuevo disponible para cualquiera de los LVs que contenga. O para crear LVs nuevos.

La idea, al menos de esta primera ventaja que nos presta el LVM, es que el almacenamiento no nos imponga límites «artificiales». Nada de particiones que no pueden crecer porque les sigue otra en el disco. O discos que una vez llenos no podemos seguir usando sin hacer malabares. El espacio de mis dispositivos está ahí a mi disposición, para que lo use como me convenga. Para crecer mientras haya espacio libre, para mover los datos entre dispositivos sin que tenga paradas en el servicio. En resumen, los megas son mios y los uso como quiero.

En la próxima entrada empezaré a hablar de los comandos para la gestión del LVM y estarán mucho más claros todos esto ejemplos y funcionalidades. ¿Preguntas? Pon un comentario e intentaré resolverlas.

$ exit