FC LUN подхватывается SES драйвером, а не sd_mod

Взгляни на /proc/scsi/scsi когда «всё становится нормально» - виден ли там SES-девайс наряду с диском?

Я это к чему - обычно должны быть видны оба девайса: и ses и sd.

И то, что ты видишь ses вместо sd, вовсе не значит, что ses подхватывает его вместо sd. Это просто значит, что ты не видишь sd. Например, потому, что не отресканил HBA. А после перезагрузки все ресканится и «всё становится нормально».

В первую очередь попробуй rescan (у тебя это может быть не host0, а host1 или host2):

echo "- - -" >  /sys/class/scsi_host/host0/scan

Во вторую очередь, почитай Host Attachment Guide у твоей СХД для твоей ОС.

Рескан не помогает. SES появляется именно вместо sd. Похоже, там что-то не то в inquiry в момент появления. Рядом SES нет, в системе есть две штуки, но они и по inquiry – enclosures. А эти – диски. Помогает, как оказалось, удалить их через scsi адреса и уже тогда пересканировать scsi host, тогда они появились нормально через sd. Без всяких ses. Остался вопрос, как это дело отлавливать, но это уже вторично…

Но ведь причина непонятна.

Это каждый раз такое происходит, когда отдается новый диск?

Или все-таки на хранилке выполнялись какие-то нетипичиные действия перед этим (например, отдали диск -> забрали -> отдали новый с тем же самым LUN ID...)?

Какой LUN ID был у этого девайса - 0? Что, если попробовать отдавать с другим LUN ID?

Что за хранилка, кстати?

Да там стало всё понятно, когда объяснили, – это NPIV, там устройство сперва на машину добавляется действительно как enclosure, потом на хранилке смотрится wwpn, мапится туда лун, и в этот момент он, по идее, по inquiry становится диском, только пересканирование не помогает, помогает передобавление. Возможно, поможет и посыл LIP плюс рескан, завтра попробую. Я с самого начала процесса не видел, ибо на удалёнке. Поэтому и выглядело загадочно. Хранилка HP MSA 2050.

Админы массива не могли по ошибке выдать диск как command device?

NPIV, там устройство сперва на машину добавляется действительно как enclosure, потом на хранилке смотрится wwpn, мапится туда лун, и в этот момент он, по идее, по inquiry становится диском

Не сталкивался вплотную, но насколько я знаю, NPIV - это немного другое. На стороне хоста на порт вешается дополнительный wwnn. Обычно это используется для виртуализации, когда нужо выпустить ВМ в san. Т.е. это работает на стороне хоста, а не массива. Массив тупо презентует порт этому виртуальному wwnn, как и любому другому потребителю

Скорее всё же админы массива где-то накосячили с презентацией

+1
NPIV или не NPIV - это не важно.
Скорее всего, storage-админы сначала сделали зоны, а только потом маппинг.
Если бы сделали в обратной последовательности, проблемы бы не было.
А так HBA залогинился на массив, нашел там только SES, и все. Убедить его в том, что там есть что-то еще, может релогин в фабрику (LIP или перезагрузка).

Скорее всего, storage-админы сначала сделали зоны, а только потом маппинг. Если бы сделали в обратной последовательности, проблемы бы не было

В смысле? Это нормальная работа

А так HBA залогинился на массив, нашел там только SES, и все.

Это не так работает. Чтобы хост увидел что-то с массива, ему нужно что-то презентовать с массива. Если хост должен видеть enclosure, хосту презентуется command device. Но это ни разу не обязательно

Даже если хосту не перезентован ни один LUN, он все равно может залогиниться (PLOGI) на массив. И он делает это, как только от свитча прилетает RSCN. А прилетает она тогда, когда хост добавляют в зону. Админы создают зону -> свитч посылает RSCN -> HBA логинится на порт массива -> не находит там ровном счетом ничего -> и все, больше он логиниться туда уже не будет. Даже если админы потом презентуют хосту диски на массиве. Чтобы заставить его перелогиниться, нужна перезагрузка/LIP/добавить-удалить-из-зоны.

Именно поэтому лучше сначала презентовать диски на массиве, а потом добавлять в зоны. Тогда новый хост увидит диски без проблем.

Это не для всех массивов так, кстати. Порты некоторых массивов сами делают FLOGI после того, как на них мапят луны, тем самым тригеря RSCN и заставляя HBA залогинится на них заново. Там такой пролемы нет. Но за это приходится платить тем, что отдача дисков там - disruptive operation. Т.е. ее нельзя делать на всех портах одновременно.

Command Device - это в хитачи, а в MSA нет command device. Там есть глобальная опция включить/выключить SES. ХЗ как это работает, но оскорее всего, либо дает возмножность использовать любой LUN в качестве command device, либо хосту подсовывается какой-то фиктивный LUN.