LVM para torpes (III). Ampliando espacio.

¿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

44 comentarios en “LVM para torpes (III). Ampliando espacio.

  1. Francisco

    Hola, fue tan perfecto tu post, que copie el contenido y lo puse en mi blog, aun en construcción para tener la explicación para mi en el futuro, claro que aclare la fuente, inittab.org, En fin la mejor explicación que me he encontrado en internet sobre lvm. Gracias a ti ahora lo entiendo totalmente..Mil gracias por compartir con la comunidad tus conocimientos..Saludos Cordiales.

    Responder
  2. Felipe Castillo

    Muy buena explicacion sobre el manejo de los lvm

    A ver si me puedes ayudar con un problemita que tengo y que no hayo solucion.

    Tengo un disco de dos teras en el cual tengo instalado fedora 20, la verdad batalle mucho para ponerlo a punto en cuanto a aplicaciones, condiguracion de video, impresora en red, etc.

    Ahora quiero actualizar a fedora 23, pero no quiero que se me haga un relajo por lo cual queria clonar mis particiones con «dd» trabajar sobre el clon para que mientras lo adecuo tener el original para trabajar.

    En el disco de 2 teras tengo una particion de 1Gb arrancable donde creo tener el boot y una particion de 843 Gb LVM2, que se creo con la instalacion de fedora 20, estas dos particiones las quiero copiar a un disco de 1 tera, pero no encuentro forma de hacerlo, ya intente con «dd» con gparted y no hay manera.

    Ojala me puedas ayudar a copiarlas para poder actualizar en uno y trabajar en otro.

    Gracias

    Responder
      1. Felipe Castillo

        Gracias por responder.

        En sda que es un disco de 2 teras tengo 4 particiones:
        sda1 boot de 1 giga,
        sda2 lvm2 de 843 gigas, dentro de las cuales esta / /swap /home,
        sda3 ntfs con datos
        sda4 ext4 con datos

        Ahora las particiones sda1 y sda2 las quiero copiar al disco sdb que es de 1 tera
        Sda1 la copio sin problemas y queda como sdb1, sda2 que es la lvm2 no me deja copiarla de ninguna forma, ya intente con dd, con clonezilla y nada.

        Copio los archivos creando una particion en sdb2 con cp y si los copiar pero al intentar arrancar con sdb, me manda a grub rescue>

        Responder
        1. Alberto Gonzalez Iniesta Autor

          Hola Felipe, el problema de copiar un volumen físico (PV) con DD es que estás duplicando UUIDs y nombres de VG, LVs,…
          Nada bueno. Para el sda2 (PV) te recomendaría que hicieras una partición del mismo tamaño en sdb, la marcaras como PV y crearas un VG con diferente nombre al que tienes ahora. Luego te creas los mismos LVs que en el VG original, hasta con el mismo nombre, y luego si puedes usar dd para copiar de un LV al otro.
          Si vas a arrancar luego con el sdb, te tocaría repasar el /etc/fstab que tengas en sdb y reinstalar el grub. Eso se hace mejor con un chroot al LV raiz que tengas en sdb. No es tan simple como copiar y pegar 🙂 Suerte!

          Responder
  3. Mario

    Buenas, una pregunta, si tengo instalado un sistema linux en mi computador y quiero cambiar a LVM, tengo que reinstalar el sistema es decir, puedo crear un LVM sin borrar los datos del sistema?

    Responder
  4. Alberto Gonzalez Iniesta Autor

    Hola Mario, lo más sencillo es reinstalar. De otro modo necesitarías algo de espacio sin particionar para ir creando el LVM a partir de él y según vas moviendo datos ir liberando espacio de las particiones tradicionales. No es trivial. Desde cero quedará mejor organizado también.

    Responder
  5. armando

    Excelente artículo!!

    Gracias por compartir la explicación, lo encontré buscando información porque tengo el siguiente escenario:

    Necesito preparar un servidor de virtualización (utilizando kvm) en el cual tengo dos discos de 2TB cada uno, gracias a tu artículo ya sé cómo puedo optimizar el espacio, pero ahora viene la pregunta, qué esquema me recomiendas que utilice?

    Obviamente se me ocurrió crear un VG y ahí colocar esos 2 discos, pero en cuanto al esquema qué me puedes recomendar? 1LV para las virtuales? 1 LV para backups? tengo entendido que kvm guarda los discos en el /var/lib/libvirt

    Gracias desde ya por tu artículo y por tus recomentaciones.

    Responder
    1. Alberto Gonzalez Iniesta Autor

      Hola Armando, el formato en el que uses los discos es algo muy personal y que sobre todo depende de tus necesidades. No sé si necesitas 2TB para máquinas o con 1TB para máquinas tendrías suficiente. Tampoco que tipos de backup realizarás (1 por máquina? incrementales? cuanto tiempo se almacenarán, …).

      Si realmente no necesitas 2TB para máquinas y con 1TB (+/-) te apañas, dejando otro TB para backups, yo haría:
      – Un RAID1 (espejo) con los dos discos de 2TB. Eso te deja «sólo» 2TB totales, pero a prueba de fallos de disco (de uno, claro).
      – Con ese RAID montaría un sólo VG, y usaría LVs para los discos de las máquinas (en vez de ficheros bajo /var/lib/libvirt). Eso te dará alguna de las ventajas del LVM con los discos virtuales de las VMs. Es decir, un LV para el sistema de ficheros de host kvm, y un LV para cada disco virtual que necesites.

      Pero es sólo una de las muchas posibilidades. Saludos.

      Responder
  6. Jorge Navas

    Excelente tu post. Tengo una duda, en mi sistema actualmente tengo 2 discos físicos /dev/cciss/c0d0p2 (600G) y /dev/cciss/c0d0p1 (2.5T), cada uno está asociado a un PV. Ahora bien tengo 2 VG, Disk1 y Disk2 cada uno asociado a cada PV anterior así:

    PV –> VG
    /dev/cciss/c0d0p2 –> Disk1
    /dev/cciss/c0d0p1 –> Disk2

    Finalmente tengo 6 LV, distribuidos de la siguiente manera:

    VG –> LV
    Disk1 –> root
    Disk1 –> tmp
    Disk1 –> var
    Disk1 –> datos1
    Disk1 –> swap
    Disk2 –> datos2

    Ahora bien, mi problema es que el LV datos1 se quedó sin espacio y no tengo espacio libre en el VG Disk1 para asignarle mas, pensé inicialmente en reducir el tamaño de alguno de los LV dentro del mismo VG para liberar espacio y asignárselo al LV datos1, pero los otros LV dentro del VG Disk1 están justos de espacio.

    En cambio, en el VG Disk2 (2.5T) solo se están utilizando 331G (aprox. 15%). Mi pregunta es la siguiente: Es posible pasar algo de la capacidad no usada en el VG Disk2 al VG Disk1 para luego ampliar el LV datos1? Por supuesto sin colocar en riesgo la información en los LV?

    Si es posible me podrías compartir algunos comandos de ejemplo para realizarlo? Gracias,

    Responder
  7. Alberto Gonzalez Iniesta Autor

    Hola, mucho me temo que no tengo una solución sencilla para tu problema. Si pudieras mover los datos del Disk2 a otro sitio temporalmente y destruir el LV y el VG Disk2, podrías añadir el PV del segundo disco al VG Disk1 y ya disponer de todo el espacio como necesites. Tal vez se podría hacer alguna otra chapuza, pero nada limpio o sencillo.

    Suerte.

    Responder
  8. RonDamon

    ¡Hola!
    Geniales tus posts, sobre todo estos de LVM 🙂
    Quería consultarte una duda que me surge a raíz del consejo de no darle todo el espacio a los LV. En mi caso, iba a hacer eso mismo y te explico la situación.

    En mi PC tengo varios discos duros de almacén, de tamaños dispares, por lo que me gustaría «unificar» todas esas capacidades en una única:

    /dev/sda: 1TB
    /dev/sdb: 500GB
    /dev/sdc: 3TB

    Mi idea era crear un VG con los 3 discos (como PVs) y crear un LV de 4,5TB (el total de los 3).

    ¿Es, entonces, una mala práctica? En principio, como mucho, añadiré algún disco más en el futuro, no tengo otros planes.

    ¡Gracias!

    Responder
  9. Alberto Gonzalez Iniesta Autor

    Hola! Dices que no tienes otros planes, pero …. lo mismo hay otros planes para ti y tú todavía no lo sabes.
    Si en tu LV por ahora no vas a usar más de 500MB, ¿para que necesitas el espacio en él? ¿Y si mañana quieres probar algo en un LV nuevo? Un disco para una máquina virtual, un sistema de ficheros para guardar unos gigas temporalmente… Es posible que no suceda, pero recuerda que para ampliar el LV (en caliente, sin interrupciones) siempre hay tiempo. De todas formas, cada uno tenemos nuestras prácticas. Saludos.

    Responder
    1. RonDamon

      Gracias por tu respuesta.

      La cosa es que me daría miedo que se me acabase el espacio sobre la marcha (descargas, por ejemplo) y no me diese cuenta antes de ampliar el LV.

      Otra cosa que me da cosica es el tema de si me falla uno de los discos duros y pierda toda la información…

      Responder
  10. Alberto Gonzalez Iniesta Autor

    Puedes montar un RAID por software con el disco de 1T y una partición de 1T del disco de 3T. Sólo sería una 1T a prueba de fallos, pero ya es algo. Incluso otro con el de 500MB. Usas el RAID de PV y con lo que no es RAID o creas un VG diferente, o a la hora de crear los LVs prestas atención al PV que les asignas.

    Responder
  11. Carlos

    Hola:
    Instalé Linux Mint 18.1 con LVM en un disco SSD de 250 Gb, de forma automática, lo que instalador quiso hacer. En el mismo Pc tengo otro disco HDD de 2 Tb, que esperaba iba a formar parte del VG cuando hice la instalación, pero se quedó fuera. Ahora voy a incluirlo y tengo la duda de si afectará al rendimiento por ser los dos discos diferentes.
    Un saludo.

    Responder
    1. Alberto Gonzalez Iniesta Autor

      Hola Carlos. No es que vaya a afectar al rendimiento de por sí. Es que tendrás que tener cuidado cuando crees LVs en tu VG y decidir que PV quieres que usen. A la hora de crear o crecer un LV (con lvcreate o lvextend/lvresize) puedes especificar de que PV quieres sacar el espacio (dando el nombre como último argumento de estos comandos). Lo ideal es que uses el SSD con los LVs que tengas ahora en él (para que no tengan espacio de dos dispositivos con diferente velocidad) y que los LVs donde la velocidad no sea importante los crees usando espacio del PV lento (el HDD). Saludos.

      Responder
  12. Gabriel Pineda

    Hola que tal, primero que nada quiero felicitarte por tu blog pero yo Estoy atorado en un gran problema y creo que este tutorial me podría servir Pero no logró hacerlo funcionar mira tengo un servidor Apache corriendo en mi servidor este servidor es para entregar películas y series a usuarios fuera de mi red simplemente dejando salir al servidor por el puerto 80 a los links de las películas y las series El problema es que se me ha llenado el disco duro en la carpeta var www y lo que quisiera hacer es simplemente Añadir y Añadir más discos duros a esta carpeta y que los lea como un solo disco duro para no quedarme sin espacio mientras tenga posibilidad de conectar más discos duros a la placa madre espero puedas ayudarme ya que intenté mil veces tu tutorial y no lo logré 1000 gracias

    Responder
  13. weep

    Disculpa, corrígeme si me equivoco, pero la primera explicación de como redimensionar un PV, no funciona, verdad?
    Es decir, faltan muchas más cosas , como pasar por fdisk o pasar por gparted, me equivoco?
    más que nada porque al hacer el: pvresize /dev/vda3
    Se queda exactamente igual al verlo tanto por pvs como por vgs
    No hace nada.
    Agradecería tu respuesta, gracias y saludos.

    Responder
  14. Alexis

    Me ha encantado el artículo!!! llevaba tiempo queriendo aprender sobre LVM y me he ledio los 3 atículos de una sentada.
    Muchas gracias por la explicación

    Responder
  15. comboz0r

    Nunca comento nada cuando estoy googleando alguna información, pero este howto de lvm realmente está perfectamente explicado, lo puse en practica y todo salio a la perfección!!
    Me gustaría que en algún momento explicaras NFS.

    Saludos!

    Responder
  16. pollo

    Hola, hay varias siglas que se me escapan porque no se bien que significan. Quizás mi pregunta esté respondida mas arriba pero no estoy seguro, por eso la planteo. Mi particion pve (local) indica 100% en uso, y no se como liberar espacio allí (no se cual es) ni si es posible redimensionarla. Por si sirve te acerco mas info:
    # df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 7.8G 0 7.8G 0% /dev
    tmpfs 1.6G 9.0M 1.6G 1% /run
    /dev/mapper/pve-root 2.7G 2.7G 0 100% /
    tmpfs 7.8G 0 7.8G 0% /dev/shm
    tmpfs 5.0M 0 5.0M 0% /run/lock
    tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
    /dev/sdb2 129G 61M 122G 1% /FileServer
    /dev/sda5 118G 895M 111G 1% /isos
    /dev/sda2 511M 304K 511M 1% /boot/efi
    PoolZFS800 739G 128K 739G 1% /PoolZFS800

    # df -i
    Filesystem Inodes IUsed IFree IUse% Mounted on
    udev 2034144 559 2033585 1% /dev
    tmpfs 2039403 776 2038627 1% /run
    /dev/mapper/pve-root 180224 47176 133048 27% /
    tmpfs 2039403 1 2039402 1% /dev/shm
    tmpfs 2039403 9 2039394 1% /run/lock
    tmpfs 2039403 17 2039386 1% /sys/fs/cgroup
    /dev/sdb2 8626176 13 8626163 1% /FileServer
    /dev/sda5 7839744 15 7839729 1% /isos
    /dev/sda2 0 0 0 – /boot/efi
    PoolZFS800 1547951038 6 1547951032 1% /PoolZFS800

    Desde ya muchas gracias por tu predisposición a ayudar.

    Responder
    1. Alberto Gonzalez Iniesta Autor

      Buenas, lo que tienes al 100% es el sistema de ficheros raíz, que se encuentra sobre el LV llamado /dev/pve/root. Primero tienes que ver si tienes espacio libre en el VG, con el comando «vgs». Y de tener espacio, aumentar el tamaño del LV (y su sistema de ficheros). Por ejemplo con un par de gigas más (o lo que consideres):

      lvextend -L+2G -r /dev/pve/root

      Responder
      1. pollo

        Perfecto! Muchas gracias. Con tu ayuda recuperé mi servidor de pruebas. Cual es el tamaño adecuado para que no me vuelva a suceder? O que otra precaución debería tener?
        Nuevamente muchas gracias por tu ayuda!!

        Responder
        1. Alberto Gonzalez Iniesta Autor

          Hola! No hay un tamaño que venga bien a todo el mundo. Debes tener siempre un margen razonable (al uso de la máquina), procurando dejar lo máximo libre en el VG (para que puedas usarlo como quieras cuando lo necesites). El truco real es tener monitorizado el espacio libre, como casi todo lo que se pueda monitorizar de la máquina, para actuar antes de que sea tarde. Saludos.

          Responder
          1. pollo

            Lo tendré en cuenta. Seguiré investigando y tratando de aprender. Gracias por la ayuda. Abrazo.

  17. Orlando

    Finalmente pude agregar un disco par ampliar la partición de data de mi proxmox. eres el puto amo. Una duda, si deseo retirar ese disco duro de 2T que ya está agregado a un PV y este a su vez ampliando una LV, cómo lo hago sin perder la info? El LV que amplié era inicialmente de 500 GB, al expandrir con el de 2T me fué utilísimo pero supongamos q hay fallos físicos..qué pasaría en ese escenario? Saludos!

    Responder
    1. Alberto Gonzalez Iniesta Autor

      Tendrías que mover el espacio que este asignado a LVs de ese disco (PV) a otros discos (PVs) con espacio libre. Es una operación que se hace en caliente (comando «pvmove»), no hay que parar nada. Pero todo el espacio que tengas usado de ese disco, lo necesitarás en espacio libre en otros discos que estén en el VG.

      Creí que lo tenía explicado en el blog, pero parece que no. A ver si saco un rato y añado un capítulo al LVM para torpes. Saludos!

      Responder
  18. Pedro Arroyo

    Hola Alberto y gracias de antemano.Y en la parte final:
    Si quisiéramos ampliar un sistema de ficheros btrfs? Estoy usando openSUSE 15.1 y no me funciona el comando df , es muy extraño

    Responder
      1. Pedro Arroyo

        si ,me funciona df perdona. esq tngo opensuse y nose si las deberia poner btrfs. En todo caso porque es lo normal no usar LVM con el?

        Responder
        1. Pedro Arroyo

          En la ampliación del PV también estoy muy confuso, ya que al hacerle el resize que inicialmente tenia 400MG según tu, dices que aumentemos la partición(pero con fdisk o como??)
          • Se amplia la partición a 500MB y se ejecuta pvresize
          # pvresize /dev/vda3
          Si era de 400 megas como es posible que pase a 500?
          Physical volume «/dev/vda3» changed
          1 physical volume(s) resized / 0 physical volume(s) not resized

          o también he visto este comando, y funciona, mi duda esq tengo 4 discos(son virtuales en VBOX) y mirando las capacidades de almacenamiento no localizo de donde me ha aumentado el PV de 8G a 9G pero no se de donde coge ese 1G
          pvresize –setphysicalvolumesize 9G /dev/sda1

          Responder
          1. Alberto Gonzalez Iniesta Autor

            Me lio con tu setup. En cualquier caso, un PV (sea partición o disco virtual), sólo crecerá si antes ha crecido el dispositivo, porque aumentas la partición (con fdisk, por ejemplo) o el disco virtual (desde el servidor de virtualización).

        2. Alberto Gonzalez Iniesta Autor

          Es posible usar btrfs sobre LVM, claro. Sin problema. Pero muchas de las ventajas que te da el LVM (flexibilidad, snapshots, subvolúmenes, stripping, mirror,..) ya las tienes en BTRFS, así que lo normal (salvo que tengas una necesidad de tener LVM por algo MUY concreto) es que te ahorres una de las capas 🙂

          Responder
          1. Pedro Arroyo

            muchísimas gracias Alberto por la guía, me ha ayudado mucho y he resuelto las dudas que tenía

  19. Carlos De Jesús

    Excelente artículo! Me sirvió de guía para ampliar mi LVM que había creado pero se quedó sin espacio y no sabía como agregar un disco en caliente. Te agradezco bastante!

    Responder
    1. Carlos de Jesus

      Nuevamente regreso a tu blog para repasar los pasos! muchas gracias por la guía. Hablando del comando pvmove ¿podrías agregar algo a la guía?

      Saludos!!

      Responder

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *