De mi Manual de Proxmox VE 4.x: Redimensionado de los discos duros de las máquinas virtuales y particiones raíz de los contenedores (Parte III)

Saludos nuevamente.

Esta es la tercera (y última) parte de esta serie de posts referentes al redimensionado de los discos duros de las VMs.

En el post anterior vimos el proceso de redimensionar un disco duro de una VM con sistema operativo Windows de Microsoft. Ahora veremos cómo es el proceso para un sistema operativo GNU/Linux.

Aquí les va:

Redimensionado de máquinas virtuales con sistemas GNU/Linux

En la sección anterior se describió el proceso de redimensionado de particiones o volúmenes en máquinas virtuales con sistemas operativos Windows de Microsoft. Ahora toca el turno de analizar este mismo proceso, pero en sistemas operativos GNU/Linux. En los ejemplos que describiré a continuación usaré GNU/Linux Debian, tanto la versión 7.0 (Wheezy) como la versión 8.0 (Jessie).

El tema del redimensionado de particiones en GNU/Linux no es difícil, pero tampoco es una sencillez para los que se inician en estos menesteres. En la mayoría de los casos nos podemos encontrar con dos modelos de particionado:

  • Particiones clásicas con sistemas de archivos etx3/ext4
  • Particiones que usan LVM (Gestor de Volúmenes Lógicos)

 

Actualmente el segundo modelo es el más difundido, de hecho, las distribuciones basadas en Red Hat lo utilizan por defecto durante el proceso de instalación; muchas variantes de distribuciones basadas en Debian también la utilizan por defecto (por ejemplo, el mismo Proxmox VE), mientras que otras la presentan como una opción a escoger. Además, en un modelo que da muchísimas facilidades a la hora de trabajar con las particiones. Más información acerca de las particiones LVM puede encontrarse en Wikipedia.

En esta sección describiré los pasos el citado proceso para los dos modelos, pero voy a comenzar con el más interesante, con particiones LVM, y luego con el más simple.

Redimensionando particiones y volúmenes LVM

Antes de continuar, quiero recalcar que cuando se redimensionan volúmenes LVM hay que realizar una serie de pasos adicionales, como incrementar o reducir volúmenes físicos, grupos de volúmenes y volúmenes lógicos.

Bueno vayamos al asunto. Los pasos son los siguientes:

1.- Redimensionar el tamaño del disco duro de la máquina virtual

Consideraciones generales

Antes de realizar cualquier modificación en el tamaño de un disco duro virtual, para evitar confusiones o dudas, imagínense que lo que se está haciendo es añadiendo o retirando los platos de un disco duro (esos discos plateados que están conectados al eje giratorio, claro, si alguien  ha visto uno por dentro). Por lo tanto, dicha operación debe realizarse con extremo cuidado y en un ambiente de extrema concentración debido a que si se comete un error en los pasos, se corre el riesgo de tener pérdida de información.

Si se alarga el tamaño del disco duro (o sea, añadir un nuevo plato con sus correspondientes mecanismos adicionales, cabezales, etc.), la tabla de particiones y sistemas de archivos se mantienen intactos, por lo que es obligatorio actuar dentro de la VM para hacer los ajustes pertinentes.

Si se reduce (shrink) el tamaño del disco duro (o sea, retirar el último plato con todo lo añadido anteriormente), lo más probable es que automáticamente se destruyen tanto el sistema de archivos como los datos dejando a la tabla de particiones y sistemas de archivos restantes en un estado no consistente. Por lo tanto, antes de hacer esto, primeramente hay que hacer los ajustes necesarios dentro de la VM (reducir el tamaño de los sistemas de archivos y luego el de las particiones) para luego reducir el tamaño del disco duro. En este caso, SystemRescueCD es el adecuado para esta operación, claro está que hay que iniciar la máquina virtual con él.

Redimensionado a través de la WebGUI

Esta operación se puede realizar con la VM encendida o apagada.

Gestor de Proxmox VE —> Máquina Virtual Específica —> Pestaña Hardware —> Seleccionar Disco Duro a Redimensionar —> Botón “Resize disk”

 75 - Gestor de Proxmox VE - VM_KVM - Pestaña Hardware - Resize Disk

De ahí especificar la cantidad en GB en que se incrementará el tamaño del disco virtual:

