3. Le modèle de stockage de Proxmox : bloc, fichier, LVM-thin

Avant de construire un pool ZFS, de déclarer un stockage iSCSI ou de monter un cluster Ceph, il faut une grille de lecture commune. Tous ces stockages ne se ressemblent pas : certains offrent des disques bruts, d'autres des dossiers partagés. Cette distinction explique presque tout ce que Proxmox autorise ou refuse — quel format de disque, quels snapshots, où ranger une ISO.

3.1 Trois modèles de stockage : bloc, fichier, objet

Il existe trois grandes façons d'organiser des données sur un support, et Proxmox les rencontre toutes :

Le bloc fournit un disque nu, que le client formate lui-même. Le fichier fournit une arborescence partagée. L'objet fournit des objets entiers, adressés par URL.

Les disques de VM relèvent du bloc ; les ISO et les sauvegardes, du fichier ; l'objet n'apparaît dans Proxmox qu'à la marge (cible S3 de PBS).

Revenons à la définition de base : un stockage garde des données ; toute la question est de savoir qui les range.

Sur un stockage bloc, c'est la VM qui gère son système de fichiers. Sur un stockage fichier, c'est le serveur : une ISO ou une sauvegarde y est un fichier ordinaire.

Où voir le modèle de chaque stockage :

3.2 Le mode bloc : un disque brut, sans structure

Le stockage en mode bloc découpe la capacité en volumes présentés à l'hôte comme un disque dur brut : une simple suite de blocs numérotés, sans aucune structure interne. C'est au système qui le consomme de décider quoi en faire.

Le formater en ext4, y créer un pool ZFS ou un groupe LVM. Ou le donner directement à une VM comme disque virtuel.

Le stockage bloc ne connaît ni fichiers, ni dossiers, ni permissions. Il ne répond qu'à deux ordres : « lis le bloc n° X » et « écris ceci dans le bloc n° Y ». Cette absence de couche intermédiaire explique ses performances — latence faible, IOPS élevés — et sa polyvalence, au prix d'une richesse fonctionnelle nulle au niveau du volume lui-même.

Pour une VM, le chemin d'un bloc traverse plusieurs étages, et chacun reste en mode bloc. D'abord le disque /dev/sda vu par l'invité, puis QEMU qui transmet les écritures.

Ensuite le volume que Proxmox a attribué : un volume LVM-thin, un zvol ZFS, une image RBD Ceph ou un LUN iSCSI. Enfin, les disques physiques.

On le constate directement sur le nœud : un disque de VM rangé dans local-lvm n'est pas un fichier, c'est un périphérique bloc.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Le chemin réel d'un disque de VM stocké sur local-lvm
pvesm path local-lvm:vm-101-disk-0

Résultat attendu sur pxe211 (la VM 101 du chapitre 2) :

/dev/pve/vm-101-disk-0

/dev/pve/vm-101-disk-0 est un volume logique du groupe LVM pve : un périphérique sous /dev, sans extension, sans système de fichiers visible de l'hôte. C'est la VM qui, de l'intérieur, y a posé le sien.

3.3 Ce que le mode bloc implique dans Proxmox

Ce modèle a des conséquences très concrètes, que vous retrouverez à chaque création de disque :

• Format de disque imposé : raw. Un volume bloc est déjà un disque brut ; on ne peut pas y déposer un fichier qcow2, puisqu'il n'y a pas de système de fichiers pour l'accueillir.

  Les fonctions qu'apporterait qcow2 — snapshots, allocation à la demande — sont alors assurées par la couche bloc elle-même. C'est le thin provisioning pour LVM-thin (assuré par dm-thin, un module du device mapper du noyau Linux), et la copie sur écriture pour ZFS et Ceph.

• Snapshots : possibles si le backend bloc les fournit (LVM-thin, ZFS, Ceph RBD) ; impossibles sur du LVM « épais » (thick) ou sur un LUN iSCSI brut sans surcouche.

• Performance : chemin d'accès court, donc latence faible et IOPS élevés. C'est le bon choix pour les disques de VM, surtout pour les bases de données.

