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

Наша взаимовыгодная связь https://banwar.org/

Після однієї з міграцій (методом 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: Зрозуміло в цілому вся описана історія по суті про те, як ми спочатку створюємо собі труднощі, а потім їх героїчно долаємо. Але можливо просто комусь цей досвід виявиться корисним.

схоже