5. Le stockage réseau : NFS et iSCSI

ZFS et LVM-thin couvrent le stockage local d'un nœud. Dès que plusieurs nœuds doivent accéder aux mêmes données, ou que vous voulez centraliser ISOs et sauvegardes, il faut du stockage réseau. Deux protocoles classiques structurent ce sujet.

NFS (Network File System) expose un répertoire d'un serveur comme un dossier réseau. C'est la solution la plus simple pour partager des ISOs, des templates ou des sauvegardes entre nœuds. NFS fonctionne bien pour du stockage de fichiers, moins bien pour des disques de VMs en production à cause de la latence et des problèmes de verrouillage en accès concurrent.

iSCSI expose des blocs de disque (LUNs) à travers le réseau IP, comme si c'était un disque local. C'est plus performant que NFS pour les disques de VMs car il n'y a aucune couche de système de fichiers entre Proxmox et le stockage.

Le serveur NFS ou la baie iSCSI sont fournis par l'infrastructure de stockage de l'entreprise : on ne les construit pas sur Proxmox. Côté Proxmox, le travail consiste à déclarer ces stockages.

5.1 Ajouter un partage NFS à Proxmox

Dans l'interface :

Datacenter → Storage → Add → NFS

(nœud pxe211 du lab d'exemple, devant un serveur NFS de test). Quatre points méritent l'attention.

• Le champ Export est une liste déroulante, pas un champ libre. Dès l'adresse du serveur saisie, Proxmox l'interroge et affiche ce qu'il partage réellement.

  Si la liste reste vide, inutile de remplir le reste : soit le serveur ne répond pas, soit il n'exporte pas vers ce nœud. C'est le test de connectivité le plus rapide dont vous disposiez.

• Le champ Content décide de ce que le stockage acceptera : sauvegardes, ISO, disques de machines, modèles de conteneurs. Un contenu non coché ne pourra pas y être écrit.

• Nodes : All (No restrictions) déclare le stockage pour tous les nœuds du cluster. Chacun devra pouvoir joindre le serveur, sans quoi le stockage remontera en erreur sur ceux qui n'y arrivent pas.

• La colonne Shared, dans la liste derrière la fenêtre. local et local-lvm affichent No.

  Le partage NFS affichera Yes : la distinction entre stockage local et stockage partagé, rendue visible en une colonne. C'est elle qui conditionne la migration à chaud et la haute disponibilité.

Laissez NFS Version sur Default : client et serveur négocient seuls. Ne cochez pas Allow Snapshots as Volume-Chain, signalé comme fonction en avant-première.

En CLI :

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

# Côté Proxmox — ajouter le stockage NFS
pvesm add nfs nfs-partage \
  --server <adresse-du-serveur-nfs> \
  --export /srv/partage \
  --content iso,vztmpl,images

# Vérifier l'ajout
pvesm status

Résultat attendu d'exemple, où le partage portait l'ID nfs-tp :

nfs-tp            nfs     active         4046848          720896         3099648   17.81%

La colonne Status doit indiquer active. Un inactive signale un serveur injoignable ou un export refusé.

Le stockage NFS apparaît immédiatement dans Datacenter → Storage avec son point de montage local /mnt/pve/nfs-partage, que Proxmox choisit lui-même d'après l'identifiant du stockage.

5.2 Ajouter une cible iSCSI, puis LVM par-dessus

Une cible iSCSI expose un disque (un LUN) sur le réseau. On la déclare à Proxmox en deux temps : la cible elle-même, puis un groupe LVM posé sur son LUN. C'est le montage « LVM sur iSCSI » des clusters qui disposent déjà d'un SAN.

Datacenter → Storage → Add → iSCSI

La fenêtre Add: iSCSI, au moment précis où la découverte a réussi.

• Le champ Target est une liste déroulante, pas un champ libre. Dès que le portail est saisi, Proxmox interroge la cible et affiche les IQN (iSCSI Qualified Name, nom unique d'une cible) qu'elle propose — ici iqn.2026-09.fr.dawan:lab.

  Si cette liste reste vide, inutile de continuer : soit la cible ne répond pas sur le port 3260, soit elle refuse votre nœud. C'est votre meilleur test de connectivité, et il ne coûte rien.

• Use LUNs directly est cochée par défaut. C'est le réglage à interroger : coché, le LUN entier ira à une seule VM ; décoché, il servira de socle à un groupe LVM. Voir l'encadré plus bas.

• Il n'y a pas de champ Content, contrairement au dialogue NFS : un LUN iSCSI n'accepte que des images disque, la question ne se pose pas.
• Regardez la liste derrière la fenêtre. local et local-lvm affichent Shared: No. Une fois ajouté, iscsi-lab y apparaîtra en Shared: Yes — la nature du protocole, pas un réglage.

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

# déclarer la cible iSCSI comme stockage
pvesm add iscsi iscsi-lab \
  --portal <ip-de-la-cible-iscsi> \
  --target iqn.2026-09.fr.dawan:lab \
  --content images

pvesm status   # le nouveau stockage doit être actif

Résultat attendu :

root@pxe211:~# pvesm add iscsi iscsi-lab --portal 10.44.1.98 --target iqn.2026-09.fr.dawan:lab --content images
root@pxe211:~# pvesm status
Name             Type     Status           Total            Used       Available        %
iscsi-lab       iscsi     active               0               0               0    0.00%
local             dir     active        98559220        22417684        71095996   22.75%

root@pxe211:~# lsblk | grep sde
sde    8:64   0    10G  0 disk

En l'état, ce stockage est peu utilisable : Proxmox y placerait les disques de VM en accès direct au LUN, sans gestion de l'espace ni snapshots. C'est la raison d'être de l'étape suivante — poser LVM par-dessus, ce qui rend le LUN partageable entre nœuds et lui donne une vraie gestion des volumes.

Le stockage apparaît avec Shared: Yes, alors que local et local-lvm sont à No. Ce n'est pas un réglage : c'est la nature du protocole. Un LUN iSCSI est joignable par tous les nœuds qui connaissent son portail.

C'est ce qui en fait un stockage de cluster. C'est aussi ce qui le rend dangereux sans une couche de coordination au-dessus.

L'empilement LVM :

Datacenter → Storage → Add → LVM

La fenêtre Add: LVM, telle qu'elle s'ouvre — et telle qu'il ne faut pas la laisser.

• Base storage vaut Existing volume groups par défaut. C'est le piège : tant que ce champ n'est pas changé, Volume group ne propose que les VG déjà présents sur le disque local (ici pve), et le LUN iSCSI reste invisible. Changez ce champ en premier, avant tout le reste.
• Content vaut Disk image, Container. Sur un LUN partagé de cluster, on laisse les deux : les disques de VM comme les rootfs de conteneurs pourront y vivre.
• Shared n'est pas cochée par défaut. Sur un stockage bâti sur iSCSI, il faut la cocher. C'est elle qui dit à Proxmox que tous les nœuds voient le même espace, et qui autorise la migration à chaud sans copier les disques.
• Wipe Removed Volumes reste décochée. Cochée, elle écrase chaque volume supprimé — sécurisant, mais chaque suppression de VM prend alors plusieurs minutes.

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

# Le meme resultat en ligne de commande, en trois temps :
# le LUN devient un volume physique, puis un groupe de volumes,
# et c'est ce groupe qu'on declare comme stockage Proxmox.
pvcreate /dev/sde
vgcreate vgiscsi /dev/sde   # puis un groupe de volumes
pvesm add lvm lvm-sur-iscsi --vgname vgiscsi --content images --shared 1   # déclaré comme stockage partagé

Résultat attendu :

root@pxe211:~# pvcreate /dev/sde
  Physical volume "/dev/sde" successfully created.
root@pxe211:~# vgcreate vgiscsi /dev/sde
  Volume group "vgiscsi" successfully created
root@pxe211:~# pvesm add lvm lvm-sur-iscsi --vgname vgiscsi --content images --shared 1
root@pxe211:~# pvesm status | grep lvm-sur-iscsi
lvm-sur-iscsi     lvm     active        10481664               0        10481664    0.00%

Cette fois, les tailles sont renseignées : LVM apporte la couche qui manquait au LUN brut, et Proxmox sait enfin compter l'espace disponible.

Ces commandes ne s'exécutent qu'une fois, depuis un seul nœud. pvcreate et vgcreate écrivent sur le LUN lui-même : les autres nœuds voient le groupe de volumes sans rien refaire. Et pvesm add écrit dans /etc/pve/storage.cfg, commun à tout le cluster : le stockage est déclaré pour tous les nœuds d'un coup.

À retenir : un partage NFS se déclare par Datacenter → Storage → Add → NFS : il accepte ISO, modèles, sauvegardes et disques. Une cible iSCSI se déclare par Add → iSCSI, puis on pose LVM sur son LUN ; --shared 1 est indispensable dès que plusieurs nœuds le voient.

5.3 La conférence : Ceph, le stockage du futur

NFS et iSCSI supposent un serveur ou une baie de stockage, extérieurs aux nœuds. Ceph, le stockage distribué, s'en passe : cette conférence en explique le fonctionnement.

• 🎥 Ceph, le stockage du futur — Grégory Colpart, conférence du Capitole du Libre (2019, 1 h 10) : le fonctionnement interne de Ceph (OSD, groupes de placement, moniteurs). Elle montre aussi ses usages en virtualisation, dont Proxmox.

C'est une bonne introduction à la mise en cluster : elle fait comprendre comment plusieurs nœuds partagent un même stockage.