De mi Manual de Proxmox VE 4.x: Anexo 2 – Redimensionar imágenes de discos duros de máquinas virtuales vía CLI o Shell de Proxmox VE

Saludos nuevamente.

¿Se acuerdan que en el tercer y último post en donde describí el proceso de redimensionamiento de los discos duros de las VMs y/o particiones raíz de los CTs hice referencia al Anexo 2? Pues es el texto que viene a continuación. La variante que expongo en dicho anexo no es más que el mismo proceso, pero desde la consola de Proxmox VE.

Sin más, aquí les va:

Anexo 2 – Redimensionar imágenes de discos duros de máquinas virtuales vía CLI o Shell de Proxmox VE

Durante el proceso de lectura de documentación para describir el proceso de redimensionado de discos duros de máquinas virtuales pude consultar, aparte de la Wiki de Proxmox VE, varias páginas en Internet de cosas que han hecho otros especialistas y entusiastas en este sentido.

Luego de escribir el epígrafe y las secciones correspondientes a esta parte de redimensionar discos duros virtuales y sus sistemas de archivos internos, me tropecé en Internet con un blog bastante interesante en la siguiente URL:

https://blog.tinned-software.net/resize-proxmox-vm-disc-via-command-line-without-livecd/

En él su autor explica otra variante del proceso. La misma me pareció muy interesante, y por eso voy a dedicar este anexo a explicar el proceso que describe, pero basado en las condiciones que tengo (aparte de mi segunda intención, que es crear humildemente una transcripción al español de su post en un documento).

A grosso modo consiste en que la parte del proceso de redimensión de las particiones dentro del disco duro virtual posterior al incremento del tamaño del mismo se realiza en el hipervisor Proxmox VE usando drivers y herramientas especiales que permiten leer el contenido de las imágenes de disco duro de las VM, por lo que el único trabajo que se realiza dentro de la VM es el ajuste del sistema de archivos tanto primario como en el grupo de volúmenes y/o volúmenes lógicos LVM.

Antes de comenzar, propongo utilizar dos máquinas virtuales con características personalizadas, una con particionado LVM, y otra con particionado simple. Las características principales de las mismas son las siguientes:

• VM 108

CPU: 1 socket

RAM: 512 MB

HDD: 20 GB (Bus VirtIO)

Particiones en el HDD:

• /boot (ext4): 250MB
• LVM : 20 GB aprox.

• LV-root (ext4): 19 GB aprox.
• LV-swap (swap): 1 GB

SO: Debian 8

Red: Modelo VirtIO paravirtualizado

Nombre: vm09.lab.codesa.co.cu

• VM 109

CPU: 1 socket

RAM: 512 MB

HDD: 20 GB (Bus VirtIO)

Particiones en el HDD:

• /boot (ext4): 250MB
• swap: 1 GB
• / (ext4): 19 GB aprox.

SO: Debian 8

Red: Modelo VirtIO paravirtualizado

Nombre: vm10.lab.codesa.co.cu

Y precisamente creo dos máquinas virtuales para describir los dos casos a los que hice referencia en el epígrafe relacionado más arriba.

Bueno, sin más preámbulo, vayamos directamente al asunto.

Máquina Virtual No. 108 – Estructura de Particiones con sistema de archivos LVM (Volúmenes Lógicos)

Incremento del tamaño de la imagen de disco de la máquina virtual de interés

Primero que todo hay que autenticarse en el Shell del hipervisor Proxmox VE para redimensionar la imagen de disco duro de la VM deseada. Entre los muchos comandos y herramientas con las que cuenta Proxmox VE existe una, qm, que permite mostrar el listado de las máquinas virtuales que han sido configuradas previamente. He aquí con su respectiva salida:

root@prx4-c0-1-drbd8:~# qm list

      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID

       100 vm01.lab.codesa.co.cu stopped    512               40.00 0

       103 vm04.lab.codesa.co.cu stopped    1024              70.00 0

       104 vm05.lab.codesa.co.cu stopped    1024              80.00 0

       105 vm06.lab.codesa.co.cu stopped    512               50.00 0

       106 vm07.lab.codesa.co.cu stopped    512               40.00 0

       107 vm08.lab.codesa.co.cu stopped    512               50.00 0

       108 vm09.lab.codesa.co.cu stopped    512               20.00 0

       109 vm10.lab.codesa.co.cu stopped    512               20.00 0

root@prx4-c0-1-drbd8:~#

En el listado anterior aparecen las dos máquinas virtuales que se utilizarán en este anexo, de las cuales ya se saben sus características.

NOTA: En este punto sugiero que se haga antes una copia de seguridad de la(s) máquina(s) virtual(es) que se utilizarán en los trabajos. Esto por si algo sale mal, tener la posibilidad de revertir fácilmente los cambios hechos. Proxmox VE tiene para hacer esta tarea, ya sea por la WebGUI o por el Shell. Por ejemplo, para el caso de la VM 108, el comando en el Shell puede ser:

# vzdump 108 –storage local –mode snapshot –remove 0 –compress gzip –node prx4-c0-1-drbd8

