Étendre /var sur LVM dans une VM Proxmox (Debian 12 / OSBoxes) — procédure + troubleshooting

extend-var-lvm.md

Étendre /var sur LVM dans une VM Proxmox (Debian 12 / OSBoxes) — procédure + troubleshooting

Contexte

VM Debian 12 issue d'une image pré-faite OSBoxes. Ces images appliquent un partitionnement LVM "guidé Debian" assez strict : un LV séparé par point de montage (/, /var, /tmp, /home, swap), avec /var taillé très petit (~9 G) et /home qui récupère l'essentiel. Sur une utilisation k3s/Docker — qui empile images, layers, logs et volumes dans /var/lib/... — /var se remplit vite, alors que /home reste désespérément vide.

Symptômes observés :

• /var à 51% sur un LV de 9.3 G seulement,
• VG 100% alloué (VFree = 0) — donc lvextend impossible directement,
• mais lsblk montre que le disque virtuel a été agrandi côté hyperviseur (300 G) sans que la table de partitions de l'invité ne suive : sda5 plafonné à 249.5 G → 50 GiB libres après sda5.

Objectif : ajouter +50 G à /var sans démontage, sans reboot, sans toucher à /home.

État initial

$ lsblk
sda                       8:0    0   300G  0 disk
├─sda1                    8:1    0   487M  0 part /boot
├─sda2                    8:2    0     1K  0 part           ← partition étendue (MBR)
└─sda5                    8:5    0 249.5G  0 part           ← logique, contient le PV LVM
  ├─debian12--vg-root   254:0    0  23.3G  0 lvm  /
  ├─debian12--vg-var    254:1    0   9.3G  0 lvm  /var      ← à étendre
  ├─debian12--vg-swap_1 254:2    0   976M  0 lvm  [SWAP]
  ├─debian12--vg-tmp    254:3    0   1.9G  0 lvm  /tmp
  └─debian12--vg-home   254:4    0 214.1G  0 lvm  /home

$ sudo parted /dev/sda unit GiB print free
Number  Start    End      Size     Type      File system  Flags
 1      0.00GiB  0.48GiB  0.48GiB  primary   ext2         boot
 2      0.48GiB  250GiB   250GiB   extended
 5      0.48GiB  250GiB   250GiB   logical                lvm
        250GiB   300GiB   50.0GiB            Free Space   ← le rab

$ sudo vgs
  VG          #PV #LV #SN Attr   VSize    VFree
  debian12-vg   1   5   0 wz--n- <249.52g    0

Plan

hyperviseur (Proxmox)  ──  disque sda  ──  partition étendue sda2  ──  partition logique sda5  ──  PV LVM  ──  VG  ──  LV var  ──  ext4
  qm resize +XG               (agrandi)            agrandir                  agrandir            pvresize    +50G   lvextend -r

Deux côtés à traiter :

1. Côté hyperviseur (Proxmox) — n'est nécessaire que si lsblk côté invité ne montre pas déjà d'espace libre après la dernière partition. Dans le cas OSBoxes, l'image arrive avec un disque de 300 G mais des partitions qui n'occupent que 250 G : l'espace est déjà là, à étape à sauter. Si à l'inverse le disque est plein jusqu'au bout, il faut l'agrandir côté Proxmox d'abord.
2. Côté invité — toujours nécessaire. En MBR avec partition étendue + logique, on doit étendre sda2 AVANT sda5 : la logique ne peut pas dépasser les bornes de l'étendue qui la contient.

Préalable : agrandir le disque virtuel côté Proxmox

À faire uniquement si parted /dev/sda print free côté invité ne montre pas déjà 50 GiB de Free Space après sda5. Sur un disque OSBoxes "vierge", l'espace est déjà présent → passer directement à la procédure côté invité.

En CLI sur l'hôte Proxmox

# 1. Identifier la VM et son disque
qm list                       # repérer le VMID (ex. 101)
qm config 101 | grep -E '^scsi|^virtio|^ide|^sata'
# scsi0: local-lvm:vm-101-disk-0,iothread=1,size=300G

# 2. Agrandir le disque (ajoute +50G, peut se faire VM allumée si scsihw=virtio-scsi-single)
qm resize 101 scsi0 +50G

# 3. Vérifier
qm config 101 | grep ^scsi0
# scsi0: local-lvm:vm-101-disk-0,iothread=1,size=350G

qm resize n'accepte qu'augmentation ; pas de réduction. La syntaxe +50G ajoute, sans + la valeur est interprétée comme nouvelle taille absolue.

En GUI Proxmox

VM → onglet Hardware → sélectionner le disque (scsi0/virtio0/...) → bouton Disk Action → Resize → entrer la valeur à ajouter (champ "Size Increment").

Faire voir la nouvelle taille à l'invité (sans reboot)

Si la VM est allumée, le noyau invité ne re-scan pas tout seul. Forcer le rescan :

# côté VM, en root
echo 1 | sudo tee /sys/block/sda/device/rescan
# pour un disque virtio (vda) :
echo 1 | sudo tee /sys/class/block/vda/device/rescan

