Il y a quelques semaines, Gautier Husson (un expert Promox avec qui on a travaillé en juin) m’a recommandé la lecture d’un article en particulier qui explique complètement le fonctionnement des « LUNs raw sur la technologie qcow2/lvm » et qui permet notamment d’avoir des snaps sur les technologies iSCSI (et accessoirement FC puisque c’est grosso modo la même chose sur un support différent).
L’article en question via de la société BlobkBridge et est tellement intéressant qu’il me semblait important, pendant mes vacances, de prendre le temps de le traduire en Français, avec l’aide de mon Jarvis perso bien sûr, et relu et corrigé par moi-même. Pour une petite lecture à la plage, comme un mini roman d’été 😉
Voici l’article original au cazoo : https://kb.blockbridge.com/technote/proxmox-qcow-snapshots-on-lvm/
Proxmox VE 9 déverrouille (enfin) les snapshots sur les SAN traditionnels (iSCSI ou FC, donc)
Proxmox VE 9 introduit une évolution attendue depuis pas mal de temps et qui pénalisait en grande partie ceux qui voulaient absolument utiliser ce type de techno plutôt que du file, type NFS: la prise en charge des snapshots pour les environnements SAN legacy, avec toutes les technologies de baies de stockage partagées associées. Cette avancée, encore en technology preview (NDT : c’est important à rappeler pour de la production éventuelle), s’appuie sur une combinaison astucieuse de QCOW2 et de volumes LVM thin pour offrir ce qui manquait cruellement aux infrastructures iSCSI ou Fibre Channel. Permettre aux administrateurs de créer, restaurer ou supprimer des snaps de VM directement sur des LUNs partagés.
Avant PVE9, la donne était simple : les snapshots QCOW2, dynamiques et thin par nature, exigeaient un système de fichiers sous-jacent capable de gérer leur croissance à la demande. NFS s’était imposé comme le compromis universel, compatible avec cette approche. Mais les SAN, avec leurs LUNs statiquement alloués, restaient hors jeu. En effet, QCOW2, conçu pour des fichiers, ne s’accommodait pas des contraintes des volumes bruts, où chaque octet non écrit doit impérativement renvoyer des zéros sous peine de corruption. Un détail technique qui bloquait toute intégration propre.
QCOW2 sur LVM thick : un mariage un peu contre nature
La nouveauté de PVE9 réside dans l’utilisation de volumes logiques LVM thick comme support brut pour des images QCOW2. Chaque disque de machine virtuelle, et chaque snapshot, est stocké sous forme d’image QCOW2 posée sur un volume LVM dédié, pré-alloué à une taille suffisante pour absorber l’intégralité des données et des métadonnées du format. Quand un snapshot est créé, Proxmox alloue un nouveau volume LVM thick, y dépose une nouvelle image QCOW2 en overlay, et la lie à l’image précédente via le mécanisme de backing file. Une chaîne linéaire de couches où les lectures remontent les versions, tandis que les écritures ciblent toujours la couche supérieure.
Les snapshots deviennent possibles sur des LUNs partagés, et les retours en arrière (rollbacks) sont fulgurants, puisque la restauration se résume à basculer vers une image précédente. Finis les copies lentes ou les manipulations complexes. En revanche, cette élégance a un prix. Le format QCOW2, avec son copy-on-write et ses métadonnées hiérarchiques, introduit une surcharge non négligeable : entre 30 % et 90 % de perte de performances selon les cas, surtout quand les métadonnées ne tiennent plus en mémoire ou que la chaîne de snapshots s’allonge. Un compromis à bien mesurer avant d’utiliser ce système.
QCOW2 : un format conçu pour l’efficacité, pas pour la simplicité
Le format QCOW2 (QEMU Copy-On-Write) est une prouesse d’ingénierie logicielle, pensée pour les environnements virtualisés où l’espace et la flexibilité comptent autant que la performance. Son architecture repose sur une double table de mappage (L1 et L2) qui traduit les adresses virtuelles du disque invité en offsets physiques dans le fichier image, le tout découpé en clusters de 64 Ko par défaut. Chaque cluster non alloué reste sparse (typiquemement le volume s’étend dynamiquement mais ne consomme que ce qui est utilisé) : tant qu’aucune donnée n’y est écrite, il n’occupe aucun espace sur le stockage sous-jacent. C’est ce mécanisme de thin provisioning qui permet à QCOW2 de créer des disques virtuels bien plus grands que l’espace réellement consommé.
Mais la vraie « sorcellerie » opère au moment des écritures. Grâce au copy-on-write, toute modification d’un cluster existant déclenche la création d’une nouvelle copie : les données originales sont lues, modifiées, puis écrites dans un nouvel emplacement, préservant ainsi l’intégrité des snapshots précédents. Ce comportement, s’il permet un versioning efficace, génère une amplification des E/S, particulièrement pénalisante avec des écritures petites ou non alignées. Les snapshots, qu’ils soient internes (tout dans un seul fichier) ou externes (chaîne de fichiers QCOW2 indépendants), exploient cette mécanique, mais avec des trade-offs distincts : les premiers simplifient la gestion, les seconds accélèrent les retours en arrière… au prix d’une dégradation progressive des performances à mesure que la chaîne s’allonge.
LVM : le socle invisible qui rend tout cela possible
Derrière cette intégration se cache un autre acteur clé : LVM, le Logical Volume Manager de Linux. Contrairement aux schémas de partitionnement classiques, LVM permet de regrouper des disques physiques (ou Physical Volumes) au sein de pools logiques (Volume Groups), puis d’y allouer dynamiquement des volumes (Logical Volumes) utilisables comme des disques bruts par les machines virtuelles. Dans Proxmox, chaque VM dispose ainsi de son propre LV, géré par le cluster pour garantir une écriture exclusive des métadonnées : un seul nœud à la fois peut modifier la configuration LVM, les autres se contentant de rafraîchir leur vue locale via un mécanisme de polling coordonné.
Cette approche single-writer est cruciale pour éviter les corruptions, mais elle impose une limite : seul le thick provisioning est supporté. Le thin LVM, qui alloue l’espace à la volée, est en effet incompatible avec ce modèle de synchronisation. Autre contrainte : chaque snapshot nécessite un nouveau LV thick, pré-alloué à la taille maximale possible du disque QCOW2. Une exigence qui peut vite devenir coûteuse en espace, surtout quand on enchaîne les snapshots horaires sur des disques de plusieurs téraoctets. Sans compter que les opérations de fusion lors de la suppression d’un snapshot peuvent, paradoxalement, augmenter la consommation de stockage, en raison des copies de données nécessaires pour maintenir la cohérence de la chaîne.
Attention aux pièges : performances, sécurité et compatibilité
Si la fonctionnalité est prometteuse, elle n’est pas (encore) exempte de défis. Le premier, et le plus visible, est la baisse de performances : entre 30 % et 90 % selon les scénarios, avec un impact d’autant plus marqué que les disques sont grands ou que les snapshots s’accumulent (NDT : attention quand vous faites des snaps … ils doivent durer un minimum de temps et ne doivent être faits qu’a des moments où c’est possible et si la performance est très importante sur le workload considéré). Les tests menés par Blockbridge (NDT : et sur mes premiers tests aussi …) montrent par exemple une chute de 60 % en bande passante et de 30 % en IOPS sur des disques de moins de 256 Go, où les métadonnées QCOW2 tiennent encore en mémoire. Au-delà, la dégradation atteint 90 % sur les accès non séquentiels, la chaîne de snapshots amplifiant l’I/O nécessaire pour chaque opération.
Autre problème : la consistance des données. QCOW2 suppose que toute lecture sur une zone non écrite renvoie des zéros. Or, un volume LVM nouvellement créé n’est pas systématiquement initialisé à zéro. En cas de perte de puissance, des résidus de données précédentes pourraient être interprétés comme valides, corrompant l’image ou exposant des informations sensibles à la VM. Une parade partielle existe (activer le Wipe Removed Volumes), mais elle ne résout pas le problème de fond. Enfin, côté compatibilité, les disques TPM (pour les fonctionnalités de sécurité comme BitLocker par exemple) ne supportent pas QCOW2 : impossible de faire des snaps d’une VM si son disque TPM réside sur un pool LVM partagé. Et les baies NVMe/TCP ou NVMe/Fabrics sont à éviter en production, Linux n’y implémentant pas encore les mécanismes de limitation de files d’attente multi-hôtes, essentiels pour éviter les goulots d’étranglement.
Un pas en avant, mais pas encore la panacée
Proxmox VE 9 franchit une étape importante en rendant les snapshots accessibles aux environnements SAN traditionnels, avec à la clé des retours en arrière rapides et une intégration transparente dans l’écosystème existant. Pour autant, les limites actuelles — performances en berne, risques de fuite de données, surcoût de stockage, incompatibilités matérielles — en font une fonctionnalité réservée aux tests ou aux déploiements très contrôlés.
La route vers une solution mature est encore longue, mais la direction est la bonne. Les prochaines versions devront impérativement adresser ces points, notamment via une meilleure initialisation des volumes, une optimisation du copy-on-write, ou une intégration plus poussée avec les baies modernes. En l’état, mieux vaut s’en tenir aux stockages fichiers (NFS, CephFS) ou aux solutions dédiées pour les environnements critiques. Mais pour ceux qui veulent explorer les possibilités, PVE9 offre enfin un terrain de jeu… à manipuler avec précaution.
Conclusion du traducteur (l’humain, pas l’IA)
… je reprend la main rapidement, pour vous dire que malgré certains points qui semblent vraiment problématiques aujourd’hui, je connais certains collègues d’autres DSI qui utilisent ce système en production, malgré les risques inhérents aux technologies utilisées et encore en preview. En gros, si vous avez une BONNE sauvegarde, bien solide et que vos tests de restauration sont réguliers. Après tout, pourquoi pas, tant qu’on est pas sur des productions critiques.
C’est ça aussi l’Open Source, ça avance très vite, ça en met plein les yeux, mais il faut être conscient de ce qu’on fait sans accepter aveuglément une techno. D’où la nécessité de prend le TEMPS de mettre en place tout cela, malgré tout ce que vous dirons vos responsables et autres directeurs ayant en charge avant tout l’aspect ROI financier de la chose …
Bon journée sur vos serviettes de bain !
Références :
– Gautier sur LinkedIn (si vous voulez le contacter) : https://www.linkedin.com/in/gautier-husson/
– L’artiocle original de Blobkbridge : https://kb.blockbridge.com/technote/proxmox-qcow-snapshots-on-lvm/