Como ya es sabido, Proxmox VE utiliza qemu para la virtualización con KVM (virtualización completa), la cual brinda buena información acerca de las máquinas virtuales. Por ejemplo, para ver la configuración de una VM específica (donde se muestra todos los detalles de la VM) se utiliza el comando siguiente:

root@prx4-c0-1-drbd8:~# qm config 108

bootdisk: virtio0

cores: 1

ide2: local:iso/debian-8.1.0-amd64-CD-1.iso,media=cdrom

memory: 512

name: vm09.lab.codesa.co.cu

net0: virtio=36:37:36:30:63:34,bridge=vmbr0

numa: 0

ostype: l26

smbios1: uuid=5d9fe32c-e4d3-4a4c-99e7-82f90345ad54

sockets: 1

virtio0: local:108/vm-108-disk-1.qcow2,cache=writeback,size=20G

root@prx4-c0-1-drbd8:~#

Este comando ya se ha visto anteriormente, pero hago la reiteración para remarcar que aquí se pueden ver los detalles que pueden ser útiles para lo que viene más adelante, que son el tipo de bus y tamaño del disco duro. De ellos la información más importante es la identificación del tipo de disco, en este caso virtio0, la cual representa también que es el primer -y, hasta hora, único- disco conectado a la VM por medio del bus VirtIO.

Para ver los detalles de la imagen del disco duro de la VM, se puede ejecutar el siguiente comando:

root@prx4-c0-1-drbd8:~# qemu-img info /var/lib/vz/images/108/vm-108-disk-1.qcow2

image: /var/lib/vz/images/108/vm-108-disk-1.qcow2

file format: qcow2

virtual size: 20G (21474836480 bytes)

disk size: 1.5G

cluster_size: 65536

Format specific information:

    compat: 1.1

    lazy refcounts: false

    refcount bits: 16

    corrupt: false

root@prx4-c0-1-drbd8:~#

De toda la información mostrada hasta ahora, con el ID y el tipo de bus del disco duro de la VM se tiene lo necesario para realizar las labores de redimensionado de su disco duro. No obstante, existen dos limitaciones en este sentido:

1. No es posible reducir el tamaño del disco duro, solamente se puede incrementar.
2. El uso de instantáneas (snapshots) de la VM

Si el disco tuviese una instantánea definida, la información de la imagen del disco duro cambia un poquito, dado que también muestra los datos de la(s) instantánea(s) asociadas, como se ve a continuación:

root@prx4-c0-1-drbd8:~# qemu-img info /var/lib/vz/images/108/vm-108-disk-1.qcow2

image: /var/lib/vz/images/108/vm-108-disk-1.qcow2

file format: qcow2

virtual size: 20G (21474836480 bytes)

disk size: 1.5G

cluster_size: 65536

Snapshot list:

ID        TAG                 VM SIZE                DATE       VM CLOCK

1         Test_Snapshot             0 2015-12-26 06:44:41   00:00:00.000

Format specific information:

    compat: 1.1

    lazy refcounts: false

    refcount bits: 16

    corrupt: false

root@prx4-c0-1-drbd8:~#

Si se intenta redimensionar una imagen de disco duro de VM teniendo esta una instantánea definida previamente, se obtendrá un mensaje de error como este en el Shell del hipervisor:

root@prx4-c0-1-drbd8:~# qm resize 108 virtio0 +20G

can’t resize volume: virtio0 if snapshot exists

root@prx4-c0-1-drbd8:~#

O por la WebGUI, si se hace por esta vía:

Por lo tanto, si se desea redimensionar la imagen del disco virtual, se deben deshabilitar o eliminar las instantáneas que tenga asociada.

Entonces, si todo está bien y no hay contratiempos, se procede a incrementar el tamaño del disco duro de la VM:

root@prx4-c0-1-drbd8:~# qm resize 108 virtio0 +20G

Image resized.

root@prx4-c0-1-drbd8:~#

Con esto la imagen de disco duro conectada a la VM mediante el identificador de bus virtio0 se ha incrementado a 40 GB. A medida que se vayan introduciendo datos dentro del disco duro de la VM, esta imagen crecerá en consecuencia. También es válido aclarar que el tamaño del archivo de imagen (en este caso el archivo vm-108-disk-1.qcow2) no se afecta con este cambio en primera instancia, sino que el mismo crecerá hasta el tamaño máximo de 40 GB en vez del valor anterior de 20 GB.

Ahora bien, posterior a este cambio, la información que muestre la imagen de disco reflejará este nuevo valor en el campo “virtual size”, mientras que el campo “disk size” no cambia dado que muestra la cantidad de espacio usado dentro de la misma:

root@prx4-c0-1-drbd8:~# qemu-img info /var/lib/vz/images/108/vm-108-disk-1.qcow2

image: /var/lib/vz/images/108/vm-108-disk-1.qcow2

file format: qcow2

virtual size: 40G (42949672960 bytes)

disk size: 1.5G

cluster_size: 65536

Format specific information:

    compat: 1.1

    lazy refcounts: false

    refcount bits: 16

    corrupt: false