81.1 - Gestor de Proxmox VE - VM_KVM - Pestaña Hardware - Hard Disk - Resize disk

Redimensionado a través del a Shell de Proxmox VE mediante el comando qm

Igual, también se puede realizar esta operación con la VM encendida o apagada.

qm resize <ID de la VM> <Identificador de Disco Duro Virtual> +<Cantidad a Incrementar>G

Por ejemplo, aumentar en 20GB más el disco duro de la VM con ID 105, el cual tiene un bus del tipo VirtIO:

qm resize 105 virtio0 +20G

Para discos virtuales con bus VirtIO:

Los sistemas GNU/Linux deben ver el nuevo tamaño automáticamente sin necesidad de reiniciar la VM si la versión de su núcleo es igual o mayor a la 3.6.

Para discos virtuales con bus SCSI-VirtIO:

Los sistemas GNU/Linux deben ver el nuevo tamaño automáticamente sin necesidad de reiniciar la VM si la versión de su núcleo es igual o mayor a la 3.7.

En ambos casos, Windows debe ver el nuevo espacio automáticamente sin necesidad de reiniciar la VM a menos que tenga incluidos la última versión de los drivers de VirtIO.

2.- Extender o incrementar el volumen lógico de interés dentro del disco duro de la máquina virtual

En este punto la diferencia la aporta el sistema operativo huésped instalado en la VM. En algunos esta operación es recomendable hacerlo con el sistema operativo dormido utilizando un LiveCD, y en otros se puede hacer en caliente.

Con el sistema operativo GNU/Linux huésped apagado (dormido o fuera de línea)

En este modo se recomienda usar o GParted o alguna herramienta similar desde un LiveCD.

NOTA: Aún las particiones LVM y los discos dinámicos de Windows no están soportados  ni en GParted ni en muchas herramientas de gestión de discos.

Con el sistema operativo GNU/Linux huésped encendido o en línea

Aquí se describirá el proceso de cómo alargar una partición LVM. No obstante, este procedimiento es aplicable a cualquier otro tipo de partición.

NOTA IMPORTANTE: Muchos expertos recomiendan que este procedimiento debe hacerse en particiones cuya posición se encuentre al final del disco. En caso de que la partición esté en otra posición, se recomienda fuertemente hacerlo en modo apagado mediante una herramienta externa.

Bueno, asumiendo que ya se aumentó en 20 GB (ya sea utilizando la WebGUI o ejecutando el comando qm resize correspondiente) el tamaño del disco duro virtual de la VM 105, se procede a realizar las operaciones correspondientes en el sistema operativo huésped.

  • Chequear que el kernel haya detectado el cambio en el tamaño del disco duro

NOTA: Recordar que si se usa VirtIO como bus del disco duro virtual, el nombre del dispositivo apuntador dentro del sistema operativo es vda.

Para chequear si se vió el cambio, se debe ejecutar el comando:

# dmesg | grep vda

El cual mostrará, entre otras cosas, algo parecido a esto:

root@vm06:~# dmesg | grep vda

[    2.257553]  vda: vda1 vda2 < vda5 >

[   13.104822] EXT4-fs (vda1): mounting ext2 file system using the ext4 subsystem

[   13.113951] EXT4-fs (vda1): mounted filesystem without journal. Opts: (null)

[  389.199935] vda: detected capacity change from 32212254720 to 53687091200

root@vm06:~#

Lo cual confirma que el kernel detectó el cambio de tamaño de 30 a 50 GB.

  • Mostrar la actual tabla de particiones actual (antes de realizar los cambios)

Para ello se debe ejecutar el siguiente comando:

# fdisk -l /dev/vda | grep ^/dev

El cual da la salida siguiente:

root@vm06:~# fdisk -l /dev/vda | grep ^/dev

/dev/vda1  *      2048   499711   497664  243M 83 Linux

/dev/vda2       501758 62912511 62410754 29.8G  5 Extended

/dev/vda5       501760 62912511 62410752 29.8G 8e Linux LVM

root@vm06:~#

Como se ve, todo sigue igual como si no hubiese sucedido nada.

  • Redimensionar la tercera partición (en este caso, la de tipo Linux LVM) de manera tal que ocupe el espacio restante del disco duro (los 20 GB restantes resultado del incremento del tamaño)

