Proxmox iSCSI échec de connexion : cible joignable mais pas de LUN — comment réparer

Ce que signifie réellement « cible joignable mais pas de LUN »

iSCSI est en réalité deux problèmes distincts sous un même manteau :
le transport (puis-je atteindre le portail cible et m’authentifier ?) et la présentation (la cible me présente-t-elle réellement un périphérique bloc, c’est‑à‑dire un LUN ?).

« Cible joignable » signifie que la découverte fonctionne ou au moins que la connexion TCP vers 3260 fonctionne. Cela ne signifie pas que vous êtes autorisé à voir un LUN.
Cela veut souvent dire que vous avez réussi à parler au démon de la cible, mais celui‑ci a décidé — correctement ou non — que vous devez obtenir zéro périphérique.

La partie déroutante : initiateurs, cibles et interfaces utilisateur décriront tous « pas de LUN pour vous » de façons différentes :

• Connexion échoue : la cible rejette la session (mismatch CHAP, IQN non autorisé, mauvais groupe de portail, méthode d’authentification différente).
• Connexion réussie, pas de disque : la session est établie mais le masquage de LUN / ACL / mappage empêche l’exposition de tout LUN.
• Le disque apparaît puis disparaît : mauvaise configuration multipath, timeouts, path flapping, ou étrangetés ALUA/TPG.
• Stockage Proxmox « OK » mais rien d’utilisable : vous avez ajouté un stockage iSCSI sans la couche supérieure (LVM/LVM-thin/ZFS dessus), ou le LUN est en lecture seule.

Votre travail est de décider quelle couche vous raconte des mensonges. Ensuite, corrigez cette couche — pas toute la pile « au cas où ».

Feuille de route diagnostic rapide (faire en premier)

Si vous êtes de garde, vous voulez une méthode qui prouve la vérité en minutes, pas une quête spirituelle à travers des interfaces graphiques.
Voici la séquence qui trouve le goulot d’étranglement le plus vite.

1) Vérifier que la cible est réellement joignable sur la bonne IP et le bon port

Vérifiez que vous atteignez le portail prévu (VLAN correct, interface correcte, pas de NAT surprise), et que 3260 est ouvert.
Si cela échoue, rien d’autre n’a d’importance.

2) Découvrir les cibles depuis le nœud Proxmox avec iscsiadm

Si la découverte échoue, c’est DNS/routage/pare‑feu/configuration du portail. Si la découverte réussit, continuez.

3) Se connecter manuellement et vérifier les sessions

Si la connexion échoue : CHAP, ACL IQN, méthode d’authentification, ou groupe de portail incorrect.
Si la connexion réussit : inspectez si des périphériques SCSI ont été mappés.

4) Chercher les LUNs : scan SCSI + périphériques bloc

Si vous avez une session iSCSI mais pas de /dev/sdX (ou pas de périphérique multipath), la cible ne présente pas de LUN à cet initiateur.
C’est presque toujours du masquage de LUN, un mappage manquant ou une entrée ACL qui existe mais pointe vers le mauvais IQN d’initiateur.

5) Confirmer que Proxmox est configuré pour le bon type de stockage

Le stockage « iSCSI » dans Proxmox n’est pas là où vivent les disques VM à moins que vous utilisiez des LUNs directs. La plupart des déploiements associent iSCSI à LVM ou LVM-thin.
Ne « corrigez » pas iSCSI quand le vrai problème est que vous attendiez d’iSCSI qu’il se comporte comme du NFS.

6) Si multipath est impliqué, vérifiez‑le avant d’accuser l’appliance

Un LUN parfaitement mappé peut toujours disparaître derrière une configuration multipath cassée.
Confirmez que vous voyez des chemins stables et un périphérique mappé.

Faits intéressants (et un peu d’histoire) qui aident au debug

• iSCSI a été normalisé en 2004 (RFC 3720). C’est assez ancien pour expliquer pourquoi beaucoup de baies conservent des paramètres par défaut hérités.
• Découverte et connexion sont des étapes différentes : la découverte SendTargets peut fonctionner même lorsque la connexion est interdite par des ACL.
• Le masquage de LUN précède iSCSI : la même idée existait pour Fibre Channel. Votre problème de « pas de LUN » est classique, il porte juste de l’Ethernet.
• L’identité de l’initiateur est l’IQN (ou EUI). Les IP aident, mais les cibles autorisent typiquement par IQN parce que les IP mentent et DHCP est le chaos.
• CHAP est optionnel, et beaucoup d’environnements tournent encore sans — généralement parce que quelqu’un a décidé « on est sur un VLAN privé » puis a oublié de le garder privé.
• ALUA existe parce que les contrôleurs de stockage sont politiques : certains chemins sont « optimisés » et d’autres « non optimisés », et multipath a besoin d’indices pour éviter les chemins lents.
• Le port iSCSI par défaut est 3260, mais certaines appliances supportent plusieurs portails et binding de port ; vous pouvez être « joignable » sur un portail mais mappé sur un autre.
• Linux open-iscsi stocke des enregistrements node sous /etc/iscsi/. Cette persistance est pratique jusqu’à ce qu’elle ne le soit plus — des enregistrements obsolètes causent des incidents très modernes.
• Proxmox ne crée pas magiquement un système de fichiers sur un LUN iSCSI. Il se connectera volontiers et vous laissera avec un glorieux « et maintenant ? ».

