LVM avec Ansible : pipeline pv → vg → lv → filesystem → mount

LVM (Logical Volume Manager) abstrait les disques physiques en volumes logiques redimensionnables. Sur RHEL 2026, c'est l'outil standard pour gérer le stockage des serveurs. Pipeline classique :

PV (Physical Volume), disque ou partition initialisée pour LVM.
VG (Volume Group), pool de PVs combinés.
LV (Logical Volume), volume découpé dans le VG (le "disque virtuel" utilisable).

4 modules Ansible forment le pipeline storage complet :

community.general.lvg:, gérer les Volume Groups (PVs inclus).
community.general.lvol:, gérer les Logical Volumes.
community.general.filesystem:, formater un LV ou un disque.
ansible.posix.mount:, monter et persister dans fstab.

Ce que vous allez apprendre

Construire un PV → VG → LV en chaîne avec les modules dédiés.
Formater un LV en xfs ou ext4 avec idempotence.
Monter le LV via /dev/<vg>/<lv> dans fstab.
Étendre un LV à chaud avec lvol: resizefs: true.
Comprendre l'ordre du teardown (inverse de la création).

Prérequis

community.general et ansible.posix installés.
Sur le managed node : lvm2, parted, xfsprogs (généralement installés par défaut sur RHEL).

Pipeline complet

- name: Pipeline LVM complet
  hosts: db1.lab
  become: true
  tasks:
    - name: 1. Creer le VG sur un disque (ou loop device)
      community.general.lvg:
        vg: lab_vg
        pvs: /dev/loop10
        state: present

    - name: 2. Creer le LV (300M)
      community.general.lvol:
        vg: lab_vg
        lv: lab_lv
        size: 300M
        state: present

    - name: 3. Formater en xfs
      community.general.filesystem:
        fstype: xfs
        dev: /dev/lab_vg/lab_lv

    - name: 4. Creer le point de montage
      ansible.builtin.file:
        path: /mnt/lvm-data
        state: directory
        mode: "0755"

    - name: 5. Monter le LV (fstab + maintenant)
      ansible.posix.mount:
        path: /mnt/lvm-data
        src: /dev/lab_vg/lab_lv
        fstype: xfs
        opts: defaults,noatime
        state: mounted

5 tâches dans l'ordre strict. Chaque module est idempotent, 2e run → changed=0.

`lvg:`, Volume Group (PV + VG en une étape)

- name: Créer le groupe de volumes lab_vg
  community.general.lvg:
    vg: lab_vg
    pvs: /dev/loop10
    state: present

Le module fait 2 choses :

pvcreate /dev/loop10, initialise le PV.
vgcreate lab_vg /dev/loop10, crée le VG sur ce PV.

Étendre le VG ultérieurement avec un nouveau disque :

- name: Créer le groupe de volumes lab_vg
  community.general.lvg:
    vg: lab_vg
    pvs: /dev/loop10,/dev/loop11   # Ajout du 2e disque
    state: present

`lvol:`, Logical Volume

- name: Créer le volume logique lab_lv
  community.general.lvol:
    vg: lab_vg
    lv: lab_lv
    size: 100%FREE
    state: present

Format de size: :

100M, taille fixe (en MB).
50%FREE, 50% de l'espace libre du VG.
+10G, extension de 10Go (relatif).
100%VG, tout l'espace du VG.

Le LV est créé à /dev/lab_vg/lab_lv (ou /dev/mapper/lab_vg-lab_lv).

Note RHCE : LVM arrondit à des multiples du PE size (4Mo par défaut). Demander 100M peut donner 100M ou 104M selon les cas.

`filesystem:`, formater le LV

- name: Formater lab_lv
  community.general.filesystem:
    fstype: xfs
    dev: /dev/lab_vg/lab_lv

Idempotent : si le filesystem est déjà du bon type, changed=0. force: true force le reformatage si un autre filesystem existe (DANGER, perte de données).

Filesystems supportés : ext2, ext3, ext4, xfs, btrfs, f2fs, etc.

Convention RHCE 2026 :

