Добрый день, после обновления VIOSа столкнулся с проблемой в проброске лунов с дискового хранилища в виос (в последствии в систему)
сервер находится в HACMP кластере по этому пока работает на резервной ноде, на боевой произошло следующее
показания VIOS боевой ноды

# fget_config -Adv

---dar0---

User array name = 'DS4700_2'
dac4 ACTIVE dac6 ACTIVE

Disk DAC LUN Logical Drive
hdisk4 dac6 0 TWCMS01_BOOT
hdisk5 dac6 1 ERP02_boot
hdisk6 dac6 2 ERP02_PG
hdisk7 dac6 3 ERP_HB
hdisk8 dac4 4 T24_HB
hdisk9 dac6 5 TWCMS_HB
hdisk10 dac4 6 TWO_HB

---dar1---

User array name = 'DS4700_1'
dac5 ACTIVE dac7 ACTIVE

Disk DAC LUN Logical Drive
hdisk11 dac7 0 T24_DATA
hdisk12 dac7 1 ERP_BIN
hdisk13 dac7 2 ERP_DATA
hdisk14 dac7 3 DI_LOCAL_01
hdisk15 dac7 4 DI_LOCAL_02
hdisk16 dac7 5 TWCMS_ORA_BIN
hdisk17 dac7 6 TWCMS_ORA_DATA
hdisk18 dac7 7 TWO_ORA_BIN
hdisk19 dac7 8 TWO_ORA_DATA

$ lspv
NAME PVID VG STATUS
hdisk0 00c0e9a42c7a581b rootvg active
hdisk1 00c0e9b48be8410b rootvg active
hdisk2 00c0e9a48be27f75 datavg active
hdisk3 00c0e9a42e464a2c datavg active
hdisk4 00c0e9a4334de73f None
hdisk5 00c0e9a4334f87e2 None
hdisk6 00c0e9a49dc60633 None
hdisk7 00c0e9945681a0bc None
hdisk8 00c0e9943c72680d None
hdisk9 00c0e9a45a743dc3 None
hdisk10 00c0e9945fbdadf6 None
hdisk11 00c0e9943c67cd57 None
hdisk12 00c0e994568bbb64 None
hdisk13 none None
hdisk14 none None
hdisk15 00c0e9a456855fde None
hdisk16 00c0e9a45a7b6e71 None
hdisk17 00c0e9a45a7c1022 None
hdisk18 00c0e9945fce5f06 None
hdisk19 00c0e9945fcc88b1 None

вобщем то вопрос куда делись диски hdisk13 и hdisk14
пробовал удалять все мапинги дисков в виртуальные разделы и удалять диски после чего cfgmgr но это не помогает, картина аналогичная, тоесть в позиции hdisk13 и hdisk14 стоит None

# lsattr -El hdisk13
PR_key_value none Persistant Reserve Key Value True
cache_method default Write Caching method False
ieee_volname 600A0B8000505F24000007CF4A9666AA IEEE Unique volume name False
lun_id 0x0002000000000000 Logical Unit Number False
max_transfer 0x100000 Maximum TRANSFER Size True
prefetch_mult 0 Multiple of blocks to prefetch on read False
pvid none Physical volume identifier False
q_type simple Queuing Type False
queue_depth 10 Queue Depth True
raid_level 0 RAID Level False
reassign_to 120 Reassign Timeout value True
reserve_policy single_path Reserve Policy True
rw_timeout 30 Read/Write Timeout value True
scsi_id 0x20700 SCSI ID False
size 2899838150 Size in Mbytes False
write_cache no Write Caching enabled False
#
# lsattr -El hdisk10
PR_key_value none Persistant Reserve Key Value True
cache_method default Write Caching method False
ieee_volname 600A0B8000505F0A000005504A8D5AF3 IEEE Unique volume name False
lun_id 0x0006000000000000 Logical Unit Number False
max_transfer 0x100000 Maximum TRANSFER Size True
prefetch_mult 0 Multiple of blocks to prefetch on read False
pvid 00c0e9945fbdadf60000000000000000 Physical volume identifier False
q_type simple Queuing Type False
queue_depth 10 Queue Depth True
raid_level 5 RAID Level False
reassign_to 120 Reassign Timeout value True
reserve_policy single_path Reserve Policy True
rw_timeout 30 Read/Write Timeout value True
scsi_id 0x20400 SCSI ID False
size 9 Size in Mbytes False
write_cache no Write Caching enabled False