Para ello ya hay que utilizar una herramienta de gestión de discos duros. La herramienta escogida es parted, la cual brinda muchas opciones.

NOTA: En una instalación reciente de GNU/Linux Debian la herramienta parted no viene por defecto, por tanto, hay que instalarla.

Primeramente ejecutar parted proporcionándole como parámetro el disco duro de la VM:

root@vm06:~# parted /dev/vda

GNU Parted 3.2

Using /dev/vda

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

 

(parted)

 

Luego ver la tabla de particiones actual del disco:

 

(parted) print

Model: Virtio Block Device (virtblk)

Disk /dev/vda: 53.7GB

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

Partition Table: msdos

Disk Flags:

 

Number  Start   End     Size    Type      File system  Flags

 1      1049kB  256MB   255MB   primary   ext2         boot

 2      257MB   32.2GB  32.0GB  extended

 5      257MB   32.2GB  32.0GB  logical                lvm

 

(parted)

NOTA IMPORTANTE: Si no hubiese una partición extendida, el procedimiento es simple, solamente hay que redimensionar la última partición; pero en este caso la partición que se desea redimensionar es lógica, o sea, se encuentra dentro de la partición extendida. Ya aquí la historia es diferente, dado que primero hay que redimensionar primero la partición extendida y luego la lógica.

Redimensionar la partición extendida:

(parted) resizepart 2 100%

(parted)

 

Ver los cambios:

 

(parted) print

Model: Virtio Block Device (virtblk)

Disk /dev/vda: 53.7GB

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

Partition Table: msdos

Disk Flags:

 

Number  Start   End     Size    Type      File system  Flags

 1      1049kB  256MB   255MB   primary   ext2         boot

 2      257MB   53.7GB  53.4GB  extended

 5      257MB   32.2GB  32.0GB  logical                lvm

 

(parted)

Redimensionar la partición lógica (que es la que interesa):

(parted) resizepart 5 100%

(parted)

Ver los cambios otra vez:

(parted) print

Model: Virtio Block Device (virtblk)

Disk /dev/vda: 53.7GB

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

Partition Table: msdos

Disk Flags:

 

Number  Start   End     Size    Type      File system  Flags

 1      1049kB  256MB   255MB   primary   ext2         boot

 2      257MB   53.7GB  53.4GB  extended

 5      257MB   53.7GB  53.4GB  logical                lvm

 

(parted)

Por último, salir del parted:

(parted) quit

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

 

root@vm06:~#

  •  Chequear la nueva tabla de particiones del disco duro luego del redimensionado de sus particiones

 

En este punto, para confirmar si los cambios fueron efectivos, hay que ejecutar nuevamente el comando siguiente:

# fdisk -l /dev/vda | grep ^/dev

Cuya nueva salida da esto:

root@vm06:~# fdisk -l /dev/vda | grep ^/dev

/dev/vda1  *      2048    499711    497664  243M 83 Linux

/dev/vda2       501758 104857599 104355842 49.8G  5 Extended

/dev/vda5       501760 104857599 104355840 49.8G 8e Linux LVM

root@vm06:~#

Aquí se ve que el cambio se hizo correctamente. Anteriormente el tamaño de la partición extendida y de la lógica que tiene dentro eran de 29.8 GB, ahora es de 49.8 GB.

Hasta este punto ya se han completado los pasos para el redimensionado de la partición que contiene el volumen LVM que se va a modificar posteriormente. En el proceso que le sigue se procederá a:

  • Incrementar el tamaño del volumen físico LVM (esto automáticamente incrementa el tamaño del espacio libre del grupo de volúmenes alojado dentro del volumen físico redimensionado)
  • Incrementar el tamaño del volumen lógico (o los volúmenes lógicos) de interés

 

3.- Extender o incrementar el sistema de archivos dentro de la partición modificada

El sistema de archivos en la partición que se ha redimensionado recientemente es de tipo LVM, lo cual hace que se deban ejecutar una serie de pasos intermedios para poder redimensionar finalmente el sistema de archivos más simple.

  • Incrementar el tamaño del volumen físico LVM (LVM PV) para que ocupe el espacio libre de la partición

Para ello se ejecuta el comando siguiente:

# pvresize /dev/vda5

NOTA: Recordar que la partición con sistema de archivos de tipo LVM está en el dispositivo /dev/vda5

