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

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

image

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

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

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

image

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

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

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

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

image

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

image

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

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

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

image

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

image

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

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

image

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

***

Однако уже проведя выше описанные изменения и проверив работоспособность сети я узнал, что есть ещё один вариант решения проблемы. И этот вариант в итоге показался мне наиболее правильным и простым. Суть его заключается в корректировке файла с названием *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: Разумеется в целом вся описанная история по сути про то, как мы сначала создаём себе сложности, а потом их героически преодолеваем. Но возможно просто кому-то этот опыт окажется полезен.

Всего комментариев: 8 Комментировать

  1. Павел /

    Ну эта проблема скорее не Service Processor'a конкретно, а RedHat'а и производных от него ))

    1. Алексей Максимов / Автор записи

      Ну я и не говорил, что проблема в VSP. Проблема конкретно в том, что я не настроил в своё время статическое назначение MAC-адреса для виртуальной машины, что в последствии и привело к неработоспособности VSP, а рассуждать о проблемах RHEL я не возьмусь, так как уровень знания этой системы у меня очень поверхностный. Поэтому данный пост можно позиционировать лишь как предостережение тем, кто может оказаться в аналогичной ситуации, ну и как описание пары нехитрых вариантов исправления уже сложившейся проблемной ситуации с VSP.

      1. Баф /

        Алексей, а есть ещё идеи, где динамические MAC'и выстрелят подобным образом?

        Особенно, в Win среде?

        1. Алексей Максимов / Автор записи

          Само собой разумеется если виртуальная машина использует DHCP и уже тем более резервирование IP, то тут уж однозначно надо назначать статический MAC.

          Ещё здесь нашёл рекоментацию использовать статичекий MAC Use best practice configurations for the SharePoint 2013 virtual machines and Hyper-V environment
          Хотя у меня виртуальная машина с SharePoint уже не первый год работает и без проблем мигрирует с хоста на хост с динамическим MAC.

          Оказалось, что грабли с Linux на Hyper-V имеют неплохую бороду: KB976724 - The SUSE Linux Enterprise network configurations are lost after a Hyper-V Live Migration

          И вообще можно встретить рекомендации использовать только статические MAC в продуктивной среде: Hyper-V MAC Addresses Duplication or Collison
          И если честно, я сам всё больше склоняюсь к такой мысли.

  2. Alexey /

    Алексей, подскажите, как попасть в консоль VSP под root? Имеется только пароль от учетки 3parcust.

    1. Алексей Максимов / Автор записи

      Ссылка здесь на эту информацию есть. Читайте внимательно.

  3. Обратная ссылка: Развёртывание и настройка oVirt 4.0. Часть 12. Резервное копирование виртуальных машин | Блог IT-KB /

  4. Обратная ссылка: Миграция виртуальной машины oVirt 4.2 на Hyper-V (конвертация в VHDX) – Блог IT-KB /

Добавить комментарий