Aller au contenu

LVM partagé sur LUN : snapshots, thin vs thick, limites

Day 0 · ConcevoirNiveau 3 · MaîtriserCoursRédigé · à valider en lab

Sur un SAN, Proxmox utilise du LVM épais (thick) partagé : c'est la seule forme de LVM sûre en accès concurrent. Depuis PVE 9.0, il accepte des snapshots de VM grâce aux chaînes de volumes qcow2 (snapshot-as-volume-chain), une fonction encore en aperçu technologique (support « best effort ») en PVE 9.2. Objectif : comprendre ce mécanisme, ses coûts et ses limites avant de promettre des snapshots à vos équipes.

Notions clés

Thick vs thin

Critère LVM (thick) LVM-thin
Plugin lvm lvmthin
Partageable entre nœuds Oui, avec shared 1 Non, local uniquement
Allocation Taille complète réservée à la création À la demande
Snapshots qcow2 en chaîne de volumes (aperçu, PVE 9+, VM uniquement) Natifs, matures
Verrouillage Verrou cluster de Proxmox si shared 1 Aucun verrou multi-hôtes
Thin provisioning Seulement côté baie (LUN thin) Côté hôte

Retenez : sur un LUN partagé, toujours lvm, jamais lvmthin. Si vous voulez du thin, activez-le sur la baie.

Comment fonctionne le snapshot en chaîne de volumes

Sans cette option, un disque sur LVM est un LV au format raw : pas de snapshot. Avec snapshot-as-volume-chain 1, les nouveaux disques sont créés en qcow2 directement dans un LV. Un snapshot :

  1. renomme le volume courant en volume de snapshot, désormais en lecture seule ;
  2. crée un nouveau LV qcow2 dont le backing file pointe vers le précédent ;
  3. la VM écrit dans le nouveau volume.

Proxmox n'utilise pas les snapshots internes qcow2 : il se sert seulement de la superposition de volumes (backing chain). La gestion des snapshots reste faite par la couche stockage de Proxmox.

flowchart LR
    B[vm-101-disk-0 base<br/>lecture seule] --> S1[snap-avant-maj<br/>lecture seule] --> C[volume courant<br/>écritures de la VM]

Coûts et limites

Point Ce qu'il faut savoir
Statut Aperçu technologique depuis PVE 9.0, améliorations en 9.1 et 9.2. Le retrait de ce statut figure sur la feuille de route, sans date.
Format Seuls les disques qcow2 prennent des snapshots. Les disques raw existants doivent être déplacés (Move disk) vers le même stockage pour être convertis.
Activation L'option ne concerne que les disques créés après son activation.
Conteneurs Les snapshots en chaîne de volumes concernent les VM. Pas les conteneurs LXC.
Espace En LVM épais, chaque volume de la chaîne est un LV alloué sur le VG. Prévoyez nettement plus d'espace libre que la somme des disques (à mesurer en lab).
Suppression Supprimer un snapshot fusionne des données : l'opération écrit beaucoup sur la baie.
Performances Une chaîne longue dégrade les lectures. Gardez 1 à 2 snapshots, quelques jours au plus.
TPM PVE 9.2 autorise les snapshots à chaud des VM avec état TPM sur ces stockages ; en 9.0/9.1, limitations connues.

Exemple de storage.cfg

iscsi: san-iscsi
        portal 10.20.0.10
        target iqn.2001-05.com.baie:pve-lun01
        content none

lvm: san-lvm
        vgname vg_san
        base san-iscsi:0.0.1.scsi-36001405abcdef0123456789
        shared 1
        content images
        saferemove 1
        snapshot-as-volume-chain 1
  • base : volume de base activé avant l'accès au VG, utile quand le VG est sur un LUN iSCSI déclaré dans Proxmox. Sur FC ou avec multipath, on déclare souvent seulement le VG.
  • saferemove 1 (GUI : Wipe Removed Volumes) : met à zéro les LV supprimés. Recommandé pour éviter de retrouver d'anciennes données dans un nouveau disque. Depuis PVE 9.1, Proxmox utilise blkdiscard quand c'est possible, plus rapide.
  • GUI : Datacenter → Storage → Add → LVM, cases Shared et Allow Snapshots as Volume-Chain.

Point de vigilance de la mise à niveau 8 → 9

Sur LVM partagé, PVE 9 désactive l'auto-activation des nouveaux LV. Le script pve8to9 signale les LV existants encore en auto-activation et propose un script de migration. Cette étape fait partie de la mise à niveau majeure, pilotée par le MSP.

Recommandations MSP

  • N'activez snapshot-as-volume-chain qu'après validation en lab et accord du MSP : c'est un aperçu technologique, le support reste « best effort ».
  • Le snapshot n'est pas une sauvegarde. Avant une mise à jour applicative, une sauvegarde PBS vers pbs-local reste la référence.
  • Si la baie propose des snapshots de LUN, ils capturent tout le VG, donc toutes les VM : utiles pour le PRA, inutilisables pour restaurer une seule VM sans le MSP.
  • Supprimez les snapshots dès que la mise à jour est validée.

Pièges vus en support

  • Bouton Take Snapshot grisé : le disque est en raw ou le stockage n'a pas l'option. Ce n'est pas une panne.
  • VG plein après plusieurs snapshots : les VM se figent en écriture. Surveillez vgs (colonne VFree).
  • LVM-thin créé « pour avoir des snapshots » sur un LUN partagé : configuration non supportée, à défaire.
  • Snapshot de LUN côté baie restauré sans arrêter le cluster : métadonnées LVM incohérentes entre nœuds.

Testez-vous

  1. Pourquoi un disque raw existant ne peut-il pas être snapshotté après activation de l'option ?

    Réponse

    L'option ne s'applique qu'aux nouveaux disques, et le mécanisme exige le format qcow2. Il faut convertir le disque en le déplaçant (Move disk) vers le même stockage au format qcow2.

  2. Quel est le statut de support des snapshots en chaîne de volumes en PVE 9.x ?

    Réponse

    Aperçu technologique, support au mieux (« best effort »). Il est prévu de le retirer, sans date annoncée.

  3. Que fait l'option saferemove ?

    Réponse

    Elle met à zéro les volumes supprimés (Wipe Removed Volumes), pour qu'un nouveau disque ne contienne pas d'anciennes données.

  4. Peut-on snapshotter un conteneur LXC sur LVM partagé ?

    Réponse

    Non. Les snapshots en chaîne de volumes concernent les VM.

Pour aller plus loin