root@prx4-c0-1-drbd8:~#

Conectar la imagen de disco duro virtual a modificar al hipervisor Proxmox VE

Para cambiar el tamaño de las particiones dentro de la imagen de disco duro virtual -el archivo qcow2 mencionado anteriormente- se necesita tener acceso exclusivo sobre ella. Esto quiere decir que mientras la VM esté encendida no será posible este paso. Por lo tanto, hay que apagarla obligatoriamente.

Si el disco redimensionado no es el disco de arranque y la VM no lo está utilizando en ese momento, este se puede desmontar de la VM para luego redimensionarlo de la manera que se describió anteriormente en el epígrafe relacionado con este proceso ubicado más arriba en este documento.

No obstante, si el disco redimensionado es el disco de arranque de la VM, normalmente lo que se hace es utilizar un LiveCD con un sistema operativo compatible que contenga todas las herramientas necesarias para estos menesteres, iniciar con él y realizar las tareas de redimensión de las particiones que contiene el disco de la VM, dado que el sistema operativo de la misma está dormido.

Por suerte Proxmox VE cuenta con un grupo de herramientas que permiten acceder a la imagen de disco duro de las VM sin tener que hacer tantas cosas y realizar sin problemas los pasos requeridos para trabajar con las particiones. Esto es posible gracias al conjunto de herramientas asociadas a qemu-nbd (donde nbd significa Dispositivo de Bloques en Red [Network Block Device]), las cuales permiten conectarse a la imagen de disco qcow2 generando un dispositivo más para el sistema operativo (representado internamente como un dispositivo de bloques virtual).

Si se tiene ya práctica con el tema de los dispositivos y los módulos del kernel de GNU/Linux, no es difícil manipular este tipo de dispositivos de bloques. Para este caso en particular, los módulos necesarios para el trabajo con dispositivos NBD ya están incluidos en la versión del kernel de GNU/Linux que viene con Proxmox VE, pero no se cargan por defecto durante el arranque del sistema operativo. No obstante, gracias a la flexibilidad que brinda el kernel de este gran sistema operativo, estos módulos pueden ser cargados sin problemas mientras el mismo está corriendo, o sea:

root@prx4-c0-1-drbd8:~# modprobe -av nbd

insmod /lib/modules/4.2.6-1-pve/kernel/drivers/block/nbd.ko

root@prx4-c0-1-drbd8:~#

El comando anterior lo que hizo fue cargar el módulo del kernel (o driver, como se quiera llamar) qemu-nbd, con el cual qemu podrá conectarse a las imágenes de disco duro virtual sin ningún tipo de problema.

NOTA IMPORTANTE: Recordar que para acceder a la imagen de disco duro de la VM, hay que asegurarse de que la misma esté apagada previamente.

Ah, y otra cosa, aparte de lo anterior, también es indispensable instalar el paquete nbd-client para permitir que las herramientas que trabajan  con dispositivos NDB se conecten a las imágenes de discos duros de qemu apropiadamente.

NOTA: En caso de que APT no encuentre el paquete en el repositorio principal de Debian Jessie (por la causa que sea), usará el que tiene disponible en el repositorio de actualizaciones (Debian Security).

Entonces, para conectarse la imagen que interesa, se debe ejecutar lo siguiente:

# qemu-nbd -c /dev/nbd0 /var/lib/vz/images/108/vm-108-disk-1.qcow2

El comando anterior no produce salida alguna, a no ser que haya algún problema con el módulo o la imagen de disco que se pretende montar. No obstante, el resultado del mismo será la creación de un nuevo dispositivo que está conectado a la imagen de disco recién redimensionada. Dicho dispositivo está disponible en el apuntador /dev/nbd0 y puede ser accedido como un dispositivo de bloques más.

Redimensionando las particiones dentro del disco duro virtual

Si se tiene curiosidad por saber si realmente el disco duro virtual está montado y se pueden leer las particiones, se puede usar cualquier herramienta de gestión de discos. Por ejemplo, con fdisk:

root@prx4-c0-1-drbd8:~# fdisk /dev/nbd0

Welcome to fdisk (util-linux 2.25.2).

Changes will remain in memory only, until you decide to write them.

Be careful before using the write command.

Command (m for help): p

Disk /dev/nbd0: 40 GiB, 42949672960 bytes, 83886080 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x1d49ba41

Device      Boot  Start      End  Sectors  Size Id Type

/dev/nbd0p1 *      2048   487423   485376  237M 83 Linux

/dev/nbd0p2      487424 41940991 41453568 19.8G 8e Linux LVM

Command (m for help):

Efectivamente, el nuevo dispositivo de bloques se ha montado exitosamente y se puede leer su tabla de particiones sin ningún problema. Es más, se puede modificar sin ningún problema.

Pero prefiero usar parted como herramienta de gestión de disco para redimensionar la partición donde está el directorio raíz del sistema operativo (en este caso la segunda partición, que es el mejor escenario para esto).

Entonces, ejecutando dicha herramienta se puede ver tanto las particiones, como el espacio libre que tiene el disco:

root@prx4-c0-1-drbd8:~# parted /dev/nbd0

GNU Parted 3.2

Using /dev/nbd0

Welcome to GNU Parted! Type ‘help’ to view a list of commands.

(parted) print free

Model: Unknown (unknown)

Disk /dev/nbd0: 42.9GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number  Start   End     Size    Type     File system  Flags

        32.3kB  1049kB  1016kB           Free Space

 1      1049kB  250MB   249MB   primary  ext4         boot

 2      250MB   21.5GB  21.2GB  primary               lvm

        21.5GB  42.9GB  21.5GB           Free Space

(parted)

Ahora se procederá a redimensionar la segunda partición para que ocupe el espacio libre que queda en el disco duro luego de su incremento de tamaño. Para ellos se ejecuta lo siguiente dentro de la herramienta:

(parted) resizepart 2 42.9G

(parted)

Luego mostrar nuevamente la tabla de particiones después de la operación realizada para luego salir de la herramienta:

(parted) print free

Model: Unknown (unknown)

Disk /dev/nbd0: 42.9GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number  Start   End     Size    Type     File system  Flags

        32.3kB  1049kB  1016kB           Free Space

 1      1049kB  250MB   249MB   primary  ext4         boot

 2      250MB   42.9GB  42.7GB  primary               lvm

        42.9GB  42.9GB  49.7MB           Free Space

(parted) quit

Information: You may need to update /etc/fstab.

Como se ve, la partición No. 2 ahora tiene un tamaño de 42.7 GB, de 21.2 que tenía anteriormente. Esto evidencia que todo ha salido bien.

Entonces, en este punto, ya el disco se ha incrementado de tamaño y la segunda partición ha ocupado el nuevo espacio libre. Dos de los pasos importantes san sido completados satisfactoriamente. A diferencia de otras variantes, todas las tareas se han realizado en el mismo hipervisor Proxmox VE, ahora lo que queda por hacer ya hay que hacerlo dentro de la VM.

Ah, pero primero hay que realizar las operaciones de desconexión del dispositivo de bloques asociado a la imagen de disco duro virtual que se modificó y luego descargar el módulo o driver NBD cargado previamente, todo esto en el hipervisor Proxmox VE:

root@prx4-c0-1-drbd8:~# qemu-nbd –disconnect /dev/nbd0

/dev/nbd0 disconnected

root@prx4-c0-1-drbd8:~# modprobe -rv nbd

rmmod nbd

root@prx4-c0-1-drbd8:~#

Bueno, el primer comando lo que hizo fue desconectar el dispositivo, mientras que el segundo descargó el módulo o driver del kernel de GNU/Linux.

Ajustar (incrementar) el tamaño de los sistemas de archivos dentro de las particiones del disco duro virtual

Ya aquí se describe el proceso de ajuste o redimensionado de los sistemas de archivos alojados dentro de las particiones del disco duro virtual. En una sección describiré el proceso de ajuste de volúmenes lógicos LVM y en otra el de un sistema de archivos primario ext3/ext4. Cada uno en su VM asociada.

Ajuste del tamaño de un volumen lógico LVM

Primero que todo, hay que encender la VM y autenticarse vía SSH preferentemente. En este punto el disco con tamaño incrementado debe de estar disponible para operar, pero hasta este momento solamente el tamaño del disco y la partición LVM son los elementos que han sido redimensionados, aún no el sistema de archivos (la estructura compuesta por el volumen físico, el grupo de volúmenes y los volúmenes lógicos) dentro de la partición LVM.

Como primer paso de esta tercera etapa, para el caso de volúmenes lógicos LVM, es incrementar el tamaño del volumen físico LVM, en otras palabras, el volumen físico LVM necesita ser notificado del incremento de tamaño del disco duro “físico” donde se encuentra alojado.

De hecho, si se muestra el estado del volumen físico antes del cambio, se puede ver que aún conserva el tamaño actual:

root@vm09:~# pvs

  PV         VG      Fmt  Attr PSize  PFree

  /dev/vda2  vm09-vg lvm2 a–  19.77g    0

root@vm09:~#

Entonces, mediante el comando pvresize, y estableciéndole como parámetro la partición del disco duro de tipo LVM, se ejecuta el cambio deseado:

root@vm09:~# pvresize /dev/vda2

  Physical volume «/dev/vda2» changed

  1 physical volume(s) resized / 0 physical volume(s) not resized

root@vm09:~#

Después que el volumen físico se ha modificado, se puede ver su nuevo tamaño o con pvs o con pvdisplay. En cualquiera caso muestra el cambio realizado:

root@vm09:~# pvs

  PV         VG      Fmt  Attr PSize  PFree

  /dev/vda2  vm09-vg lvm2 a–  39.72g 19.95g

root@vm09:~#

root@vm09:~# pvdisplay

  — Physical volume —

  PV Name               /dev/vda2

  VG Name               vm09-vg

  PV Size               39.72 GiB / not usable 1.63 MiB

  Allocatable           yes

  PE Size               4.00 MiB

  Total PE              10168

  Free PE               5108

  Allocated PE          5060

  PV UUID               cU3S8I-u39f-L32g-YQl9-BrHp-HnWl-u8QOYP

