Freitag früh ist mir beim morgentlichen Stubenrundgang aufgefallen, dass ein Filesystem kurz vor dem Anschlag steht. Der in Icinga definierte Schwellwert war ist noch nicht erreicht, aber es war eigentlich nur eine Frage von Tagen bis das Monitoring Alarm schlägt und daher hatte ich schon mal pro-aktiv in Proxmox die Festplatte der VM um 20GB vergrößert. Um die 20GB dann auch tatsächlich nutzbar zu machen waren noch ein paar Schritte zusätzlich notwendig, da die Platte per LUKS verschlüsselt ist und LVM nutzt.

Zunächst die Disk und die ID des LUKS-Devices per lsblk ermitteln.

$ lsblk
NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0  320G  0 disk
├─sda1                                          8:1    0    1G  0 part  /boot
└─sda2                                          8:2    0  319G  0 part
  └─luks-e4f9f1bc-5271-4afe-b145-394c4a5fa157 252:0    0  319G  0 crypt
    ├─ol-root                                 252:1    0 36.9G  0 lvm   /
    ├─ol-swap                                 252:2    0  2.1G  0 lvm   [SWAP]
    └─ol-barman                               252:3    0  280G  0 lvm   /var/lib/barman

Dann die Partion vergrößern. Dazu nutze ich im konkreten Beispiel cfdisk /dev/sda, wähle die Partition sda2 aus und vergrößere per resize. Speichern (write) nicht vergessen. Im Anschluss per cryptsetup die Größe anpassen, hier also cryptsetup resize <id>. Den Erfolg der Aktion kann man dann mit cryptsetup status <id> überprüfen. Abschließend dann die üblichen Schritte bei LVM, also pveresize, lvxetend und xfs_growfs (oder halt resize2fs bei EXT4).

Vollständig:

$ cfdisk /dev/sda
$ cryptsetup resize luks-e4f9f1bc-5271-4afe-b145-394c4a5fa157
$ pveresize /dev/mapper/luks-e4f9f1bc-5271-4afe-b145-394c4a5fa157
$ lvextend -l +100%FREE /dev/mapper/ol-barman
$ xfs_growfs /dev/mapper/ol-barman