Que da una salida siguiente:

root@vm06:~# pvresize /dev/vda5

  Physical volume «/dev/vda5» changed

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

root@vm06:~#

Chequear que se ha redimensionado el sistema de archivos LVM (comandos pvs y vgs para que las salidas sean concisas y escuetas):

root@vm06:~# pvs

  PV         VG      Fmt  Attr PSize  PFree

  /dev/vda5  vm06-vg lvm2 a–  49.76g 20.00g

root@vm06:~# vgs

  VG      #PV #LV #SN Attr   VSize  VFree

  vm06-vg   1   2   0 wz–n- 49.76g 20.00g

root@vm06:~#

Efectivamente se ha incrementado su tamaño, ahora cuenta con 20 GB de espacio libre.

  • Incrementar el tamaño del volumen lógico (o los volúmenes lógicos) de interés y, de paso, también incrementar el tamaño del sistema de archivos que contiene

NOTA IMPORTANTE: Si el sistema de archivos que contiene el volumen lógico es de tipo ext3, ext4 o xfs, se puede redimensionar incluso si está montado (en uso) en el momento de la operación. En otras palabras, el redimensionado en caliente (on-line resizing) funciona solamente con estos tres sistemas de archivos.

Antes de pasar a redimensionar el volumen lógico de interés, se debe ver la lista de volúmenes lógicos que contiene el grupo de volúmenes. Para ello se ejecuta el comando siguiente:

# lvs

El cual da la salida siguiente:

root@vm06:~# lvs

  LV     VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

  root   vm06-vg -wi-ao—- 28.76g                                             

  swap_1 vm06-vg -wi-ao—-  1.00g                                             

root@vm06:~#

Aquí vemos que hay dos volúmenes lógicos: root y swap_1, cuyos apuntadores a sus dispositivos son /dev/vm06-vg/root y /dev/vm06-vg/swap_1. Al que hay que incrementarle el tamaño es al volumen lógico /dev/vm06-vg/root y, de paso, ajustar también el tamaño del sistema de archivos ext3/ext4 alojado dentro. Para ello se ejecuta el siguiente comando:

# lvextend –extents +100%FREE –resizefs /dev/vm06-vg/root

Donde su salida es esta:

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

  Size of logical volume vm06-vg/root changed from 28.76 GiB (7362 extents) to 48.76 GiB (12482 extents).

  Logical volume root successfully resized

resize2fs 1.42.12 (29-Aug-2014)

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

old_desc_blocks = 2, new_desc_blocks = 4

The filesystem on /dev/mapper/vm06–vg-root is now 12781568 (4k) blocks long.

 

root@vm06:~#

Como se ve, lvextend también se encargó de incrementarle el tamaño al sistema de archivos raíz de tipo ext3/ext4, o sea, lo redimensionó en caliente.

Pero por si quedara alguna duda, se puede ver que el tamaño del volumen lógico /dev/vm06-vg/root ha cambiado:

root@vm06:~# lvs

  LV     VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

  root   vm06-vg -wi-ao—- 48.76g                                             

  swap_1 vm06-vg -wi-ao—-  1.00g                                             

root@vm06:~#

Así como el tamaño de la partición raíz del sistema operativo:

root@vm06:~# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/dm-0        48G  880M   45G   2% /

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       236M   33M  191M  15% /boot

root@vm06:~#

Si se ejecutaron todos los pasos anteriores sin ningún problema, entonces se ha completado el proceso de redimensionamiento (en este caso, incremento de espacio) de particiones con sistemas de archivos LVM, los cuales también contienen otros sistemas de archivos primarios que también deben ser modificados.

Redimensionando particiones simples con sistemas de archivos ext3/ext4

Ahora toca el turno de describir el proceso de redimensionamiento de sistemas de archivos más simples o primarios como ext3, ext4 o xfs.

En estos casos no hay que realizar esa gran cantidad de pasos que se describieron en la sección anterior, dado que el proceso es muchísimo más corto. De hecho, es un solo paso. 🙂

Para ejemplificar el proceso se utilizará una VM con un sistema operativo GNU/Linux con un esquema de particionado simple, o sea, a base de particiones ext3/ext4, dicha VM candidata es la que tiene ID 107 (sus características se pueden ver al comienzo del epígrafe).