Modèle mental : portails, cibles, sessions, LUNs, ACLs

En dépannage, utilisez un vocabulaire strict. Cela évite les conversations « on a réparé » où personne n’est d’accord sur ce que « ça » était.

Portail

Un portail est une paire IP:port à laquelle vous vous connectez, typiquement TCP 3260. Les baies peuvent exposer plusieurs portails (par contrôleur, par VLAN, par interface).
« Cible joignable » signifie souvent « portail joignable ».

IQN de la cible

La cible est l’entité à laquelle vous vous connectez, identifiée par un IQN comme iqn.2020-01.example:storage.lun01.
Une cible peut exposer plusieurs LUNs — ou aucun — selon le mappage.

IQN de l’initiateur

Votre nœud Proxmox (l’initiateur) a aussi un IQN, trouvé dans /etc/iscsi/initiatorname.iscsi.
Les cibles utilisent couramment cet IQN dans les listes de contrôle d’accès (ACL). Si l’IQN ne correspond pas exactement, vous êtes un inconnu.

Session vs LUN

Une session est une connexion loguée. Un LUN est une unité logique SCSI présentée via cette session.
Vous pouvez avoir une session avec zéro LUNs. Ce n’est pas un « réseau cassé » ; c’est un « mappage cassé ».

CHAP et ACLs : deux verrous, deux clés

CHAP répond à « qui êtes‑vous ? » Les ACL répondent à « êtes‑vous autorisé à voir ce LUN ? ». Vous pouvez passer l’un et échouer l’autre.
Certaines cibles ont aussi des paramètres d’authentification par portail — parce qu’un verrou n’a jamais été suffisant.

Couches de stockage Proxmox

Proxmox peut :

• Utiliser iSCSI comme transport pour LVM ou LVM-thin (le plus courant).
• Utiliser iSCSI pour l’attribution directe de LUNs aux VM (moins courant, plus fragile).
• Combiner iSCSI avec multipath (courant en environnements sérieux).

Si vous attendez d’une cible iSCSI qu’elle ressemble à du NFS « un endroit pour déposer des fichiers », vous poursuivrez la mauvaise piste pendant des heures.

Tâches pratiques : commandes, sorties et décisions (12+)

Ci‑dessous des vérifications concrètes à exécuter sur un nœud Proxmox. Chaque élément inclut : la commande, ce que signifie la sortie, et la décision à prendre ensuite.
Exécutez-les en root ou avec des privilèges équivalents.

Task 1: Confirm which initiator IQN Proxmox is using

cr0x@server:~$ cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1993-08.org.debian:01:9d3a3b21f9a7

Signification : Cet IQN est votre identité auprès de la cible. Si l’ACL de la cible est configurée pour un IQN différent (courant après clonage de nœuds),
vous vous connecterez peut‑être mais ne verrez aucun LUN, ou vous serez rejeté immédiatement.

Décision : Comparez cette chaîne exacte avec l’objet initiateur/hôte de la cible. Corrigez l’ACL de la cible ou changez l’IQN de l’initiateur intentionnellement (rare).

Task 2: Verify the iSCSI service is running

cr0x@server:~$ systemctl status iscsid --no-pager
● iscsid.service - Open-iSCSI
     Loaded: loaded (/lib/systemd/system/iscsid.service; enabled)
     Active: active (running) since Thu 2025-12-26 09:12:01 UTC; 1h 3min ago

Signification : Si iscsid n’est pas en cours, découverte/connexion peuvent se comporter de façon incohérente, surtout au démarrage automatique.

Décision : Si inactive/failed, consultez les logs et réparez le service avant de toucher à la configuration du stockage.

Task 3: Validate basic reachability to the correct portal IP

cr0x@server:~$ ping -c 2 10.10.20.50
PING 10.10.20.50 (10.10.20.50) 56(84) bytes of data.
64 bytes from 10.10.20.50: icmp_seq=1 ttl=64 time=0.410 ms
64 bytes from 10.10.20.50: icmp_seq=2 ttl=64 time=0.392 ms

--- 10.10.20.50 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Signification : ICMP fonctionne. Ce n’est pas la preuve d’un succès iSCSI, mais cela élimine le problème réseau le plus basique.

Décision : Si le ping échoue, corrigez routage/VLAN/MTU/pare‑feu avant toute autre chose.

Task 4: Confirm TCP/3260 is reachable

