Ampliación de disco en sistema virtualizado KVM (proxmox)

Introduccion
En un escenario de uso de discos virtuales, como KVM, Proxmox y otros, a veces es necesario una ampliacion del disco. Si usamos LVM esto es posible y sencillo.
Convenciones
Ciertas cosas que hay en esta entrada, asi como en otras, requieren un conocimiento previo. No es un sitio para copiar y pegar sino para entender y hacer
No siempre es el disco vda, no siempre es la particion 1, y asi sucesivamente.
Ampliacion de una disco virtual KVM
La ampliacion de un disco LVM es posible una vez que hemos realizado el cambio virtual del tamano de la unidad LVM.
En el caso de Proxmox acudimos a la administracion de nuestro proxmox:
Seleccionamos el VPS
Click en **Resize Disk"
Incrementamos el tamano.
Si el aumento de tamano implica un tamano final mayor de 2 TiB deberas tener el esquema de particiones GPT de lo contrario, tendras que modificar bajo tu responsabilidad el esquema MBR a GPT. Esta entrada no trata de eso, y para ello es aconsejable el uso de Gparted Live, lo cual no siempre es posible.
El articulo interpreta que conoces el uso de ciertos comando, que sustituiran el dispositivo (disco) por el tuyo, y que sabes como obtener el esquema de tu disco (particiones)
Consejo sobre particionamiento durante la instalacion
Es aconsejable el uso de GPT y de ello hablamos en nuestra wiki, Instalacion GPT con el instalador Centos 7 en discos menores de 2 TiB
Verificacion en un KVM basado en LVM
Una vez que hemos ampliado el disco, podemos verificar el cambio de tamano en nuestro VPS. Esto funcionara hasta que reiniciemos la maquina. Despues ya no nos informara.
vda, vdb, sda, ... son nombres de dispositivos. Debes consultar cuales son tus dispositivos de disco usando 
fdisk -l y usar el apropiado en el comando
dmesg | grep vda
...
[  222.436098] vda: detected capacity change from 32212254720 to 37580963840
Imprimir la tabla actual del disco
fdisk -l /dev/vda | grep ^/dev
/dev/vda1   *        2048     1026047      512000   83  Linux
/dev/vda2         1026048    62914559    30944256   8e  Linux LVM
Conocer el uso de las particiones en el sistema LVM
pvscan
  PV /dev/vda2   VG centos          lvm2 [<29,51 GiB / 40,00 MiB free]
  Total: 1 [<29,51 GiB] / in use: 1 [<29,51 GiB] / in no VG: 0 [0   ]
lvscan
  ACTIVE            '/dev/centos/swap' [3,00 GiB] inherit
  ACTIVE            '/dev/centos/root' [<26,47 GiB] inherit
Metodo rapido y recomendado: 
growpart (GPT, no interactivo)
Desde hace años existe 
growpart (paquete 
cloud-guest-utils en Debian/Ubuntu, 
cloud-utils-growpart en RHEL/Alma/Rocky), que automatiza en un solo comando lo que en los casos anteriores se hace a mano con 
parted: extiende la partición para ocupar todo el espacio nuevo y reubica la tabla GPT de respaldo al final del disco (el "Fix" que 
parted pide de forma interactiva). Es no interactivo, idempotente y seguro sobre particiones en uso, por lo que es la vía preferida en discos GPT.
Para la pila típica 
disco virtual → partición → PV → VG → LV → XFS, una vez ampliado el disco en Proxmox (Resize Disk), el procedimiento completo en caliente (sin desmontar) es:
# 1. Crecer la partición (ej: partición 1 del disco vdd). growpart reubica el backup GPT solo
growpart /dev/vdd 1
# 2. Extender el Physical Volume de LVM al nuevo tamaño de la partición
pvresize /dev/vdd1
# 3. Extender el Logical Volume con todo el espacio libre del VG
lvextend -l +100%FREE /dev/stor2/stor2_vol
# 4. Crecer el filesystem (XFS crece montado; para EXT4 usar resize2fs)
xfs_growfs /srv/storage2
Ejemplo real de salida (ampliación de 
/srv/storage2 de 4 TiB a 8 TiB sobre 
/dev/vdd):
growpart /dev/vdd 1
CHANGED: partition=1 start=2048 old: size=8589932511 end=8589934558 new: size=17179867103 end=17179869150
pvresize /dev/vdd1
  Physical volume "/dev/vdd1" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
lvextend -l +100%FREE /dev/stor2/stor2_vol
  Size of logical volume stor2/stor2_vol changed from <4.00 TiB to <8.00 TiB.
  Logical volume stor2/stor2_vol successfully resized.
xfs_growfs /srv/storage2
data blocks changed from 1073740800 to 2147482624
Por qué funciona en caliente: 
growpart usa el ioctl 
BLKPG_RESIZE_PARTITION, que actualiza una sola partición sin re-leer toda la tabla, así que no falla aunque la partición esté en uso como PV activo de LVM. Y al reubicar él mismo el backup GPT, evita el error típico de responder mal al diálogo interactivo de 
parted. Si el sistema no trae 
growpart: 
apt install cloud-guest-utils (Debian/Ubuntu) o 
dnf install cloud-utils-growpart (RHEL/Alma/Rocky).
Caso 1: Particion primaria con LVM (GPT o MBR simple)
Este es el caso mas comun en instalaciones modernas con GPT.
Ampliar la particion fisica
parted /dev/vda
GNU Parted 3.1
Usando /dev/vda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 37,6GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Numero  Inicio  Fin     Tamano  Typo     Sistema de ficheros  Banderas
 1      1049kB  525MB   524MB   primary  xfs                  arranque
 2      525MB   32,2GB  31,7GB  primary                       lvm