root@vm09:~#

Como se ve, ahora el tamaño del volumen físico ha cambiado a 39.72 GB, antes tenía 19.77GB.

También el tamaño del grupo de volúmenes ha cambiado al mismo valor, lo cual se puede ver mediante los comandos vgs y vgdisplay. En el caso de vgdisplay, este muestra la cantidad de espacio libre tanto en extents (PE) como en GiB:

root@vm09:~# vgs

  VG      #PV #LV #SN Attr   VSize  VFree

  vm09-vg   1   2   0 wz–n- 39.72g 19.95g

root@vm09:~#

root@vm09:~# vgdisplay

  — Volume group —

  VG Name               vm09-vg

  System ID

  Format                lvm2

  Metadata Areas        1

  Metadata Sequence No  4

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                2

  Open LV               2

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               39.72 GiB

  PE Size               4.00 MiB

  Total PE              10168

  Alloc PE / Size       5060 / 19.77 GiB

  Free  PE / Size       5108 / 19.95 GiB

  VG UUID               dSAZVv-3KLO-OKVq-CrL9-U780-Z36G-rExXBV

root@vm09:~#

Ahora bien, con el comando lvdisplay se muestran los volúmenes lógicos que están definidos dentro del grupo de volúmenes vg09-vg, por ejemplo:

root@vm09:~# lvdisplay

  — Logical volume —

  LV Path                /dev/vm09-vg/LV-root

  LV Name                LV-root

  VG Name                vm09-vg

  LV UUID                j5a3zF-0y1X-QhuY-g9HD-mggZ-WszF-LHFwZg

  LV Write Access        read/write

  LV Creation host, time vm09, 2015-12-25 17:26:38 -0500

  LV Status              available

  # open                 1

  LV Size                18.83 GiB

  Current LE             4821

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  – currently set to     256

  Block device           253:0

  — Logical volume —

  LV Path                /dev/vm09-vg/LV-swap

  LV Name                LV-swap

  VG Name                vm09-vg

  LV UUID                ikGfpH-E1Zn-fuBY-qsCC-nExl-iktQ-6ZfFEm

  LV Write Access        read/write

  LV Creation host, time vm09, 2015-12-25 17:26:56 -0500

  LV Status              available

  # open                 2

  LV Size                956.00 MiB

  Current LE             239

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  – currently set to     256

  Block device           253:1

root@vm09:~#

De toda la información que despliega, el campo que interesa es “LV Path”, dado que el valor del mismo sirve como parámetro necesario para redimensionar el volumen lógico que desea aumentar el tamaño, o sea, el próximo paso que viene a continuación. No quiero decir que los demás datos no sean importantes, sino que de toda la información que se ha recolectado hasta el momento son pocos datos los que se necesita para realizar las operaciones requeridas.

Y para la operación que se va a realizar ahora se pueden escoger dos variantes, o lo que es lo mismo, dos comandos que, al final, hacen lo mismo: lvextend y lvresize. Con el primero se puede utilizar la cantidad de espacio libre en valores de extents (esta variante es más exacta porque usa el valor “Free PE / Size” del comando vgdisplay), mientras que con el segundo se puede utilizar valores en GB.

Variante con lvextend:

root@vm09:~# lvextend –extents +100%FREE –resizefs /dev/vm09-vg/LV-root

  Size of logical volume vm09-vg/LV-root changed from 18.83 GiB (4821 extents) to 38.79 GiB (9929 extents).

  Logical volume LV-root successfully resized

resize2fs 1.42.12 (29-Aug-2014)

Filesystem at /dev/mapper/vm09–vg-LV–root is mounted on /; on-line resizing required

old_desc_blocks = 2, new_desc_blocks = 3

The filesystem on /dev/mapper/vm09–vg-LV–root is now 10167296 (4k) blocks long.

root@vm09:~#

NOTA: El parámetro –resizefs proporcionado a lvextend realiza, de paso, el ajuste del tamaño del sistema de archivos ext3/ext4 al nuevo tamaño del volumen lógico /dev/vm09-vg/LV-root. No obstante, se puede hacer a posteriori también.

Variante con lvresize:

root@vm09:~# lvresize –size +19.95GB –resizefs /dev/vm09-vg/LV-root

  Rounding size to boundary between physical extents: 19.95 GiB

  Size of logical volume vm09-vg/LV-root changed from 18.83 GiB (4821 extents) to 38.79 GiB (9929 extents).

  Logical volume LV-root successfully resized

resize2fs 1.42.12 (29-Aug-2014)

Filesystem at /dev/mapper/vm09–vg-LV–root is mounted on /; on-line resizing required

old_desc_blocks = 2, new_desc_blocks = 3

The filesystem on /dev/mapper/vm09–vg-LV–root is now 10167296 (4k) blocks long.

root@vm09:~#

Después de esto el espacio libre que tenía el grupo de volúmenes es asignado al volumen lógico LV-root. Para confirmar que esto es cierto, basta con ejecutar nuevamente el comando vgdisplay y luego lvdisplay:

root@vm09:~# vgdisplay

  — Volume group —

  VG Name               vm09-vg

  System ID

  Format                lvm2

  Metadata Areas        1

  Metadata Sequence No  5

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                2

  Open LV               2

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               39.72 GiB

  PE Size               4.00 MiB

  Total PE              10168

  Alloc PE / Size       10168 / 39.72 GiB

  Free  PE / Size       0 / 0

  VG UUID               dSAZVv-3KLO-OKVq-CrL9-U780-Z36G-rExXBV

root@vm09:~#

root@vm09:~# lvdisplay /dev/vm09-vg/LV-root

  — Logical volume —

  LV Path                /dev/vm09-vg/LV-root

  LV Name                LV-root

  VG Name                vm09-vg

  LV UUID                j5a3zF-0y1X-QhuY-g9HD-mggZ-WszF-LHFwZg

  LV Write Access        read/write

  LV Creation host, time vm09, 2015-12-25 17:26:38 -0500

  LV Status              available

  # open                 1

  LV Size                38.79 GiB

  Current LE             9929

  Segments               2

  Allocation             inherit

  Read ahead sectors     auto

  – currently set to     256

  Block device           253:0

root@vm09:~#

En la salida del primer comando se puede ver que ya no le queda espacio libre al grupo de volúmenes porque el volumen lógico LV-root ahora tiene 38.79 GB de espacio total, como se ve en la salida del segundo comando.

En cuanto al sistema de archivos ext3/ext4 alojado dentro del volumen lógico recién redimensionado, si no se especifica el parámetro –resizefs en ninguno de los dos comandos, el mismo aún conserva su tamaño actual. Esto se puede ver ejecutando el comando df:

root@vm09:~# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/dm-0        19G  903M   17G   6% /

udev             10M     0   10M   0% /dev

tmpfs            99M  4.4M   95M   5% /run

tmpfs           248M     0  248M   0% /dev/shm

tmpfs           5.0M     0  5.0M   0% /run/lock

tmpfs           248M     0  248M   0% /sys/fs/cgroup

/dev/vda1       226M   33M  178M  16% /boot

root@vm09:~#

Entonces, para ajustar el tamaño del sistema de archivos del volumen lógico se debe ejecutar el comando resize2fs especificándole el volumen lógico donde se encuentra alojado, o sea:

root@vm09:~# resize2fs /dev/vm09-vg/LV-root

resize2fs 1.42.12 (29-Aug-2014)

Filesystem at /dev/vm09-vg/LV-root is mounted on /; on-line resizing required

old_desc_blocks = 2, new_desc_blocks = 3

The filesystem on /dev/vm09-vg/LV-root is now 10167296 (4k) blocks long.

root@vm09:~#

Por último, para ver si el cambio se realizó sin problema alguno, hay que ejecutar nuevamente el comando df:

Filesystem      Size  Used Avail Use% Mounted on

/dev/dm-0        39G  907M   36G   3% /

udev             10M     0   10M   0% /dev

tmpfs            99M  4.4M   95M   5% /run

tmpfs           248M     0  248M   0% /dev/shm

tmpfs           5.0M     0  5.0M   0% /run/lock

tmpfs           248M     0  248M   0% /sys/fs/cgroup

/dev/vda1       226M   33M  178M  16% /boot

root@vm09:~#

Como se ve, se ha redimensionado también el sistema de archivos. Ahora su tamaño es de aproximadamente 36 GB.

Y con esto finaliza el proceso de redimensionamiento de un volumen lógico específico. No obstante, los pasos anteriores se aplican a cualquier otro volumen lógico que se desee hacerle la misma operación.

En el caso de una partición con un sistema de archivos primario, la cosa es más simple. Claro, y vuelvo a reiterarlo, si la partición a redimensionar se encuentra en la posición final del disco duro.

Máquina Virtual No. 109 – Estructura de Particiones con sistemas de archivos primarios

Incremento del tamaño de la imagen de disco de la máquina virtual de interés

Al igual que para la VM 108, hay que autenticarse en el Shell del hipervisor Proxmox VE para redimensionar la imagen de disco duro de la VM deseada.

Mostrar el listado de las máquinas virtuales que han sido configuradas previamente:

root@prx4-c0-1-drbd8:~# qm list

VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID

100 vm01.lab.codesa.co.cu stopped    512               40.00 0

103 vm04.lab.codesa.co.cu stopped    1024              70.00 0

104 vm05.lab.codesa.co.cu stopped    1024              80.00 0

105 vm06.lab.codesa.co.cu stopped    512               50.00 0

106 vm07.lab.codesa.co.cu stopped    512               40.00 0

107 vm08.lab.codesa.co.cu stopped    512               50.00 0

108 vm09.lab.codesa.co.cu stopped    512               40.00 0

109 vm10.lab.codesa.co.cu stopped    512               20.00 0

root@prx4-c0-1-drbd8:~#