xfs est le défaut RHEL 7+ (performant, snapshots, quotas).
ext4 reste utilisé pour /boot ou besoin de réduction (xfs ne sait pas réduire).

Limitation xfs : taille minimale ~300Mo. En dessous, mkfs.xfs échoue.

`mount:`, monter le LV

- name: Monter lvm-data
  ansible.posix.mount:
    path: /mnt/lvm-data
    src: /dev/lab_vg/lab_lv
    fstype: xfs
    opts: defaults,noatime
    state: mounted

Le LV monté via /dev/<vg>/<lv> est plus stable que /dev/sdaX, LVM gère l'alias logique même si le disque change de position physique.

Pattern préféré pour fstab : utiliser UUID=... plutôt que /dev/... :

ssh ansible@db1.lab 'sudo blkid /dev/lab_vg/lab_lv'
# /dev/lab_vg/lab_lv: UUID="abc-123" TYPE="xfs"

Étendre un LV à chaud

Cas réel : votre /var/log/ est plein. Vous étendez le LV sans démonter :

- name: Créer le volume logique lab_lv
  community.general.lvol:
    vg: lab_vg
    lv: lab_lv
    size: +500M
    resizefs: true   # Etend le filesystem aussi
    state: present

lvextend étend le LV de 500Mo.
resizefs: true lance xfs_growfs (ou resize2fs pour ext4) pour étendre le filesystem sans démonter.

Limitation XFS : xfs_growfs peut étendre mais pas réduire. Pour réduire, il faut ext4 ou démonter + reformater.

Le piège : ordre de teardown

# ❌ DANGER : vgremove echoue si des LVs existent encore
- name: Créer le groupe de volumes lab_vg
  community.general.lvg:
    vg: lab_vg
    state: absent

Ordre correct pour le teardown (inverse de la création) :

- name: 1. Demonter et retirer fstab
  ansible.posix.mount:
    path: /mnt/lvm-data
    state: absent

- name: 2. Supprimer le LV
  community.general.lvol:
    vg: lab_vg
    lv: lab_lv
    state: absent

- name: 3. Supprimer le VG
  community.general.lvg:
    vg: lab_vg
    state: absent

Sauter une étape = échec ou orphelins LVM qui hantent ensuite vos déploiements.

Pièges courants

Symptôme	Cause	Fix
`mkfs.xfs` failed sur LV 100M	xfs minimum ~300M	Augmenter le LV ou utiliser ext4
LV taille différente du `size:` demandé	Arrondi PE size	Vérifier avec `lvs --units M`
Teardown VG bloque	LVs encore présents	Supprimer LVs d'abord
`xfs_growfs` réduit failed	xfs ne sait pas réduire	Backup + reformater + restore

À retenir

Pipeline LVM : lvg: (PV+VG) → lvol: (LV) → filesystem: (FS) → mount:.
size: accepte : 100M, 50%FREE, +10G, 100%VG.
xfs est le défaut RHEL 7+ (limitation : ne réduit pas, minimum ~300M).
resizefs: true étend filesystem à chaud.
Teardown = inverse de la création (mount → lvol → lvg).
PE size (4Mo défaut) cause des arrondis légers sur la taille du LV.

Mettre en pratique

Les quatre modules du pipeline ne prennent leur sens qu'enchaînés sur un vrai disque. Ce lab vous fait construire le PV, le VG et le LV sur un disque secondaire, formater le volume, puis le monter via fstab pour qu'il survive au redémarrage. La dernière étape agrandit le LV à chaud avec resizefs: true, et c'est la taille réellement disponible sur le point de montage qui est contrôlée.

LVM : chaîner lvg, lvol, filesystem et mount

$ dsoxlab run modules-rhel-lvm-storage

Environnement : VM·Durée : ~50 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-rhel-lvm-storage
dsoxlab check modules-rhel-lvm-storage

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Pour aller plus loin

Module reboot : la seule preuve qu'un volume monté via fstab revient bien après un redémarrage.
Module stat : conditionner une extension sur l'état réel du périphérique plutôt que sur une hypothèse.
Écrire ses premiers rôles : industrialiser le pipeline LVM dans un rôle paramétrable.