(parted) resizepart 2 100%
(parted) quit
Asignar el nuevo tamano al volumen fisico de LVM
pvresize /dev/vda2
  Physical volume "/dev/vda2" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
Caso 2: Particion extended con logical (MBR clasico)
IMPORTANTE: Algunas instalaciones antiguas (especialmente Debian/Ubuntu) usan esquema MBR con particiones extended y logical. En este caso hay que ampliar DOS particiones en orden.
Ejemplo de estructura:
Number  Start   End    Size   Type      File system  Flags
 1      1049kB  512MB  511MB  primary   ext2         boot
 2      513MB   698GB  697GB  extended
 5      513MB   698GB  697GB  logical                lvm
Aqui vda2 es un contenedor (extended) y vda5 es la particion real con LVM (logical).
Paso 1: Ampliar la particion extended
parted /dev/vda
(parted) resizepart 2 100%
(parted) quit
Paso 2: Ampliar la particion logical
parted /dev/vda
(parted) resizepart 5 100%
(parted) quit
Verificar que ambas particiones ahora ocupan todo el espacio:
parted /dev/vda print
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 752GB
Number  Start   End    Size   Type      File system  Flags
 1      1049kB  512MB  511MB  primary   ext2         boot
 2      513MB   752GB  751GB  extended
 5      513MB   752GB  751GB  logical                lvm
Paso 3: Redimensionar el Physical Volume
CRITICO: El PV esta en la particion logical (vda5), NO en la extended (vda2):
pvresize /dev/vda5
  Physical volume "/dev/vda5" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
Error comun: ejecutar 
pvresize /dev/vda2 da error "device is too small" porque vda2 es la extended, no contiene el PV.
Paso 4: Verificar el nuevo espacio disponible
vgs
  VG        #PV #LV #SN Attr   VSize    VFree
  kvm330-vg   1   2   0 wz--n- <699.52g  50g
El VFree muestra el espacio nuevo disponible.
Redimensionar el volumen logico de LVM
Todo para una particion
lvresize --extents +100%FREE --resizefs /dev/centos/root
  Size of logical volume centos/root changed from <26,47 GiB (6776 extents) to <31,51 GiB (8066 extents).
  Logical volume centos/root successfully resized.
Resize Volumen Logico por tamano exacto a anadir
En un sistema con distintas particiones es diferente:
df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv   10G  2.7G  7.4G  27% /
/dev/mapper/ubuntu--vg-lv--usr      6.0G  5.6G  450M  93% /usr
/dev/mapper/ubuntu--vg-lv--home     5.0G   88M  5.0G   2% /home
/dev/mapper/ubuntu--vg-lv--var      6.0G  1.3G  4.8G  21% /var
Ampliar solo la particion /usr en 2GB:
lvextend -L+2G /dev/ubuntu-vg/lv-usr
  Size of logical volume ubuntu-vg/lv-usr changed from 6.00 GiB to 8.00 GiB.
  Logical volume ubuntu-vg/lv-usr successfully resized.
Expandir el sistema de archivos (para XFS):
xfs_growfs /dev/ubuntu-vg/lv-usr
data blocks changed from 1572864 to 2097152
Para EXT4 usar resize2fs o la opcion --resizefs en lvresize.
Mensajes de error comunes
Error en parted: tabla GPT al final del disco
A veces, es posible que tras un acceso con 
parted a nuestro dispositivo, podemos encontrar mensajes relativos a problemas derivados de los instaladores de Centos, de Ubuntu, segun cuando y como se hizo la particion.
Error: La copia de la tabla GPT no esta al final del disco, como deberia ser.
Arreglar/Fix/Descartar/Ignore/Cancelar/Cancel? Fix
Aviso: Not all of the space available to /dev/vda appears to be used
Arreglar/Fix/Descartar/Ignore? F
Responder Fix a estos mensajes para corregir la tabla GPT.
Con 
growpart (ver el método con 
growpart más arriba) este diálogo no aparece: el fix del backup GPT lo realiza automáticamente.
Error pvresize: device is too small
pvresize /dev/vda2
  Cannot use /dev/vda2: device is too small (pv_min_size)
  0 physical volume(s) resized or updated / 0 physical volume(s) not resized
Este error ocurre cuando se intenta hacer pvresize sobre la particion extended en lugar de la logical. Verificar con 
pvscan cual es la particion correcta que contiene el Physical Volume.
Actualizacion 2024-03-21
En nuevas versiones de parted, por ejemplo en AlmaLinux 8, no es posible usar el comando interactivo como anteriormente. Debes hacerlo directamente en el shell:
parted /dev/sdx --script resizepart NumeroParticion 100%
Aviso
Esta documentacion y su contenido, no implica que funcione en tu caso o determinados casos. Tambien implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad.
El contenido se entrega, tal y como esta, sin que ello implique ninguna obligacion ni responsabilidad por parte de Castris
Si necesitas soporte profesional puedes contratar con Castris soporte profesional.