Ya se sabe que la VM 109 existe y está lista para lo que viene, pero antes que todo hay que hacerle un respaldo por si acaso. El comando, similar al ejecutado para el caso de la VM 108:

# vzdump 109 –storage local –mode snapshot –remove 0 –compress gzip –node prx4-c0-1-drbd8

Completada la salva de la misma, se puede ver la configuración que tiene antes del cambio que se realizará:

root@prx4-c0-1-drbd8:~# qm config 109

bootdisk: virtio0

cores: 1

ide2: local:iso/debian-8.1.0-amd64-CD-1.iso,media=cdrom

memory: 512

name: vm10.lab.codesa.co.cu

net0: virtio=62:38:64:32:32:32,bridge=vmbr0

numa: 0

ostype: l26

smbios1: uuid=e66b44c9-1b2a-471b-b419-891a69af079e

sockets: 1

virtio0: local:109/vm-109-disk-1.qcow2,cache=writeback,size=20G

root@prx4-c0-1-drbd8:~#

En la configuración de la VM 109 se puede ver que también usa el bus VirtIO en la conexión a la imagen de disco duro.

Para ver los detalles de la misma, se ejecuta el siguiente comando:

root@prx4-c0-1-drbd8:~# qemu-img info /var/lib/vz/images/109/vm-109-disk-1.qcow2

image: /var/lib/vz/images/109/vm-109-disk-1.qcow2

file format: qcow2

virtual size: 20G (21474836480 bytes)

disk size: 1.5G

cluster_size: 65536

Format specific information:

compat: 1.1

lazy refcounts: false

refcount bits: 16

corrupt: false

root@prx4-c0-1-drbd8:~#

Si todo está bien y no hay problemas, toca el turno de incrementar el tamaño del disco duro de la VM:

root@prx4-c0-1-drbd8:~# qm resize 109 virtio0 +20G

Image resized.

root@prx4-c0-1-drbd8:~#

Igual que en la VM 108, posterior a este cambio, la información que muestre la imagen de disco reflejará este nuevo valor en el campo “virtual size”, mientras que el campo “disk size” no cambia dado que muestra la cantidad de espacio usado dentro de la misma:

root@prx4-c0-1-drbd8:~# qemu-img info /var/lib/vz/images/109/vm-109-disk-1.qcow2

image: /var/lib/vz/images/109/vm-109-disk-1.qcow2

file format: qcow2

virtual size: 40G (42949672960 bytes)

disk size: 1.5G

cluster_size: 65536

Format specific information:

compat: 1.1

lazy refcounts: false

refcount bits: 16

corrupt: false

root@prx4-c0-1-drbd8:~#

Conectar la imagen de disco duro virtual a modificar al hipervisor Proxmox VE

Para cambiar el tamaño de las particiones dentro de la imagen de disco duro virtual se necesita tener acceso exclusivo sobre ella. Recordar que hay que apagar la  VM obligatoriamente.

Entonces se debe cargar nuevamente el módulo o driver del kernel necesario para poder leer la imagen de disco duro virtual:

root@prx4-c0-1-drbd8:~# modprobe -av nbd

root@prx4-c0-1-drbd8:~#

Para conectarse la imagen que interesa, se debe ejecutar lo siguiente:

# qemu-nbd -c /dev/nbd0 /var/lib/vz/images/109/vm-109-disk-1.qcow2

Ya el disco duro virtual puede ser accedido como un dispositivo de bloques más, dado que está disponible en el apuntador /dev/nbd0.

Redimensionando las particiones dentro del disco duro virtual

Antes de hacer cualquier cambio en las particiones, primero se deben leer las tabla de particiones del disco duro, por ejemplo, con fdisk:

root@prx4-c0-1-drbd8:~# fdisk /dev/nbd0

Welcome to fdisk (util-linux 2.25.2).

Changes will remain in memory only, until you decide to write them.

Be careful before using the write command.

Command (m for help): p

Disk /dev/nbd0: 40 GiB, 42949672960 bytes, 83886080 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x681f0313

Device      Boot   Start      End  Sectors  Size Id Type

/dev/nbd0p1 *       2048   487423   485376  237M 83 Linux

/dev/nbd0p2       487424  2441215  1953792  954M 82 Linux swap / Solaris

/dev/nbd0p3      2441216 41940991 39499776 18.9G 83 Linux

Command (m for help):

Efectivamente, el nuevo dispositivo de bloques se ha montado exitosamente y se puede leer su tabla de particiones sin ningún problema, por lo que se puede modificar [mejor con parted]:

root@prx4-c0-1-drbd8:~# parted /dev/nbd0

GNU Parted 3.2

Using /dev/nbd0

Welcome to GNU Parted! Type ‘help’ to view a list of commands.

(parted) print free

Model: Unknown (unknown)

Disk /dev/nbd0: 42.9GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number  Start   End     Size    Type     File system     Flags

32.3kB  1049kB  1016kB           Free Space

1      1049kB  250MB   249MB   primary  ext4            boot

2      250MB   1250MB  1000MB  primary  linux-swap(v1)

3      1250MB  21.5GB  20.2GB  primary  ext4

