un jolie bug sur les distrib à base de RH6.x X86_64 concernant la détection de nouveau Lun sur le système link en FC

  • quelque soit le type de carte Emulex / QLA ... le Bug n'est pas lié aux modules (confirmer par l'arrêt/relance)
  • le bug n'est pas lié à udevd (arrêt/relance + debug-trace)
  • un scsi_rescan ne trouvera rien
  • un modprobe de toute la couche DM ne changera rien :(ici avec QLA)

    modprobe qla2xxx scsi_transport_fc  scsi_tgt dm_multipath dm_round_robin dm_mirror dm_multipath dm_mod

  • l'utilisation de dmsetup rien non plus : exemple où rien ne se passe !

    dmsetup create mpathl -v -u mpath-360a980006467467564346937484d3174

  • un arrêt relance du service multipath ne changera rien non plus, même avec l'ajout manuelle de l'id dans : /etc/multipath.conf ; /etc/multipath/wwids ; /etc/multipath/bindings
Au final, j'ai remonté chaque process au démarrage du système pour trouver la solution, et ce fût HALd le problème.
Normalement HAL est en écoute pour détecter tout nouveau D-bus périphérique, et bien apparemment, pour la couche FC il n'y arrive pas.

il suffit de relancer le service et cela fonctionne !

/etc/init.d/haldaemon restart

Une fois relancé, un nouveau device virtuel apparaît enfin dans /dev/mapper/mpath*  ( cf : ci-dessus mpathl )

Cette technique permet d'éviter le reboot système pour la détection de nouveaux Lun en FC !!!