lsblk    # sda doit afficher la nouvelle taille

Si ça ne suffit pas (cas rare avec certains contrôleurs), un reboot de la VM règle le problème.

Procédure (côté invité)

# 1. Étendre la partition étendue sda2 jusqu'à 100% du disque
printf "Yes\n" | sudo parted ---pretend-input-tty /dev/sda resizepart 2 100%

# 2. Étendre la partition logique sda5 jusqu'à 100% (= bord de sda2)
printf "Yes\n" | sudo parted ---pretend-input-tty /dev/sda resizepart 5 100%

# 3. Demander au noyau de relire la table de partitions
sudo partprobe /dev/sda

# 4. Vérifier que sda5 fait bien la nouvelle taille
lsblk /dev/sda

# 5. Étendre le PV LVM dans sda5
sudo pvresize /dev/sda5

# 6. Vérifier que le VG a bien récupéré l'espace
sudo vgs
#   VG          #PV #LV #SN Attr   VSize    VFree
#   debian12-vg   1   5   0 wz--n- <299.52g 50.00g

# 7. Étendre le LV /var de +50G AVEC redimensionnement du fs ext4 en ligne (-r)
sudo lvextend -L +50G -r debian12-vg/var

# 8. Vérification finale
df -hT /var
# /dev/mapper/debian12--vg-var  ext4  59G  4.4G  52G  8% /var

Résultat

Élément	Avant	Après
sda5	249.5 G	299.5 G
VG VFree	0	0 (réinjecté)
LV var	9.3 G	59.3 G
/var ext4 dispo	4.3 G	52 G

Aucun démontage, aucun reboot. ext4 supporte le resize2fs en ligne pour les extensions (le shrink, lui, exige un démontage).

Pourquoi pas toucher à /home ?

Idée alternative initialement envisagée : shrink /home (qui n'a que 2 G utilisés sur 214 G) puis injecter dans /var. Bien plus risqué :

• shrink ext4 = umount /home obligatoire (impossible si user connecté avec home dedans → reboot rescue ou root console),
• shrink est l'étape destructive en cas de pépin,
• l'extension PV depuis l'espace libre du disque est totalement non-destructive et en ligne.

Toujours préférer la première option si elle existe.

---

Troubleshooting

parted refuse "Partition is being used"

parted demande une confirmation interactive quand la partition est en cours d'utilisation. En SSH non-interactif :

printf "Yes\n" | sudo parted ---pretend-input-tty /dev/sda resizepart 2 100%

Le ---pretend-input-tty (trois tirets) force parted à se croire en mode interactif et accepter le Yes piped. Ne pas confondre avec parted -s (script mode) qui, lui, fait l'inverse : refuse toute opération nécessitant confirmation et échoue.

partprobe échoue avec "Device or resource busy"

Le PV est actif → certains noyaux refusent de relire la table. Essayer dans l'ordre :

sudo partprobe /dev/sda
# sinon
sudo partx -u /dev/sda
# sinon : reboot

Le reboot ne pose aucun problème : la nouvelle taille de partition est dans la table MBR sur disque, elle sera reprise au boot. Le pvresize se fait après reboot.

lvextend dit "Insufficient free space"

Tu as oublié pvresize /dev/sda5 après le resize de partition. Le PV ne sait pas encore qu'il a grandi. vgs montre VFree = 0 dans ce cas.

Disque GPT au lieu de MBR

Pas de partition étendue/logique en GPT. Procédure simplifiée :

sudo parted /dev/sda resizepart <N> 100%   # N = numéro de la partition contenant le PV
sudo partprobe /dev/sda
sudo pvresize /dev/sda<N>
sudo lvextend -L +50G -r vgname/lvname

Vérifier avec sudo parted /dev/sda print → si Partition Table: gpt, c'est ce cas.

Croissance d'un disque virtuel (VMware/Proxmox/QEMU) sans rab visible

Il faut d'abord agrandir le disque côté hyperviseur, puis dire au noyau invité de re-scanner :

echo 1 | sudo tee /sys/block/sda/device/rescan
# ou pour un disque virtio :
echo 1 | sudo tee /sys/class/block/vda/device/rescan

Puis lsblk doit montrer la nouvelle taille de sda avant de pouvoir resize la partition.

Filesystem autre qu'ext4

lvextend -r délègue à l'outil de resize approprié :

• ext2/3/4 → resize2fs (en ligne pour grow)
• xfs → xfs_growfs (en ligne pour grow, jamais shrink)
• btrfs → btrfs filesystem resize (en ligne)

Pour les shrink, seul ext* le permet, et obligatoirement hors ligne.

Toujours sauvegarder la table de partitions avant (optionnel mais recommandé)

sudo sfdisk -d /dev/sda > /root/sda.parts.$(date +%F).bak
# restauration en cas de catastrophe :
sudo sfdisk /dev/sda < /root/sda.parts.YYYY-MM-DD.bak

Références

• man parted, section resizepart
• man lvextend, option -r/--resizefs
• man pvresize
• ext4 online resize: kernel feature resize_inode (activé par défaut)