• Partage : un même volume bloc ne peut pas être monté en lecture-écriture par plusieurs nœuds à la fois, sous peine de corruption.

  Il faut alors une couche qui coordonne les nœuds. Ce peut être LVM en mode partagé (§5.2) ou un système de fichiers de cluster (OCFS2 — Oracle Cluster File System —, GFS2 — Global File System —). Ce peut être aussi un stockage distribué conçu pour cela, comme Ceph RBD.

• ISO, templates, sauvegardes : ce sont des fichiers. Ils ne peuvent pas vivre sur un stockage purement bloc ; il leur faut un stockage fichier (dir, NFS, CIFS) ou l'entrepôt de Proxmox Backup Server.

3.4 Un stockage Proxmox : un type, des contenus, un partage

Pour Proxmox, un stockage est une entrée de /etc/pve/storage.cfg — fichier répliqué par pmxcfs, donc identique sur tous les nœuds d'un cluster. Chaque entrée porte trois informations :

Datacenter → Storage sur pxe211 (Proxmox VE 9.2.21), votre écran à ce stade. C'est la vue graphique de storage.cfg : une ligne par stockage, avec son type (Directory, LVM-Thin), ses contenus (colonne Content), son chemin (Path/Target) et la colonne Shared.

local et local-lvm sont les deux stockages créés par l'installation. Ils sont propres au nœud : Shared No.

• un type : dir, lvm, lvmthin, zfspool, nfs, cifs, iscsi, rbd, cephfs, pbs… — il dit comment Proxmox accède aux données ;
• une liste de contenus acceptés : images (disques de VM), rootdir (disques de conteneurs), iso, vztmpl (templates LXC), backup, snippets, import ;
• un attribut shared, qui indique que le même contenu est visible depuis tous les nœuds (NFS, Ceph) — condition de la migration à chaud et de la haute disponibilité.

Le même écran sous Proxmox VE 9.2, bouton Add ouvert : la liste des types de stockage que Proxmox sait déclarer. En tête, les stockages en fichier ou en bloc locaux : Directory, LVM, LVM-Thin, BTRFS.

Puis les stockages réseau : NFS, SMB/CIFS, iSCSI, CephFS, RBD, ZFS over iSCSI. Puis ZFS, et deux types particuliers : Proxmox Backup Server, l'entrepôt de sauvegardes, et ESXi, qui sert à importer des VM depuis VMware.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Les stockages déclarés et leur remplissage
pvesm status

# Leur définition, telle que Proxmox la stocke
cat /etc/pve/storage.cfg

Résultat attendu sur pxe211 (Proxmox VE 9.2.21) :

Name             Type     Status     Total (KiB)      Used (KiB) Available (KiB)        %
local             dir     active        24527236         9669064        13695292   39.42%
local-lvm     lvmthin     active        64876544        42040000        22836543   64.80%

dir: local
    path /var/lib/vz
    content import,vztmpl,iso,backup

lvmthin: local-lvm
    thinpool data
    vgname pve
    content images,rootdir

Les deux stockages créés à l'installation illustrent parfaitement la distinction bloc/fichier, et c'est une confusion classique :

local est bien posé sur un volume LVM, mais Proxmox ne le voit que comme un répertoire : pas de thin provisioning, pas de snapshot au niveau du stockage. Seul local-lvm offre l'allocation à la demande, les snapshots par copie sur écriture et l'agrandissement à chaud.

Déclarer, modifier, retirer un stockage en ligne de commande. Les trois boutons Add, Edit et Remove de Datacenter → Storage ont leur équivalent pvesm.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

pvesm add dir essai-dir --path /var/tmp/essai-dir --content iso --create-base-path 1   # déclarer
pvesm set essai-dir --content iso,vztmpl                                                # modifier les contenus
grep -A3 "dir: essai-dir" /etc/pve/storage.cfg                                         # la déclaration écrite
pvesm remove essai-dir                                                                  # retirer la déclaration
ls -d /var/tmp/essai-dir                                                                # le répertoire, lui, reste

Résultat attendu (nœud pxe212) :

dir: essai-dir
    path /var/tmp/essai-dir
    content vztmpl,iso
    create-base-path 1
/var/tmp/essai-dir

pvesm remove retire seulement la déclaration dans storage.cfg. Le dossier, et tout ce qu'il contient, reste sur le disque : ls le retrouve. Pour effacer les données, il faut une action séparée.