Entonces, asumiendo que ya se aumentó en 20 GB el tamaño del disco duro virtual de la VM 107, se procede a realizar las operaciones correspondientes en el sistema operativo huésped.

Aquí los pasos son similares a los de la sección anterior. De ellos el que es aplicable 100% en este caso es el paso 1. Ya a partir del segundo la cosa cambia.

2.- Extender o incrementar el sistema de archivos ext3/ext4 de interés en el disco duro de la máquina virtual

Igual existen dos maneras de redimensionar un sistema de archivos primario: con el sistema operativo dormido y en ejecución.

Con el sistema operativo GNU/Linux huésped apagado (dormido o fuera de línea)

En este modo se recomienda usar o GParted o alguna herramienta similar desde un LiveCD.

Con el sistema operativo GNU/Linux huésped encendido o en línea

Aquí se describirá el proceso de cómo alargar una partición ext3/ext4/xfs.

Entonces, al igual que en la sección anterior, asumiendo que ya se aumentó en 20 GB el tamaño del disco duro virtual de la VM 107, se procede a realizar también las operaciones correspondientes en el sistema operativo huésped.

  • Chequear que el kernel haya detectado el cambio en el tamaño del disco duro

NOTA: Recordar que si se usa VirtIO como bus del disco duro virtual, el nombre del dispositivo apuntador dentro del sistema operativo es vda.

Para chequear si se vió el cambio, se debe ejecutar el comando:

# dmesg | grep vda

El cual mostrará, entre otras cosas, algo parecido a esto:

root@vm08:~# dmesg | grep vda

[    2.006484]  vda: vda1 vda2 < vda5 >

[    2.277933] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: (null)

[    4.919941] Adding 1045500k swap on /dev/vda5.  Priority:-1 extents:1 across:1045500k FS

[    5.019898] EXT4-fs (vda1): re-mounted. Opts: errors=remount-ro

[ 3244.447118] vda: detected capacity change from 32212254720 to 53687091200

root@vm08:~#

Lo cual confirma que el kernel detectó el cambio de tamaño de 30 a 50 GB.

  • Mostrar la actual tabla de particiones actual (antes de realizar los cambios)

 

Para ello se debe ejecutar el siguiente comando:

# fdisk -l /dev/vda

El cual da la salida siguiente:

Disk /dev/vda: 50 GiB, 53687091200 bytes, 104857600 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: 0x393388f6

 

Device     Boot    Start      End  Sectors  Size Id Type

/dev/vda1  *        2048 60819455 60817408   29G 83 Linux

/dev/vda2       60821502 62912511  2091010 1021M  5 Extended

/dev/vda5       60821504 62912511  2091008 1021M 82 Linux swap / Solaris

 

root@vm08:~#

Como se ve, todo sigue igual como si no hubiese sucedido nada.

  • Redimensionar la primera partición de manera tal que ocupe el espacio restante del disco duro (los 20 GB restantes resultado del incremento del tamaño)

 

Antes de seguir, y no porque sea una redundancia, es bueno recordar que muchos expertos recomiendan que este procedimiento debe hacerse en particiones cuya posición se encuentre al final del disco. En caso de que la partición esté en otra posición, se recomienda fuertemente hacerlo en modo apagado con un LiveCD mediante una herramienta externa (por ejemplo GParted).

En cierto modo la cosa se complica un poco, dado que la secuencia de operaciones de la variante que adoptaré será la siguiente:

  • Deshabilitar el uso de la partición que actúa como memoria de intercambio
  • Eliminar dicha partición (que, por cierto, es lógica)
  • Eliminar la partición extendida
  • Incrementar el tamaño de la primera partición (la partición raíz /) hasta la cantidad total de espacio libre menos 1 GB (o sea, aproximadamente 49 GB)
  • Redimensionar el sistema de archivos ext3/ext4 dentro de dicha partición raíz para que ocupe todo el nuevo espacio restante
  • Crear nuevamente la partición lógica con el espacio restante del disco duro virtual
  • Rehabilitar nuevamente la memoria de intercambio

 

Claro, esta secuencia es posible porque detrás de la partición raíz se encuentra la partición que actúa, como dije antes, como memoria de intercambio. Si la situación fuera otra, pues, ya el proceso es con un LiveCD y GParted con el sistema operativo apagado.