cr0x@server:~$ nc -vz 10.10.20.50 3260
Connection to 10.10.20.50 3260 port [tcp/iscsi-target] succeeded!

Signification : Le portail est joignable au niveau transport.

Décision : Si cela échoue, vérifiez les règles de pare‑feu, les IP d’écoute côté stockage, et si vous atteignez le mauvais VLAN/interface.

Task 5: Run discovery from the initiator

cr0x@server:~$ iscsiadm -m discovery -t sendtargets -p 10.10.20.50
10.10.20.50:3260,1 iqn.2023-10.lab:truenas.target01

Signification : La cible répond à la découverte et annonce un IQN de target.

Décision : Si la découverte ne retourne rien, corrigez la configuration du portail/de la découverte. Si elle retourne une cible, passez à la connexion.

Task 6: Attempt a manual login and see the real error

cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --login
Logging in to [iface: default, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260]
Login to [iface: default, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260] successful.

Signification : Session établie. Parfait. Maintenant vérifiez si des LUNs apparaissent.

Décision : Si vous obtenez « authorization failure » ou « login failed », passez aux vérifications CHAP/IQN ACL.

Task 7: List iSCSI sessions (do you actually have one?)

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.20.50:3260,1 iqn.2023-10.lab:truenas.target01 (non-flash)

Signification : Si ceci est vide, vous n’êtes pas connecté. S’il est présent, le problème « pas de LUN » est probablement dû au mappage/ACL.

Décision : Avec une session présente, arrêtez de bidouiller les règles de pare‑feu et commencez à vérifier la présentation des LUNs.

Task 8: Check kernel messages for SCSI discovery results

cr0x@server:~$ dmesg -T | tail -n 25
[Thu Dec 26 10:18:44 2025] scsi host12: iSCSI Initiator over TCP/IP
[Thu Dec 26 10:18:44 2025] scsi 12:0:0:0: Direct-Access     LIO-ORG  lun01            4.0  PQ: 0 ANSI: 5
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: Attached scsi generic sg3 type 0
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: [sdc] 209715200 512-byte logical blocks: (107 GB/100 GiB)
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: [sdc] Write Protect is off
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: [sdc] Mode Sense: 43 00 00 00
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA

Signification : C’est le cas heureux : la cible a présenté un LUN et Linux a créé /dev/sdc.

Décision : Si vous voyez la session mais aucune ligne « Direct-Access », la cible présente zéro LUN. Corrigez le mappage/ACL côté cible.

Task 9: Enumerate block devices and confirm the iSCSI disk exists

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL,TRAN
NAME     SIZE TYPE MODEL            SERIAL               TRAN
sda     447.1G disk Samsung_SSD     S6Z2NX0R123456       sata
├─sda1      1G part                                   sata
└─sda2  446.1G part                                   sata
sdc       100G disk LIO-ORG_lun01    1234567890abcdef   iscsi

Signification : Un disque avec TRAN = iscsi existe. Si aucun n’apparaît, vous n’avez pas de LUN.

Décision : Si le disque existe mais que Proxmox ne peut pas l’utiliser, remontez la pile (multipath, LVM, configuration Proxmox storage).

Task 10: Verify SCSI path and LUN IDs

cr0x@server:~$ lsscsi -tv
[12:0:0:0] disk LIO-ORG  lun01 4.0 /dev/sdc
  state=running

Signification : Vous voyez le tuple host:bus:target:lun. Si vous voyez des hosts mais pas d’entrées LUN, encore : mappage.

Décision : Si le LUN existe mais a une taille incorrecte, arrêtez — quelqu’un a mappé le mauvais extent/volume.

Task 11: Check open-iscsi node records (stale config bites)

cr0x@server:~$ iscsiadm -m node
iqn.2023-10.lab:truenas.target01 10.10.20.50:3260,1 default

Signification : Les enregistrements node sont persistants. Si vous avez changé les identifiants CHAP sur la cible mais pas ici, la connexion échouera de façon persistante.

Décision : Si l’enregistrement pointe vers d’anciens portails ou une mauvaise iface, mettez à jour ou supprimez l’enregistrement node et redécouvrez.

Task 12: Inspect CHAP settings for a node

cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 -o show | egrep 'auth|username|password'
node.session.auth.authmethod = CHAP
node.session.auth.username = proxmox01
node.session.auth.password = ********

Signification : La méthode d’auth et le nom d’utilisateur sont définis. Si la cible attend « None » et que vous forcez CHAP, la connexion échoue. Si les mots de passe diffèrent, la connexion échoue.

Décision : Alignez la config de l’initiateur avec la cible. Ne « testez pas des combinaisons au hasard » ; traitez cela comme des clés SSH, pas comme un distributeur automatique.

Task 13: Fix CHAP values (and know you changed them)

cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --op=update -n node.session.auth.authmethod -v CHAP
cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --op=update -n node.session.auth.username -v proxmox01
cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --op=update -n node.session.auth.password -v 'CorrectHorseBatteryStaple'

Signification : Vous avez mis à jour l’enregistrement node persistant.

Décision : Reconnectez et vérifiez sessions et LUNs. Si toujours pas de LUN, le coupable est le mappage/ACL, pas CHAP.

Task 14: Log out and log back in (clean state)

cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --logout
Logging out of session [sid: 1, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260]
Logout of [sid: 1, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260] successful.
cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --login
Logging in to [iface: default, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260]
Login to [iface: default, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260] successful.

Signification : Vous forcez une nouvelle négociation et un nouveau rescan.

Décision : Si la session monte mais que le LUN est toujours absent, arrêtez de toucher aux paramètres de l’initiateur et corrigez le mappage côté cible.

Task 15: If multipath is expected, confirm it’s not the reason your LUN “disappeared”

cr0x@server:~$ systemctl status multipathd --no-pager
● multipathd.service - Device-Mapper Multipath Device Controller
     Loaded: loaded (/lib/systemd/system/multipathd.service; enabled)
     Active: active (running) since Thu 2025-12-26 09:20:10 UTC; 55min ago

Signification : Le démon multipath tourne.

Décision : S’il ne tourne pas mais que vous avez plusieurs portails, vous pouvez obtenir des périphériques dupliqués ou du path flapping ; réparez multipath avant de mettre LVM dessus.

Task 16: Inspect multipath mapping

cr0x@server:~$ multipath -ll
mpatha (36001405f2a3b4c5d6e7f890123456789) dm-3 LIO-ORG,lun01
size=100G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 12:0:0:0 sdc 8:32 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 13:0:0:0 sdd 8:48 active ready running

Signification : Vous avez un périphérique multipath unique (/dev/mapper/mpatha) couvert par deux chemins. C’est ce que vous voulez.

Décision : Utilisez le périphérique multipath pour LVM/LVM-thin ; évitez d’utiliser /dev/sdc directement ou vous créerez un futur incident créatif.

Task 17: Check for duplicate SCSI devices when multipath is not configured

cr0x@server:~$ ls -l /dev/disk/by-path/ | egrep 'iscsi|ip-10.10.20'
lrwxrwxrwx 1 root root  9 Dec 26 10:19 ip-10.10.20.50:3260-iscsi-iqn.2023-10.lab:truenas.target01-lun-0 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 10:19 ip-10.10.20.51:3260-iscsi-iqn.2023-10.lab:truenas.target01-lun-0 -> ../../sdd

Signification : Deux portails, deux périphériques /dev/sdX. Sans multipath, ce sont deux disques indépendants pour Linux, même s’il s’agit du même LUN.

Décision : Activez et configurez multipath avant de créer LVM ou systèmes de fichiers, sinon vous risquez une corruption enthousiaste.

Task 18: Check Proxmox storage configuration references

cr0x@server:~$ grep -nE 'iscsi|lvm|lun|portal|target' /etc/pve/storage.cfg
12:iscsi: iscsi-san
13:        portal 10.10.20.50
14:        target iqn.2023-10.lab:truenas.target01
15:lvmthin: vmdata
16:        vgname vg_iscsi_vmdata
17:        thinpool data
18:        content images,rootdir

Signification : Proxmox sépare le transport iSCSI (la section « iscsi ») de l’espace de stockage réel (LVM-thin sur un VG).

Décision : Si vous n’avez que la section iSCSI mais pas la couche LVM/LVM-thin/ZFS, la configuration est incomplète, pas un bug de connexion.

Task 19: Confirm a volume group exists on the iSCSI/multipath device (if using LVM)

cr0x@server:~$ pvs
PV                  VG              Fmt  Attr PSize   PFree
/dev/mapper/mpatha  vg_iscsi_vmdata lvm2 a--  100.00g 20.00g

Signification : LVM voit le disque et l’utilise comme PV, ce qui implique que le LUN est visible et stable.

Décision : Si pvs n’affiche rien, vous n’avez soit pas de LUN, soit pas de périphérique multipath, soit vous ne l’avez pas initialisé. Choisissez la bonne correction.

Task 20: Look at iSCSI logs for the real rejection reason

cr0x@server:~$ journalctl -u iscsid -n 80 --no-pager
Dec 26 10:05:11 server iscsid[1243]: iSCSI daemon started
Dec 26 10:06:02 server iscsid[1243]: connection1:0 login rejected: Initiator failed authentication with target
Dec 26 10:06:02 server iscsid[1243]: connection1:0 login failed to authenticate with target iqn.2023-10.lab:truenas.target01

Signification : Échec d’authentification. C’est CHAP ou un mismatch de mode d’authentification côté cible, pas « pas de mapping de LUN ».

Décision : Corrigez d’abord les identifiants CHAP et la méthode d’authentification ; ensuite seulement occupez‑vous du mappage de LUN.

