После миграции между хостами в кластере Hyper-V на виртуальной машине HP 3PAR Virtual Service Processor 4.3.0 перестала работать сеть.

После одной из миграций (методом Live Migration) виртуальной машины HP 3PAR Virtual Service Processor (VSP) 4.3.0 между хостами кластера Hyper-V получил от SCOM оповещение о сетевой недоступности ОС внутри ВМ. После перезагрузки виртуальной машины, зайдя на консоль, обнаружил внимание на то, что интерфейсы поменяли своё название и настройки IP в системе не выполнены…

Оказалось что, в системе произошло переименование интерфейсов: интерфейс eth0 стал eth3 (интерфейс без подключения к сети на уровне настроек виртуальной машины), а интерфейс eth1 стал eth2 (основной интерфейс подключения к  локальной сети).

Понять то, где какой интерфейс в Linux можно сопоставив MAC-адреса из свойств виртуальной машины с выводом утилиты ifconfig.

Причиной такого поведения Linux-системы стало изменение MAC-адресов сетевых адаптеров виртуальной машины, которое произошло после миграции ВМ с одного хоста виртуализации на другой. Такое стало возможным из-за того, что в конфигурации по умолчанию ВМ VSP создается с двумя сетевыми адаптерами с Динамическим MAC-адресом. Стало очевидно, что при начальной настройке виртуальной машины VSP я совершенно напрасно не уделил внимания этому моменту. Чтобы исключить возникновение подобной ситуации в будущем, выключим виртуальную машину и в свойствах сетевых адаптеров настроим использование Статического MAC-адреса.

Теперь посмотрим, как можно исправить ситуацию сложившуюся внутри базовой ОС VSP без повторного развёртывания и инициализации виртуальной машины. Классический сценарий владения этой ВМ предусматривал бы под собой именно полное пересоздание и повторную настройку ВМ, так как в сложившейся ситуации доступа у ВМ к сети уже нет, а возможность воздействовать на базовую ОС внутри ВМ в конфигурации по умолчанию отсутствует. Однако ранее мы рассматривали процесс получения доступа к консоли ОС, и теперь нам эта возможность пригодится снова.

Итак, попав на консоль ОС с правами root и проведя ряд экспериментов, удалось выяснить необходимый ряд изменений в конфигурационных файлах для восстановления работоспособности сети с новыми именами сетевых интерфейсов (eth2 и eth3). Для начала откроем на редактирование ранее рассматриваемый файл настроек брандмауэра VSP:

# nano /etc/init.d/hq.firewall

Найдём в файле строки, в которых определяются переменные для сетевых интерфейсов (E0 и E1):

Изменим название интерфейсов на те, которые в данный момент определены в системе (eht2 и eth3):

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

Далее отредактируем файлы ifcfg-eth0 и ifcfg-eth1 в каталоге /etc/sysconfig/network-scripts/ заменив соответствующим образом значение переменных DEVICE 

# nano /etc/sysconfig/network-scripts/ifcfg-eth0

# nano /etc/sysconfig/network-scripts/ifcfg-eth1

Сохраним изменения в конфигурационных файлах и выполним перезагрузку системы, после чего её сетевая доступность должна возобновиться.

Чтобы убедиться в том, что VSP функционирует нормально, можем выполнить тесты сетевой конфигурации (пункты 6-8) в веб-интерфейсе SPOCC (меню SPmaint > 2. Network Configuration )

Если все тесты прошли успешно, то можно считать, что с поставленной задачей мы справились.

***

Однако уже проведя выше описанные изменения и проверив работоспособность сети я узнал, что есть ещё один вариант решения проблемы. И этот вариант в итоге показался мне наиболее правильным и простым. Суть его заключается в корректировке файла с названием *persistent-net.rules в каталоге /etc/udev/rules.d/

# ls -la /etc/udev/rules.d/*persistent-net.rules
-rw-r--r--. 1 root root 660 Dec 16 17:06 /etc/udev/rules.d/70-persistent-net.rules

Откроем файл на редактирование

# nano /etc/udev/rules.d/70-persistent-net.rules

Содержимое файла имеет примерно следующий вид:

# PCI device 0x1011:0x0009 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:5d:00:39:0f", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x1011:0x0009 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:5d:00:39:0e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x1011:0x0009 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:5d:00:5d:0f", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x1011:0x0009 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:5d:00:5d:0e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

Как видим, файл содержит информацию о прежних MAC-адресах и они привязаны к старым наименованиям интерфейсов. В строчках описывающих прежние интерфейсы eth0 и eth1 поменяем MAC-адреса на актуальные (из eth2 и eth3). А строчки описывающие интерфейсы eth2 и eth3 удалим. В итоге файл примет примерно следующий вид:

# PCI device 0x1011:0x0009 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:5d:00:5d:0f", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x1011:0x0009 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:5d:00:5d:0e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Сохраним изменения в файл и перезагрузим систему. Работоспособность сети VSP восстановлена и при этом используются интерфейсы с именами “по умолчанию”.

PS: Разумеется в целом вся описанная история по сути про то, как мы сначала создаём себе сложности, а потом их героически преодолеваем. Но возможно просто кому-то этот опыт окажется полезен.