Entonces comencemos con el proceso.

Primeramente se debe ver la tabla de particiones para saber el estado actual de las mismas usando la herramienta parted:

root@vm06:~# parted /dev/vda

GNU Parted 3.2

Using /dev/vda

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

 

(parted) print

Model: Virtio Block Device (virtblk)

Disk /dev/vda: 53.7GB

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

Partition Table: msdos

Disk Flags:

 

Number  Start   End     Size    Type      File system     Flags

1      1049kB  31.1GB  31.1GB  primary   ext4            boot

2      31.1GB  32.2GB  1071MB  extended

5      31.1GB  32.2GB  1071MB  logical   linux-swap(v1)

 

(parted)

Con esto se sabe que la partición swap es el dispositivo /dev/vda5. Luego salir de la herramienta.

  • Deshabilitar el uso de la partición que actúa como memoria de intercambio

 

Para ello ejecutar el comando:

# swapoff -a /dev/vda5

  • Eliminar la partición swap

 

Ejecutar nuevamente parted proporcionándole como parámetro el disco duro de la VM:

root@vm06:~# parted /dev/vda

GNU Parted 3.2

Using /dev/vda

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

 

(parted) rm 5

(parted)

  • Eliminar la partición extendida

 

Dentro de la herramienta, ejecutar lo siguiente:

(parted) rm 2

(parted)

Con esto ya se tiene libre todo el espacio libre del disco duro para operar.

  • Incrementar el tamaño de la primera partición (la partición raíz /) hasta la cantidad total de espacio libre menos 1 GB

 

Como se incrementó el tamaño del disco duro a 50 GB, parted referencia 53.7 GB como espacio total. Por tanto, se incrementará, por si acaso, 52.2 GB el tamaño de la partición raíz.

Entonces, dentro de la herramienta, ejecutar lo siguiente:

(parted) resizepart 1

Warning: Partition /dev/vda1 is being used. Are you sure you want to continue?

Yes/No? yes

End?  [31.1GB]? 52.2GB

(parted)

Chequear si todo está en orden:

(parted) print

Model: Virtio Block Device (virtblk)

Disk /dev/vda: 53.7GB

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

Partition Table: msdos

Disk Flags:

 

Number  Start   End     Size    Type     File system  Flags

 1      1049kB  52.2GB  52.2GB  primary  ext4         boot

 

(parted)

Sí, ya la partición tiene su nuevo tamaño. Todo está listo para el siguiente paso. Ahora hay que salir momentáneamente de la herramienta:

(parted) quit

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

 

root@vm08:~#

  • Redimensionar el sistema de archivos ext3/ext4 dentro de dicha partición raíz para que ocupe todo el nuevo espacio restante

 

Ahora lo que hay que hacer es ajustar el tamaño del sistema de archivos al nuevo tamaño de la partición:

root@vm08:~# resize2fs /dev/vda1

resize2fs 1.42.12 (29-Aug-2014)

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

old_desc_blocks = 2, new_desc_blocks = 4

The filesystem on /dev/vda1 is now 12743884 (4k) blocks long.

 

root@vm08:~#

Por si hay dudas, ver el uso de espacio de los sistemas de archivos:

root@vm08:~# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/vda1        48G  907M   45G   2% /

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

root@vm08:~#

Se ha redimensionado satisfactoriamente. Ahora hay que restaurar la partición swap otra vez porque, de no hacerse, la activación de la memoria de intercambio durante la carga del sistema operativo fallará.

  • Crear nuevamente la partición lógica con el espacio restante del disco duro virtual para habilitar nuevamente la memoria de intercambio

 

Para seguir con el esquema con que se ha trabajado la tabla de particiones, usaré nuevamente la herramienta parted. Ahora con la secuencia de creación de la nueva partición lógica swap, una vez creada, salir de la herramienta:

(parted) mkpart extended

Start? 52.2GB

End? 53.7GB

(parted)

 

(parted) print

Model: Virtio Block Device (virtblk)

Disk /dev/vda: 53.7GB

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

Partition Table: msdos

Disk Flags:

 

Number  Start   End     Size    Type      File system  Flags

1      1049kB  52.2GB  52.2GB  primary   ext4         boot

 2      52.2GB  53.7GB  1487MB  extended               lba

 