Spécificités Proxmox : iSCSI vs LVM sur iSCSI (et où les gens se perdent)

Proxmox vous donne assez de corde pour construire un stockage solide — ou pour créer un incident noueux et chronophage.
L’UI Proxmox facilite l’ajout d’un « iSCSI » et vous fait croire que c’est fini. Ce n’est pas le cas, sauf si vous faites exprès des LUNs bruts par VM.

Pattern A (courant) : iSCSI + LVM-thin

Vous connectez l’hôte à un LUN, puis construisez un VG LVM et un thin pool par dessus. Proxmox stocke les disques VM comme des volumes logiques.
C’est la voie que la plupart des personnes empruntent car elle est efficace, supportée et relativement prévisible.

Si vous voyez « cible joignable mais pas de LUN », vous êtes bloqué tout en bas : Proxmox ne voit même pas le périphérique bloc pour créer le PV.

Pattern B (moins courant) : LUN direct par VM

Vous présentez plusieurs LUNs et les mappez directement, souvent pour des appliances bases de données ou si vous voulez des snapshots/réplications natives de la baie.
Cela exige un mappage et un nommage disciplinés, sinon vous attacherez le mauvais LUN au mauvais VM et passerez un mauvais après‑midi.

Angle cluster Proxmox : chaque nœud doit être autorisé

Si vous êtes en cluster et que vous voulez que n’importe quel nœud puisse exécuter la VM, chaque nœud doit voir le même stockage de backing.
« Ça marche sur node1 » est un piège. Cela signifie seulement que l’IQN de node1 est dans l’ACL de la cible.

Blague #1 : iSCSI, c’est comme la sécurité de bureau — votre badge marche parfaitement jusqu’au jour où il ne marche plus, et alors c’est soudainement votre problème.

Où ça casse : causes réelles derrière « login failed » et « pas de LUN »

1) Mauvais IQN d’initiateur (ou nœuds clonés avec IQN identiques)

Les nœuds Proxmox construits à partir de templates héritent souvent du même InitiatorName. Les cibles voient deux hôtes revendiquant la même identité.
Au mieux, un seul fonctionne et l’autre est expulsé. Au pire, ils se volent la session à tour de rôle et vous avez des timeouts intermittents.

Corrigez‑le en générant des IQN uniques par nœud et en mettant à jour les ACLs de la cible en conséquence. N’« autorisez pas tous les initiateurs » sauf si vous aimez expliquer vos choix après coup.

2) Mismatch CHAP ou CHAP requis d’un côté mais pas de l’autre

Les baies et stacks cibles diffèrent : certaines exigent CHAP par cible, d’autres par portail, d’autres par groupe d’initiateurs. Proxmox stocke CHAP dans l’enregistrement node.
Si quelqu’un fait tourner les identifiants sur la baie et oublie de mettre à jour Proxmox, l’échec est déterministe.

3) Le LUN existe mais n’est pas mappé à cet initiateur (classique)

L’administrateur a créé le volume/extent et même la cible IQN. Mais il n’a pas mappé le LUN au groupe d’initiateurs/hôte, ou l’a mappé au mauvais groupe.
La découverte voit la cible, la connexion peut réussir, et vous n’obtiendrez toujours aucun périphérique.

C’est la cause numéro un de « cible joignable mais pas de LUN ». C’est aussi la plus facile à corriger, ce qui la rend d’autant plus irritante.

4) Mismatch de groupe de portail / liaison réseau

Beaucoup de baies ont plusieurs groupes de portails. Vous pouvez vous connecter à 10.10.20.50 mais le mappage de LUN s’applique au groupe de portail sur 10.10.30.50.
Ou la cible est liée à une interface tandis que la découverte touche un autre IP de service qui ne sert pas cette target.

5) Étrangetés ALUA/multipath qui ressemblent à « pas de LUN »

Si multipath est partiellement configuré, vous pouvez voir les périphériques brièvement puis les perdre. Proxmox peut afficher le stockage comme dégradé ou disparu.
Ce n’est pas « pas de LUN », mais c’est souvent mal diagnostiqué comme tel.

6) Enregistrements initiateur obsolètes pointant vers une ancienne config cible

Si vous avez changé les IQN de cible, les portails ou les exigences d’auth, open-iscsi peut continuer d’essayer les anciens paramètres.
Supprimer et redécouvrir les enregistrements node est parfois la solution la plus propre — faites‑le prudemment, en fenêtre de maintenance, et en tenant compte des VM qui utilisent le LUN.

7) Proxmox attend LVM-thin mais vous avez présenté un LUN avec un système de fichiers existant

Vous pouvez présenter un LUN qui contient déjà quelque chose (métadonnées LVM anciennes, partitions résiduelles). Proxmox peut refuser d’initialiser, ou pire, vous initialisez le mauvais disque.
Si vous migrez, soyez explicite sur le plan : importer vs réinitialiser.