вот еще что дает команда lsattr тоесть я явно вижу что почему то пропала строчка pvid как ее восстановить? (hdisk13 -- потеряшка, hdisk10 нормальный)

А не в reserve_policy дело?
Наверное надо в no_reserve ставить.

врядли, но попробую

# lsattr -El hdisk14
PR_key_value none Persistant Reserve Key Value True
cache_method default Write Caching method False
ieee_volname 600A0B8000505F24000007CF4A9666AA IEEE Unique volume name False
lun_id 0x0002000000000000 Logical Unit Number False
max_transfer 0x100000 Maximum TRANSFER Size True
prefetch_mult 0 Multiple of blocks to prefetch on read False
pvid 00c0e9945b64c14a0000000000000000 Physical volume identifier False
q_type simple Queuing Type False
queue_depth 32 Queue Depth True
raid_level 1 RAID Level False
reassign_to 120 Reassign Timeout value True
reserve_policy no_reserve Reserve Policy True
rw_timeout 30 Read/Write Timeout value True
scsi_id 0x20700 SCSI ID False
size 409599 Size in Mbytes False
write_cache yes Write Caching enabled False

вот такое стоит на той ноде где этот диск виден
тоесть политика резервирования на самом диске стоит правильная

а на другой стоит
reserve_policy single_path
?

нет, стоит именно no_reserve
14 -- это на резервной ноде
13 -- это на боевой

у Вас два VIOS'а на сервере или один?
LUN'ы Вы отдаете через оба VIOS'а или через один?

vios 1 штука на сервер
резервная и боевая -- это в понятиях HACMP
вопрос простой, как восстановить связку между
hdisk13 -- и LUN ERP_DATA на хранилище

в LPARы проброшены не виртуальные FC адаптеры а виртуальные диски (кстати возможно это одна из причин низкой скорости работы на i/o)
т.е.
к виосу подключены LUNы, которые мапируются в hdiskи которые в свою очередь через mkvdev мапируются через виртуальные scsi адаптеры пробрасываются в LPARы где тоже появляются соответсвующими volume grouppами, где собственно создаются разделы
пропала связка между LUN=ERP_DATA и hdiskX (в моем случае 13), что не дает пробросить этот раздел внутрь LPAR

не понимаю, что восстанавливать надо. есть один кластер, состоящий из двух AIX LPAR'ов. есть два VIOS'а (по одному на сервер). есть сторедж.
на сторедже нарезаны LUN'ы, они отдаются и мы их видим на VIOS'е (как минимум на одном из двух). до сих пор все хорошо.
если один LUN отдается на два VIOS'а сразу же, то у него по определению должна стоять policy no_reserve, после чего можно его маппировать. так что выставляйте no_reserve для всех hdisk'ов, которые должны быть одновременно видны на двух VIOS'ах, и маппируйте их на здоровье. и никакой проблемы, честно говоря, я пока что не заметил.

проблема в том что VIOS номер 2 не видет эти луны
на на VIOS номер 1, который видит луны, стоит правильная политика

значит, проблема зонинга или стореджа. проверяйте их.

вот с этого момента по подробнее
если не сложно то примерно на пальцах обЪясните и дайте ссылку на документацию
Спасибо
и еще один вопрос (хотя может стоит его вынести в отдельную тему)
сейчас настроенно
на хранилище лун AAA, хранилище подключено к серверу по файберу.
на сервере стоит VIOS в нем настроенно мапирование луна из хранилища в вирутальный SCSI адаптер в разделе
а если пробрасывать в раздел не LUN через виртуальный SCSI а виртуальный FC адаптер, будет ли такая схема быстрее?

Вообще-то я бы сначала проверил, нет ли каких ошибок на сториджах и SAN-свитчах, а потом...

У Вас диски в системе видны, но видны как новые, т. е. неиспользуемые.

Может попытаться сделать importvg?

как бы сказать, эти диски напрямую как vg внутри виоса не фигурируют они сразу пробрасываются через virtual scsi внутрь партиций
тоесть последовательность команд по мапированию примерно следующая

mkvdev -vdev hdisk4 -vadapter vhost0 -dev rootvg_part1
а внутри уже раздела
Это является Vg rootvg откуда грузится система