(parted) mkpart logical linux-swap(v1) 52.2GB 53.7GB

 

(parted) print

Model: Virtio Block Device (virtblk)

Disk /dev/vda: 53.7GB

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

Partition Table: msdos

Disk Flags:

 

Number  Start   End     Size    Type      File system     Flags

1      1049kB  52.2GB  52.2GB  primary   ext4            boot

2      52.2GB  53.7GB  1487MB  extended                  lba

 5      52.2GB  53.7GB  1486MB  logical   linux-swap(v1)  lba

 

(parted) quit

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

 

root@vm08:~#

Ya están creadas las condiciones para habilitar otra vez la memoria de intercambio.

  • Rehabilitar nuevamente la memoria de intercambio

 

Para habilitar nuevamente la memoria de intercambio, primeramente hay que crear la swap (algo similar  a formatear la partición al sistema de archivos swap):

root@vm08:~# mkswap /dev/vda5

Setting up swapspace version 1, size = 1451004 KiB

no label, UUID=74d5f7a1-c80a-4764-acea-56fb44885d6f

root@vm08:~#

Con esto el sistema operativo le asigna el UUID necesario para editar la entrada correspondiente a la partición swap en el archivo /etc/fstab. De hecho, si se ejecuta la utilidad blkid, se obtiene una lista de los UUID tanto de los dispositivos de bloques como de los ópticos:

root@vm08:~# blkid

/dev/vda1: UUID=»2dcc159a-db5e-47a1-b350-017bb3742f69″ TYPE=»ext4″ PARTUUID=»393388f6-01″

/dev/sr0: UUID=»2015-06-06-14-58-49-00″ LABEL=»Debian 8.1.0 amd64 1″ TYPE=»iso9660″ PTUUID=»51a8728a» PTTYPE=»dos»

/dev/vda5: UUID=»74d5f7a1-c80a-4764-acea-56fb44885d6f» TYPE=»swap» PARTUUID=»393388f6-05″

root@vm08:~#

De ahí la que interesa es la línea correspondiente al dispositivo /dev/vda5.

Editar el archivo /etc/fstab para sustituir el UUID anterior asignado a la partición de intercambio por el nuevo UUID generado por mkswap. Hecho el cambio, el contenido de dicho archivo quedaría así:

# /etc/fstab: static file system information.

#

# Use ‘blkid’ to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

# / was on /dev/vda1 during installation

UUID=2dcc159a-db5e-47a1-b350-017bb3742f69 /               ext4    errors=remount

-ro 0       1

# swap was on /dev/vda5 during installation

UUID=74d5f7a1-c80a-4764-acea-56fb44885d6f none            swap    sw

  0       0

/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

Por último, sólo queda activar la memoria de intercambio con el siguiente comando:

# swapon -U 74d5f7a1-c80a-4764-acea-56fb44885d6f

Y así, finalmente, queda restablecida la partición swap del sistema operativo.

Bueno, dije que era sencillo, creo que me equivoqué un poquito. Al final, prefiero usar el esquema de particionado LVM por encima del particionado básico. Con LVM se tienen muchas más ventajas. 🙂

NOTA (PARA CURIOSOS): En el Anexo 2 se muestra otra variante de redimensionado de discos duros de VM, pero desde la perspectiva de la Shell del hipervisor Proxmox VE que, a mi modo de ver, es hasta cierto punto más cómodo; claro, esto requiere de la instalación de paquetes adicionales en el hipervisor.

Y hasta aquí esta serie de tres post en los que describo el proceso de redimensionado de discos duros de VMs y/o particiones raíz de CTs.

Espero les sirva.

😀

Acerca de Hector Suarez Planas

Es Licenciado en Ciencia de la Computación (3 de julio de 2002). Ha sido Administrador de Red en varias organizaciones, Programador y Analista de Sistemas. Actualmente se desempeña como Administrador de Red del Telecentro Tele Turquino de Santiago de Cuba. Tiene experiencia con sistemas Windows y GNU/Linux, Infraestructura de Redes (Cisco, AlliedTelesis, Netgear y HP ProCurve, Vyatta/VyOS), Servidores tanto físicos como virtuales (plataformas VMWare, Proxmox VE y Xen), Sistemas de Seguridad Informática (Snort/Suricata IDS, appliances AlienVault OSSIM), programador (Delphi, C++ Builder, Perl [poco], Python [algo]), entre otras cosas. Actualmente estoy incursionando en todo lo que tiene relación con Cloud Computing (OpenStack) y Centros de Datos. :-)
Esta entrada fue publicada en Proxmox VE. Guarda el enlace permanente.