Citation (idée paraphrasée) de Werner Vogels (Amazon) : « Everything fails all the time; design and operate with that assumption. » — idée paraphrasée de Werner Vogels

Erreurs courantes : symptôme → cause → correctif

Symptôme : la découverte fonctionne, la connexion échoue avec « authorization failure »

Cause : Mismatch CHAP ou la cible exige CHAP alors que l’initiateur est réglé sur None (ou inversement).

Correctif : Alignez la méthode d’authentification et les identifiants des deux côtés. Vérifiez avec journalctl -u iscsid et iscsiadm -m node -o show.

Symptôme : connexion réussie, iscsiadm -m session montre une session, mais lsblk n’affiche aucun disque iSCSI

Cause : Aucun LUN mappé à cet IQN d’initiateur, ou le masquage de LUN le refuse.

Correctif : Sur la cible, mappez le LUN/extent au groupe d’initiateurs correct qui inclut votre IQN Proxmox. Assurez‑vous que l’ID LUN est activé. Puis rescan/relogin.

Symptôme : fonctionne sur un nœud Proxmox, échoue sur un autre du même cluster

Cause : L’ACL de la cible inclut un seul IQN d’initiateur. Ou les nœuds partagent le même IQN suite à un clonage.

Correctif : Donnez à chaque nœud un IQN unique et ajoutez tous les nœuds au groupe d’initiateurs de la cible. Validez les sessions depuis chaque nœud.

Symptôme : deux disques apparaissent pour le même LUN (/dev/sdc et /dev/sdd), Proxmox est confus

Cause : Deux portails sans multipath ; Linux voit deux périphériques SCSI indépendants.

Correctif : Configurez correctement multipath et utilisez les périphériques /dev/mapper/mpathX pour LVM. Blacklistez le disque de boot local.

Symptôme : le LUN apparaît, puis disparaît après quelques minutes ou sous charge

Cause : Mismatch MTU/jumbo frames, path flapping, ou paramètres de timeout trop agressifs.

Correctif : Validez l’MTU bout‑à‑bout, vérifiez les compteurs des switches, et revoyez les timeouts iSCSI. Stabilisez le réseau avant d’optimiser les performances.

Symptôme : l’UI Proxmox affiche iSCSI « OK », mais vous ne pouvez pas créer d’images VM là‑dessus

Cause : Vous avez ajouté le transport iSCSI mais pas créé le LVM/LVM-thin dessus (ou vous n’avez mappé aucun LUN).

Correctif : Assurez‑vous que le LUN iSCSI existe comme périphérique bloc, puis créez un PV, VG et thin pool et ajoutez‑le en tant que LVM-thin dans Proxmox.

Symptôme : la connexion échoue seulement après un reboot

Cause : Problèmes d’ordre de démarrage, binding sur mauvaise interface réseau, ou mauvais réglage node.startup pour iSCSI.

Correctif : Assurez‑vous que le réseau est opérationnel avant le login iSCSI, et définissez le démarrage node en automatique si approprié. Confirmez avec les logs systemd.

Symptôme : vous voyez le LUN, mais il est en lecture seule

Cause : Mappage en lecture seule côté cible, export snapshot/clone, ou conflits de réservation SCSI.

Correctif : Corrigez le mode de mappage sur la baie ; vérifiez les réservations persistantes si du clustering est impliqué.

Trois mini‑histoires d’entreprise

Incident causé par une mauvaise hypothèse : « la découverte signifie que c’est mappé »

Une entreprise de taille moyenne a migré de NFS vers iSCSI pour « de meilleures performances » (ce qui était vrai, mais incomplet). L’admin stockage a créé une cible,
l’a présentée sur le bon VLAN, et a transmis l’IQN à l’équipe virtualisation. Ils l’ont ajouté dans Proxmox et ont vu la cible en découverte.
Tout le monde s’est détendu. Naturellement, la maintenance s’est transformée en heures sup.

Les nœuds Proxmox pouvaient se connecter, mais aucun LUN n’est jamais apparu. L’équipe virtualisation a supposé un bug d’initiateur parce que « nous pouvons atteindre la cible ».
Ils ont passé une heure à basculer les réglages CHAP, redémarrer des services, et réajouter le stockage dans l’UI, l’équivalent opérationnel de secouer une imprimante.

Le vrai problème : le LUN existait, mais il était mappé à un groupe d’initiateurs contenant l’IQN d’un ancien hôte ESXi d’un cluster retiré.
La découverte renvoyait encore la cible parce que la découverte était ouverte. La connexion fonctionnait parce que CHAP était désactivé. Mais le masquage de LUN a fait son travail et n’a rien montré.

La correction a pris deux minutes : ajouter les IQNs d’initiateur corrects au mappage et rescanner. La leçon a duré plus longtemps :
ne pas utiliser le succès de la découverte comme preuve d’un stockage utilisable. Traitez‑le comme le DNS : utile, pas autoritatif.

