Всем доброго дня!

Есть сервер 570-MMA. На нем жила спокойно конфигурация с 2 VIOS, на которых был настроен SEA Failover и LPARы ходили через них в сеть.

Недавно в одном из VIOS сломался системный диск. Диск поменяли, VIOS поставили заново (бэкапа увы не было). Теперь восстанавливаю конфигурацию виртуальных ресурсов, в том числе и SEA.

В качестве физического адаптера, на котором создается SEA, используется LHEA.
После выполнения команды mkvdev -sea.... и создания этого злосчастного SEA с сетью начинают творится невообразимые вещи: пинги практически не идут ни до одной LPAR и даже связь с другими физическими серверами пропадает.

Если этот VIOS выключить, все становится на свои места.
Конфигурация обоих VIOS практически идиентична, и там и там используется LHEA. Профайл этого загадочного VIOS не менялся с тех пор, как вся конфигурация заработала. Да и при сравнении профайлов обоих VIOS не нашел каких-то критичных отличий.

Может, после создания SEA все LPAR пытаются через него ломиться в сеть, а на нем еще нету даже IP. Если причина в этом, то как тогда восстановить конфигурацию, не выключая LPAR?

А если не в этом, то в чем тогда?
Может, я забыл какую-то волшебную команду...

начем не с конца
IP-адрес на SEA не обязателен и даже наоборот - обычно не рекомендуется.
С LHEA есть веселые тонкости, советую обратить на них внимание:
а) в настройках LHEA должен быть выбран Promiscuous LPAR - Server -> Hardware -> Adapters -> Host Ethernet -> Configure -> Promiscuous LPAR - ваш VIOS
б) порт, отданный VIOS'у должен использоваться только VIOS'ом
А вот для дальнейшего разговора потребуется чуть больше информации.
С HMC:
lssyscfg -m SERVERNAME -r prof --filter "lpar_names=VIOS1"
lssyscfg -m SERVERNAME -r prof --filter "lpar_names=VIOS2"
с обеих VIOS'ов:
$ errlog - только события, относящиеся к SEA
$ lsdev -virtual
# lscfg -l ent*
для каждого SEA:
$ lsdev -dev entXX -attr

Promiscuous LPAR конечно же выбран соответствующий VIOS.
Как пишут в книжках это необходимое условие создания SEA на HEA.

А по поводу остальных команд...
Что именно вы там ожидаете увидеть? Дело в том, что доступ к серверу есть не всегда, поэтому если намекнете на что именно обратить внимание в выоде этих команд я непременно обращу.

Еще одна мысль:
В настройках Virtual Ethernet Adapter, который участвует в создании SEA есть параметр Trunk Priority. Написано, что при использовании SEA Failover у основного адаптера Trunk Priority должен быть ниже, чем у backup адаптера.
В моей ситуации именно у поломавшегося VIOS Trunk Priority 1, у поныне работающего 2.

Может именно в этом корень зла?

я ожидаю там увидеть ошибки в конфигурации. То, что у погибшего VIOS Trunk Priority меньше, для Вас хорошо - Вы из-за этого наступили на грабли и пытаетесь с ними разобраться. Если было бы наоборот - Вы бы никогда этих граблей не заметили, пока не попытались бы переключиться. То, что Вы описываете, с моей точки зрения является ошибкой в конфигурации VIOS'а, по крайней мере он так себя может вести при неправильной конфигурации. Какая конкретно ошибка - я не знаю, надо более внимательно смотреть, например, неправильный VLAN в Control Channel, или не тот ent определен как Control Channel, или не определен какой-то VLAN на одном из серверов, или определен неправильно. И вполне может быть, что приведенных команд окажется недостаточно.

Удалось выторговать небольшой простой для выяснения причин.

После того, как все LPARы положили, доконфигурировали ВИОС, т.е. прописали heart beat интерфейс для SEA, установили на SEA ip. Во время настройки второй виос работал как ни в чем не бывало.

Подняли LPARы и все нормально завелось. Сеть работает без сбоев и конфигурация отказоустойчивая - проверили.

Я все-таки склонен думать, что во время конфигурирования сломавшегося виоса лпары пытались сразу выходить в сеть через него (в соответствии с trunk priority), а поскольку он был еще не доделан то это вызывало странный эффект. Никаких других причин такого поведения я если честно не вижу...

andrewk, спасибо за ответы