L'ancienne option --mkdir 1 fonctionne encore, mais Proxmox affiche alors NOTE: The 'mkdir' option … is deprecated : on utilise --create-base-path.

3.5 LVM-thin : créer un pool sur des disques supplémentaires

Le chapitre 2 a détaillé le principe du thin provisioning sur le pool local-lvm installé par défaut : allocation à la demande, snapshots quasi instantanés, surveillance par lvs. Ce qui change ici : un nœud reçoit souvent des disques supplémentaires dédiés aux VM, séparés du disque système. Il faut alors construire un nouveau pool LVM-thin de toutes pièces.

La pile se lit de bas en haut, et c'est ce que font les trois commandes ci-dessous. Le disque devient un volume physique (PV : Physical Volume), rangé dans un groupe de volumes (VG : Volume Group).

Dans ce groupe, on crée un thin pool, un volume spécial qui distribue l'espace à la demande. Puis on le déclare à Proxmox comme stockage de type lvmthin.

Via l'interface graphique :

Nœud → Disks → LVM-Thin → Create: Thinpool

En ligne de commande :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Créer un nouveau groupe de volumes sur le disque dédié
# (vgcreate initialise lui-même le disque comme volume physique LVM)
vgcreate ssd /dev/sde

# Assigner l'ensemble de l'espace disponible du VG au thinpool
lvcreate --type thin-pool -l 100%FREE -n thin ssd

# Ajouter le thinpool comme stockage connu de Proxmox
pvesm add lvmthin thin --vgname ssd --thinpool thin --content rootdir,images

Résultat attendu (testé sur PVE 9.2 avec un disque de test) :

  Physical volume "/dev/sde" successfully created.
  Volume group "ssd" successfully created
  Thin pool volume with chunk size 64.00 KiB can address at most <15.88 TiB of data.
  Logical volume "thin" created.

vgcreate a d'abord initialisé le disque comme volume physique, puis créé le groupe. La ligne chunk size 64.00 KiB de lvcreate n'est pas une erreur : elle donne la granularité d'allocation du pool.

L'espace est distribué aux disques de VM par tranches de 64 Kio, au fur et à mesure des écritures. L'entrée ajoutée à /etc/pve/storage.cfg :

lvmthin: thin
    thinpool thin
    vgname ssd
    content images,rootdir

Proxmox range lui-même la liste des contenus (images,rootdir, quel que soit l'ordre saisi). Sans l'option --content, aucune ligne content n'est écrite : le stockage accepte alors, par défaut, les disques de VM et de conteneurs.

Le pool se surveille ensuite comme local-lvm. Voici la lecture du pool installé par défaut, sur le groupe pve :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Espace réellement consommé (Data%) et métadonnées (Meta%) du thin pool, volume par volume
lvs -o lv_name,lv_size,pool_lv,data_percent,metadata_percent pve

Résultat attendu (sur un nœud PVE 9.2) :

  LV               LSize    Pool Data%  Meta%
  data             <816.21g      11.01  0.59
  root               96.00g
  swap                8.00g
  vm-101-cloudinit    4.00m data 9.38
  vm-101-disk-0      20.00g data 10.34

La ligne data est le thin pool lui-même : Data% est son remplissage physique réel, toujours inférieur ou égal à la somme des tailles annoncées des disques qu'il héberge. Les lignes vm-… sont les disques des VM, rattachés au pool (colonne Pool) : vm-101-disk-0 annonce 20 Go mais n'en occupe réellement que 10 %.

root et swap, sans pool, sont des volumes classiques — root porte le stockage local. Surveillez aussi Meta% : un thin pool dont les métadonnées sont pleines se bloque exactement comme s'il manquait de données.

• 📖 Documentation Proxmox — Storage
• 📖 Le chapitre Storage du guide d'administration (types, contenus, fonctions par backend)
• 📖 LVM-thin dans Proxmox VE — pve-admin-guide
• 📖 Stockage fichier, bloc et objet — Red Hat

À retenir : trois modèles : le bloc (un disque brut, structuré par l'invité : LVM-thin, ZFS, iSCSI, Ceph RBD), le fichier (un dossier partagé : répertoire, NFS) et l'objet. Un stockage Proxmox est une entrée de /etc/pve/storage.cfg : un type, des contenus autorisés, et le fait d'être partagé ou non.