Optimisation qui a mal tourné : jumbo frames sans patience

Une autre équipe avait iSCSI fonctionnel, mais voulait moins de CPU et plus de débit. Quelqu’un a activé MTU 9000 sur les NICs stockage et Proxmox.
Ils n’ont pas touché aux switches car ils étaient « déjà configurés pour jumbo quelque part ». Ce « quelque part » était un autre jeu de ports.

Le résultat n’a pas été une panne immédiate. C’est le pire cas. La découverte fonctionnait. La connexion fonctionnait. Les LUNs apparaissaient.
Sous charge — sauvegardes VM, scrubs disque, ou base de données active — les chemins ont commencé à tomber. Multipath basculait, revenait, puis marquait des chemins morts.
Les VM se figeaient comme si c’étaient des bugs invités.

L’équipe a couru après des fantômes : versions du kernel Proxmox, réglages multipath, « peut‑être la baie est saturée ». Pendant ce temps, les compteurs réseau disaient la vérité ennuyeuse :
fragmentation, pertes, et mise en boucle intermittente de gros paquets. iSCSI est sensible à la perte et aux pics de latence ; c’est du I/O bloc, pas une simple copie de fichiers.

La correction fut peu glamour : appliquer un MTU cohérent bout‑à‑bout, ou revenir à MTU 1500 partout. Ils ont choisi la seconde option pour la simplicité,
et la stabilité a permis de conserver des performances acceptables — parce que stable vaut mieux que théorique.

Pratique ennuyeuse mais correcte qui a sauvé la journée : groupes d’hôtes explicites et test pré‑vol

Une équipe plus disciplinée avait une règle : chaque nouveau nœud Proxmox doit passer un pré‑vol stockage avant de rejoindre le cluster.
Le pré‑vol incluait la vérification d’un IQN d’initiateur unique, sa présence dans le groupe d’initiateurs de la baie, et la connexion à tous les portails.
Ils exigeaient aussi un LUN de test qui pouvait être attaché et détaché sans risque.

Un jour, un nœud de remplacement est arrivé en urgence. Il était construit à partir d’une ancienne image. L’IQN iSCSI était dupliqué.
S’ils l’avaient ajouté directement au cluster, il aurait lutté avec le nœud existant pour les sessions et probablement causé des reset de chemins.

Le pré‑vol l’a détecté immédiatement. Ils ont régénéré l’IQN d’initiateur, mis à jour le mappage du groupe d’hôtes, puis rejoint le nœud.
Pas d’incident. Pas de drame. Le meilleur incident est celui pour lequel on ne vous réveille jamais.

Blague #2 : La seule chose plus persistante que les enregistrements node iSCSI est la personne qui insiste « ça marchait en labo ».

Listes de vérification / plan étape par étape

Étape par étape : réparer « cible joignable mais pas de LUN » (cas le plus courant)

1. Confirmer l’état de session :
   lancez iscsiadm -m session. Si aucune session, vous avez un problème de connexion ; passez aux étapes auth/ACL.
2. Confirmer l’IQN de l’initiateur :
   vérifiez /etc/iscsi/initiatorname.iscsi. Assurez‑vous qu’il correspond exactement à l’ACL cible.
3. Vérifier la présence des périphériques LUN :
   lancez lsblk -o NAME,TRAN,MODEL,SIZE et dmesg -T. Si aucun disque iSCSI, vous avez un problème de mappage.
4. Corriger le mappage côté cible :
   mappez le LUN/extent au groupe d’initiateurs qui contient vos IQNs Proxmox. Assurez‑vous que l’ID LUN est activé et non filtré.
5. Re-login ou rescan :
   logout/login avec iscsiadm. Confirmez que le périphérique bloc apparaît.
6. Ce n’est qu’après que la couche bloc existe que vous configurez Proxmox :
   créez PV/VG/thinpool si vous utilisez LVM-thin, puis ajoutez LVM-thin dans Proxmox.

Étape par étape : réparer « login failed » (classe auth/ACL)

1. Confirmer la portée TCP : nc -vz <portal> 3260.
2. Confirmer la découverte : iscsiadm -m discovery -t sendtargets -p <portal>.
3. Lire les logs du démon : journalctl -u iscsid -n 100 et capturez la raison exacte.
4. Vérifier la config CHAP : iscsiadm -m node -o show et alignez avec la cible.
5. Vérifier que l’IQN d’initiateur est autorisé : contrôlez l’ACL/groupe d’hôtes de la cible. Ne comptez pas sur des règles basées sur l’IP sauf si vous aimez l’ambiguïté.
6. Supprimer des entrées node obsolètes si nécessaire : supprimez seulement l’enregistrement node concerné, redécouvrez et reconfigurez l’auth.

Étape par étape : préparation d’un cluster Proxmox pour iSCSI

