Un petit pense-bête, façon « hints & tips » à l’anglaise, pour quand un host Linux ne voit pas (ou voit mal) les volumes d’une baie. Pas de grand discours : le symptôme, la commande, ce qu’il faut regarder. À garder dans un coin ^^ Valable pour Proxmox, RHEL (et dérivés), Ubuntu / Debian, etc.
Histoire de vous donner un peu de contexte, cet article fait suite à une session (c’est le cas de le dire ^^) de travail et de troubleshooting avec Cyrille, un ingénieur avant-vente de chez HPE concernant un souci de remontée de chemins entre les volumes d’une baie HPE et leurs hotes sur un cluster Proxmox.
Pour changer, plutôt que de vous faire le récit de cette opération, j’ai pris le parti de vous transformer ça en une boîte à outils virtuelle sur le iSCSI sous Linux, ça peut toujours servir !
Les paquets et services selon la distribution Linux
| Proxmox / Debian / Ubuntu | RHEL / Rocky / Alma | |
|---|---|---|
| Initiator iSCSI | open-iscsi | iscsi-initiator-utils |
| Multipath | multipath-tools | device-mapper-multipath |
| Outils SCSI | lsscsi, sg3-utils | lsscsi, sg3_utils |
| Test user-space | libiscsi-bin | libiscsi-utils |
| Services | iscsid, open-iscsi, multipathd | iscsid, iscsi, multipathd |
| Config multipath | /etc/multipath.conf | mpathconf --enable puis /etc/multipath.conf |
L’IQN de votre host est ici, et c’est lui que la baie doit connaître :
cat /etc/iscsi/initiatorname.iscsiAvant le SCSI : est-ce que le réseau fonctionne déjà ?
|
1 2 3 |
nc -zv <IP de la baie> 3260 ping -c3 <IP de la baie> ping -M do -s 8972 -c3 <IP de la baie> # test du MTU 9000 (jumbo frames) |
Si le port 3260 ne répond pas, inutile d’aller plus loin : le coupable est le pare-feu, le VLAN ou le routage (ou un souci de paramétrage sur le switch de raccordement, comme une inversion de VLAN, au hasard… oui oui, ça m’est arrivé). Si le ping classique passe mais pas celui avec -s 8972, vous avez un souci de MTU quelque part sur le chemin.
La baie est-elle visible ? (discovery)
|
1 2 |
iscsiadm -m discovery -t sendtargets -p <IP de la baie> iscsiadm -m node # ce qui est connu localement |
Le discovery liste des cibles et portails, jamais des volumes. Les LUN n’apparaissent qu’après login, et uniquement celles mappées à votre IQN.
Le login et les sessions
Pour rappel, une session iSCSI est la connexion logique et authentifiée avec l’initiator (le serveur, identifié par son IQN) ouvre vers une cible (la baie, identifiée par son IQN et un portail IP:3260) : c’est elle qui transporte les commandes SCSI sur TCP, et c’est seulement une fois ouverte que la baie présente au serveur les LUN qui lui sont mappées.
CHAP (Challenge-Handshake Authentication Protocol) est le mécanisme qui permet à la baie de vérifier, au moment du login iSCSI pour précisément établir la session, que le serveur connaît bien un secret partagé, sans jamais le faire circuler en clair sur le réseau (et ça peut être réciproque aussi en mode mutuel).
|
1 2 3 4 5 |
iscsiadm -m node -T <iqn> -p <IP> --login iscsiadm -m session # sessions actives iscsiadm -m session -P 1 # état de la connexion, iface utilisée iscsiadm -m session -P 3 # LUN et sdX attachés iscsiadm -m node -T <iqn> -p <IP> --logout |
Erreurs classiques du login :
- initiator reported error (24 …) : problème d’authentification (CHAP) ou IQN non autorisé côté baie
- initiator reported error (8 …) : timeout, retour à la section réseau
- initiator reported error (19 …) : échec de login non récupérable (la cible refuse, souvent un IQN non autorisé ou un CHAP erroné)
- initiator reported error (21 …) : aucun enregistrement trouvé, refaites un discovery
Je me connecte mais je ne vois aucun volume
Dans l’ordre de probabilité : l’IQN du host n’est pas déclaré (ou mal) côté baie ; le volume n’est pas mappé à ce host ; le scan est en manuel : iscsiadm -m node -T <iqn> -p <IP> -o show | grep scan ; il faut juste un rescan :
|
1 2 3 |
iscsiadm -m session --rescan rescan-scsi-bus.sh # sg3-utils for i in /sys/class/scsi_host/host*/scan; do echo "- - -" > $i; done # à la main |
Pour voir ce que la baie présente sans rien attacher, iscsi-ls interroge en user-space (aucun sdX créé) :
|
1 |
iscsi-ls -i iqn.2026-10.io.vblog:monsrv -s iscsi://<IP de la baie>:3260 |
Attention, sans le bon initiateur la baie vous voit comme un inconnu et répond zéro LUN.
Lire ce que le kernel voit
|
1 2 3 4 |
lsscsi -s -t # [H:C:T:L], taille, transport lsscsi -i # avec le WWID lsblk -o NAME,SIZE,TYPE,WWN,SERIAL,MOUNTPOINT /lib/udev/scsi_id -g -u -d /dev/sdb # WWID d'un disque |
Le dernier chiffre du [H:C:T:L] est le numéro de LUN présenté par la baie. Comparez-le avec la liste des volumes mappés côté baie : les numéros doivent être identiques.
Multipath : les chemins sont-ils tous là ?
|
1 2 3 |
multipath -ll # topologie complète multipathd show paths # état de chaque chemin multipathd show maps topology |
À regarder : le WWID (le WWN du volume précédé d’un 3 dans multipath, à rapprocher du volume côté baie) et la taille ; le nombre de sdX sous chaque map (4 chemins attendus, ou 8 ?) ; les états : active ready running c’est bon, failed faulty c’est un chemin mort.
Un volume absent de multipath -ll :
|
1 2 3 |
multipath -v3 # debug verbeux, cherchez "blacklisted" multipath -r # reload des maps multipathd reconfigure |
Les logs, toujours
|
1 2 3 4 |
dmesg -T | grep -Ei 'iscsi|scsi|sd[a-z]|multipath' | tail -50 journalctl -u iscsid -u multipathd --since "10 min ago" tail -f /var/log/messages # RHEL tail -f /var/log/syslog # Debian / Ubuntu |
Les messages connection1:0: detected conn error ou Path ... failed disent presque toujours où ça casse.
Petits pièges
- Proxmox : le stockage iSCSI de l’interface crée ses propres sessions. Si vous gérez iSCSI et multipath à la main, évitez de dupliquer la connexion des deux côtés.
- Sessions persistantes : pour qu’elles reviennent au reboot,
node.startup = automatic(dans/etc/iscsi/iscsid.confpour les cibles découvertes ensuite, ou pour une cible déjà connue :iscsiadm -m node -T <iqn> -p <IP> -o update -n node.startup -v automatic). - Multipath actif pendant vos tests : il peut créer des maps tout seul. Blacklistez ou stoppez
multipathdsi vous voulez zéro effet de bord. - Une LUN retirée côté baie sans nettoyage côté host laisse des
sdXfantômes : supprimez-les avececho 1 > /sys/block/sdX/device/delete(trouvé ce soir, alors qu’on avait terminé notre session de troubleshooting 🙁 🙁 ).
Au final
Ce petit Hints & Tips est juste un guide pour vous aider (et m’aider aussi 🙂 ) à débugger vos connexions iSCSI (pour nous, c’était entre des serveurs Proxmox au sein d’un cluster avec une baie HPE)… grand merci à Cyrille pour son aide jusqu’à plus d’heure …
N’hésitez pas à ajouter vos propres astuces en commentaire … bon, c’est pas tout ça mais il faut que je calfeutre un peu tout bicoz tempête à venir sur la Bretagne !