6 respuestas a De mi Manual de Proxmox VE 4.x: Redimensionado de los discos duros de las máquinas virtuales y particiones raíz de los contenedores (Parte III)

  1. oscar dijo:

    hola muy buen post quisiera saber si tienes uno para reducir el tamaño de discos en maquinas virtuales y en contenedores … salu2…

    • Hector Suarez Planas dijo:

      Saludos, Oscar.

      Primero que todo, gracias por su comentario.

      Hasta ahora no he visto el tema de la reducción. Normalmente todos los manuales hablan de ampliación, pero si lo que quiere es lo contrario, ya tendrá que «bajar al LVM». De antemano le advierto que es peligroso hacer esas operaciones, así que le sugiero que lo haga con el FS apagado. O sea, reduzca el FS, chequéelo después de, luego reduzca el volumen lógico hasta llegar al tamaño deseado y actualice los datoa del EV para que no haya fallos.

      Es lo que yo haría en su caso, pero le reitero, es peligroso lo que quiere hacer.

      Espero le sirva. 🙂

  2. Manuel dijo:

    Hola Hector
    Muchas gracias por tu publicacion. Esta muy bien explicado, paso a paso. Aun no he tenido necesidad de usarlo. Recien estoy haciendo mis primeros pasos en Proxmox, y me parece una herramienta con mucho potencial
    Mas bien queria hacerte una consulta.. ¿Existe la posibilidad de que, al instalar el Proxmox.. poder personalizar el particionamiento.
    Caso ejemplo: Tener un equipo de pruebas de 8GB RAM y dos discos de 500GB
    Quisiera poder hacer lo siguiente
    Disco 0:
    swap 8GB
    /var/lib/vz 400GB
    / 92GB
    Disco 1
    Usarlo todo para el lvmthin

    ¿Como podria hacer esto al momento de instalar el proxmox?

    • Hector Suarez Planas dijo:

      Saludos, Manuel.

      Gracias por su respuesta. Me alegra saber que mis post le son útiles a otros colegas.

      Respecto a lo que me pregunta, eso se pued ehacer en dos pasos:

      1.- Durante la instalación, en la parte de la configuración del disco, existen varios parámetros a proporcionar:

      swapsize – Para establecer el tamaño del LV asignado a la swap.
      maxroot – Para establecer el tamaño del LV asignado a / (perfectamente lo puede dejar en blanco, dado que Proxmox VE le autoasigna 96 GB).
      maxvz – Para establecer el tamaño del LV asignado a los vHDDs de las máquinas virtuales.

      NOTA: Desde la vrsión 4.2 ya no se usan los discos virtuales en archivos qcow2, sino que se utiliza el LVM-Thin, así que el resto del disco, o sea, los casi 400 GB que quieres, van a parar a dicho LVM-Thin.

      2.- Añadir el segundo disco al PV y VG hechos por el Proxmox VE (tengo acá un post que habla sobre ese tema), para luego asignarselo al LVM-Thin.

      NOTA: La mía sugerencia es que, al menos, destine 250 GB a los respaldos de los EVs, dado que los 96 tristes GB de / se pueden consumir muyyyyyyyyyy rápido.

      Espero le sirva.

      🙂

  3. Cristian dijo:

    Hola Muy bueno tu tutorial, tuve un problema al tratar de redimensionar particion ext3/ext4, estaba todo bien pero al tratar de realizar el comando de parted , resize 1, me dice que no lo puede ejecutar que la particion esta en uso. Lo tendria que realizar con GPARTED ? obvio con un livecd. O cual puede ser el inconveniente ??

    • Hector Suarez Planas dijo:

      Saludos, Cristian.

      Primero que todo, gracias por su comentario.

      Primeramente deben estar apagados los EVs antes de redimensionar sus vHDDs a través de la WebGUI del nodo. Luego hacer los ajustes dentro del EV ya encendido.

      🙂

Responder a Cristian Cancelar respuesta

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