21.5GB  42.9GB  21.5GB           Free Space

(parted)

Ahora toca el turno de redimensionar la tercera partición para que ocupe el espacio libre que queda en el disco duro luego de su incremento de tamaño. Para ellos se ejecuta lo siguiente dentro de la herramienta:

(parted) resizepart 3 42.9G

(parted)

Luego mostrar nuevamente la tabla de particiones después de la operación realizada para luego salir de la herramienta:

(parted) print free

Model: Unknown (unknown)

Disk /dev/nbd0: 42.9GB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Disk Flags:

Number  Start   End     Size    Type     File system     Flags

32.3kB  1049kB  1016kB           Free Space

1      1049kB  250MB   249MB   primary  ext4            boot

2      250MB   1250MB  1000MB  primary  linux-swap(v1)

 3      1250MB  42.9GB  41.7GB  primary  ext4

42.9GB  42.9GB  49.7MB           Free Space

(parted) quit

Information: You may need to update /etc/fstab.

Como se ve, la partición No. 3 ahora tiene un tamaño de 41.7 GB, de 20.2 que tenía anteriormente. Esto quiere decir que todo ha salido bien.

En este punto, ya el disco se ha incrementado de tamaño y la tercera partición ha ocupado el nuevo espacio libre. Ahora lo que queda por hacer será dentro de la VM, pero antes hay que desconectar la imagen de disco duro de la VM y descargar el módulo del kernel:

root@prx4-c0-1-drbd8:~# qemu-nbd –disconnect /dev/nbd0

/dev/nbd0 disconnected

root@prx4-c0-1-drbd8:~# modprobe -rv nbd

rmmod nbd

root@prx4-c0-1-drbd8:~#

Ajustar (incrementar) el tamaño de los sistemas de archivos dentro de las particiones del disco duro virtual

Ya aquí se describe el proceso de ajuste o redimensionado de los sistemas de archivos ext3/ext4 alojados dentro de las particiones del disco duro virtual.

Ajuste del tamaño de un sistema de archivos primario ext3/ext4

Bueno, aquí también hay que hacer lo mismo, encender la VM y autenticarse en ella por vía SSH. Y ya con el disco duro redimensionado (hecho en el paso anterior) se procede solamente a redimensionar la partición deseada.

Primeramente se debe ver el estado de la tabla de particiones y el tamaño que ocupa la partición raíz del sistema operativo (que es a la que hay que ajustarle el tamaño):

root@vm10:~# fdisk /dev/vda

Welcome to fdisk (util-linux 2.25.2).

Changes will remain in memory only, until you decide to write them.

Be careful before using the write command.

Command (m for help): p

Disk /dev/vda: 40 GiB, 42949672960 bytes, 83886080 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x681f0313

Device     Boot   Start      End  Sectors  Size Id Type

/dev/vda1  *       2048   487423   485376  237M 83 Linux

/dev/vda2        487424  2441215  1953792  954M 82 Linux swap / Solaris

/dev/vda3       2441216 83789062 81347847 38.8G 83 Linux

Command (m for help):

root@vm10:~# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/vda3        19G  894M   17G   5% /

udev             10M     0   10M   0% /dev

tmpfs            99M  4.4M   95M   5% /run

tmpfs           248M     0  248M   0% /dev/shm

tmpfs           5.0M     0  5.0M   0% /run/lock

tmpfs           248M     0  248M   0% /sys/fs/cgroup

/dev/vda1       226M   32M  179M  16% /boot

root@vm10:~#

De la información recolectada hasta el momento se desprende que el disco tiene 40 GB de tamaño total, la tercera partición (o sea, /dev/vda3) tiene 38.8 GB de tamaño, y el sistema de archivos alojado en ella aún conserva su tamaño de 17 GB.

Entonces, para ajustar el tamaño del sistema de archivos de la partición /dev/vda3  se debe ejecutar el comando resize2fs, o sea:

root@vm10:~# resize2fs /dev/vda3

resize2fs 1.42.12 (29-Aug-2014)

Filesystem at /dev/vda3 is mounted on /; on-line resizing required

old_desc_blocks = 2, new_desc_blocks = 3

The filesystem on /dev/vda3 is now 10168480 (4k) blocks long.

root@vm10:~#

Para ver si el cambio se realizó sin problema alguno, hay que ejecutar nuevamente el comando df:

root@vm10:~# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/vda3        39G  898M   36G   3% /

udev             10M     0   10M   0% /dev

tmpfs            99M  4.4M   95M   5% /run

tmpfs           248M     0  248M   0% /dev/shm

tmpfs           5.0M     0  5.0M   0% /run/lock

tmpfs           248M     0  248M   0% /sys/fs/cgroup

/dev/vda1       226M   32M  179M  16% /boot

root@vm10:~#

Como se ve, se ha redimensionado también el sistema de archivos. Ahora su tamaño es de aproximadamente 36 GB.

Y con esto finaliza el proceso de redimensionamiento de un sistema de archivos primario con ext3/ext4/xfs.

Y hasta aquí el Anexo 2. Espero les sirva. 🙂