1. Chaque nœud a un IQN unique (vérifiez sur chaque nœud).
2. L’ACL cible inclut tous les IQNs de nœuds qui peuvent exécuter des VM.
3. Multipath est configuré si vous avez plusieurs portails/contrôleurs.
4. Utiliser un nommage de périphérique stable : préférez le WWID multipath ou les liens /dev/disk/by-id ; évitez les /dev/sdX bruts.
5. Tester le basculement : désactivez un chemin et confirmez que l’I/O continue (prudemment, avec un volume test sécurisé).

FAQ

1) Pourquoi puis‑je découvrir la cible mais ne pas voir de LUNs ?

Parce que la découverte indique simplement « quelles cibles existent ici ? ». La visibilité des LUNs est contrôlée par le mappage et les ACLs. La découverte peut être ouverte alors que les LUNs sont verrouillés.

2) Si la connexion réussit, cela ne prouve‑t‑il pas que le LUN est mappé ?

Non. La connexion prouve que vous avez établi une session. Le mappage des LUNs est une étape séparée. Une session sans LUNs est normale quand le masquage interdit l’accès.

3) Proxmox dit que le stockage iSCSI est en ligne, mais je ne peux pas y stocker d’images VM. Pourquoi ?

Le stockage iSCSI dans Proxmox est typiquement seulement la définition du transport. Vous devez généralement ajouter LVM ou LVM-thin par dessus pour stocker des disques VM.
Ajoutez la cible iSCSI, puis construisez un VG/thin pool et ajoutez une entrée LVM-thin.

4) Ai‑je besoin de multipath ?

Si vous avez plusieurs ports/contrôleurs et attendez de la redondance, oui. Sans multipath vous pouvez obtenir des périphériques dupliqués ou des pannes de chemin ressemblant à des problèmes disque aléatoires.
Si vous avez vraiment un seul portail et un seul chemin, multipath est optionnel mais courant dans des constructions standardisées.

5) Quelle est la façon la plus rapide de prouver qu’il s’agit d’un problème de mappage et non de Proxmox ?

Depuis le nœud : si iscsiadm -m session montre une session mais lsblk n’affiche aucun disque iSCSI et dmesg n’affiche pas d’attachement SCSI,
la cible ne vous présente aucun LUN. C’est du mappage/ACL.

6) Deux nœuds Proxmox peuvent‑ils partager le même IQN d’initiateur ?

Ne le faites pas. Certaines cibles tolèrent cela jusqu’au jour où elles ne le tolèrent plus. Vous aurez du vol de session, des réservations bizarres, et des resets de stockage intermittents.
Faites des IQNs uniques par nœud, toujours.

7) Dois‑je utiliser CHAP ?

Oui si vous le pouvez. Ce n’est pas une sécurité parfaite, mais cela évite les interférences accidentelles entre initiateurs et cibles sur des réseaux partagés.
Si vous sautez CHAP, compensez par une isolation VLAN stricte et une discipline d’ACL.

8) J’ai changé les identifiants CHAP sur la baie. Pourquoi Proxmox ne les a‑t‑ils pas pris ?

open-iscsi persiste les paramètres node. Vous devez mettre à jour l’enregistrement node (ou redécouvrir et reconfigurer).
Vérifiez avec iscsiadm -m node -o show.

9) Pourquoi je vois le LUN comme /dev/sdc à un boot et /dev/sdd à un autre ?

Linux assigne dynamiquement les noms /dev/sdX. Utilisez /dev/disk/by-id ou des périphériques multipath, pas les /dev/sdX bruts, dans toute configuration persistante.

10) Est‑ce que « pas de LUN » peut être causé par Proxmox lui‑même ?

Rarement. Proxmox utilise la pile iSCSI de Linux. Si Linux ne voit pas un LUN, Proxmox non plus. Concentrez‑vous sur la configuration initiateur/cible, pas sur l’UI.

Conclusion : prochaines étapes pour éviter la récurrence

Quand Proxmox indique « iSCSI login failed » ou que vous avez une cible joignable sans LUN, résistez à l’envie de paniquer.
Prouvez la couche qui échoue : transport, authentification ou présentation.

• Première étape : validez la joignabilité et la découverte (nc, iscsiadm -m discovery).
• Deuxième étape : validez la connexion et lisez l’erreur réelle (iscsiadm --login, journalctl -u iscsid).
• Troisième étape : validez la présentation du LUN (dmesg, lsblk, lsscsi).
• Puis : seulement après l’existence du périphérique bloc, construisez la couche stockage Proxmox (LVM/LVM-thin) et, si nécessaire, configurez multipath.

Opérationnellement, la meilleure correction est une politique : IQNs uniques par nœud, groupes d’initiateurs explicites côté cible, et un test pré‑vol avant tout ajout de nœud au cluster.
C’est ennuyeux. Ça marche. La production préfère ces deux qualités.