Налаштування libvirt: точки відмови в керуванні машинами
Вузол віртуалізації випадає в найнезручніший момент — після планового оновлення ядра, переповнення пулу зберігання або збою мережевого накопичувача. Частина машин на ньому залишається в стані, який libvirt вважає запущеним, хоча гостьові системи вже не відповідають.
Гірше того, втрачається доступ до консолі: точка входу одна й живе на тому самому вузлі, тому разом із хостом зникає й можливість керувати віртуальними машинами. Діагностика перетворюється на поетапний обхід хостів через virsh прямо в терміналі.
Друга, менш помітна проблема — неузгоджені конфігурації. Описи доменів правлять точково на одному вузлі, щоб «швидше підняти сервіс»: змінюють тип диска, ліміти, прив’язку до мережі.
Ці ручні правки в обхід регламенту ніде не фіксуються, і за місяць уже ніхто не пам’ятає, чим бойовий вузол відрізняється від резервного.
Під час живої міграції спливають залиплі машини: домен на новому вузлі вважається активним, але ресурси під нього не виділені, і він мовчки не працює до ручного розбору.
Розбираємо, як це закривається: єдиний опис парку, керований доступ до консолі та звірка стану, яка ловить розбіжності до того, як вони стануть аварією.
Що змінює охайна конфігурація гіпервізора
Охайна конфігурація гіпервізора — це не «поставити й запустити», а набір рішень, кожне з яких окупається на своєму горизонті.
Ми перевіряємо місця, де недбале налаштування libvirt перетворюється на ручну роботу: пули зберігання, шаблони, ліміти, порядок запуску, копії та відтворюваність.
- Сховище винесено в окремий пул на швидкому томі: клонування з шаблону триває секундами, а розгортання нової машини — однією операцією замість ручного встановлення.
- Один оновлюваний шаблон із гостьовим агентом: машини отримують однакову базову конфігурацію, доналаштування після першого запуску не потрібне.
- Ліміти та пріоритети ресурсів розподілені за групами машин: вузол тримає більше гостей без «тихих» перевантажень, щільність зростає передбачувано, а не до першого пікового навантаження.
- Автозапуск і порядок старту описані явно: після перезавантаження вузла інфраструктура піднімається сама, черговий біля консолі не потрібен.
- Спостережуваність за станом машин, сховищем і ресурсами: деградація видна до відмови вузла — зникає клас збоїв «дізналися від користувачів».
- Копії конфігурацій і знімки за розкладом: відновлення після відмови вузла вимірюється хвилинами, а не пошуком уцілілих дисків.
- Опис вузла й машин зберігається декларативно поруч із кодом: новий вузол піднімається повторювано, без «зроби як на першому».
Ці пункти перевіряємо до передачі в експлуатацію. Підсумок видно в трьох метриках: час розгортання, кількість машин на вузлі та час відновлення після збою.
Варіанти налаштування libvirt: порівняння підходів
Спосіб керування libvirt обирають не за розміром парку, а за кількістю вузлів і за тим, хто й як часто змінює конфігурацію. Локальний virsh звертається до демона на одному вузлі напряму — це зручно для відлагодження, разових задач і тестових стендів, де все робить один інженер.
Щойно вузлів стає більше двох-трьох, а машини мігрують між ними, прямий доступ перетворюється на джерело розбіжностей: пули зберігання, мости й моделі віртуальних мереж налаштовуються вручну й поступово розходяться.
Автоматизація поверх такого різнобою ламається на першому ж кроці — тому обмеження варіантів важливіші за їхню зручність.
Три робочі варіанти
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Локальне керування вузлом через virsh і правку XML-описів | Один-два вузли, стенди, відлагодження, разові операції | Немає спільного стану: зміни не відтворювані, частина операцій потребує ручного втручання |
| Централізоване керування парком — єдині шаблони, групи машин, спільні пули | Десятки вузлів, міграція машин, спільні мережеві та дискові політики | Потрібен окремий керуючий контур, спільне сховище описів і дисципліна їх версіонування |
| Обгортка над наявними засобами автоматизації: декларативні описи, що приводяться до стану з репозиторію | Парк, який розгортається повторювано й пов’язаний із конвеєром постачання | Накладні витрати на підтримку описів, тонкі налаштування гіпервізора все одно правляться вручну |
Межі між варіантами рухливі: локальний доступ залишається інструментом відлагодження всередині централізованої схеми, а автоматизація будується поверх спільного опису машин. Вибір фіксуємо за кількістю вузлів, потрібною відтворюваністю та швидкістю підняття нової машини.
Порядок впровадження: від аудиту до передачі
Порядок робіт вибудувано так, щоб налаштування libvirt спиралося на схему розміщення, а не навпаки. Інакше гіпервізори налаштовують навмання: гості опиняються не на тих вузлах, пули переповнені, а перенесення впирається в розбіжності конфігурації між хостами.
-
Аудит інфраструктури. Інвентаризація вузлів і гостей: які мережі та пули зберігання задані, де параметри правили вручну і вони розійшлися між хостами, які машини не піднімаються після перезавантаження. На виході — перелік розбіжностей і вузьких місць із пріоритетами.
-
Схема розміщення машин. Розподіляємо гостей за вузлами з урахуванням ресурсів, розмічаємо мережі та сховища, визначаємо, що живе на спільному пулі, а що на локальному. Схема фіксується до налаштування — вона задає параметри профілів.
-
Налаштування вузлів і політик. Єдиний профіль libvirt на всіх хостах: мережі, пули, права доступу, автозапуск гостей, поведінка при втраті живлення. Правки вручну закриваються, конфігурація приводиться до однієї бази.
-
Перевірка на відмову. Імітуємо відмову вузла, диска й мережі: дивимося, як поводиться гість, чи проходить перенесення, за який час сервіс повертається до роботи. Знайдені слабкі місця закриваємо до передачі.
-
Передача в експлуатацію. Віддаємо регламенти, карту розміщення та інструкції з типових операцій — створення машини, перенесення, зняття резервної копії, реакція на відмову.
Що залишається в замовника: схеми, політики, регламенти
Після здачі стенда в замовника залишається не лише працюючий гіпервізор, а й комплект артефактів, за яким його інженери зможуть вводити нові вузли, видавати доступи й відновлюватися після збою без звернення до нас.
Усе, що налаштовано в libvirt, фіксуємо в текстовому вигляді та версіонуємо — не «на словах в адміністратора».
- Конфігурації вузлів — описи доменів, шаблони під типові ролі, параметри прив’язки до ядер і пам’яті: новий вузол вводиться копіюванням шаблону й правкою кількох полів.
- Схеми мереж — топологія мостів і віртуальних мереж, прив’язка до VLAN, адресація, вихід назовні; зафіксовано, який трафік куди ходить.
- Схеми сховищ — пули, розміщення образів і даних за рівнями: де швидкі диски, де архів, як підключаються знімки.
- Політики доступу — ролі та групи, правила розмежування прав: хто має право запускати, гасити й переносити домени, хто лише дивиться консоль і журнали.
- Інструкції для інженерів — сценарії: створити домен, розширити диск, перевести на інший вузол, зняти й відкотити знімок.
- Регламент відновлення — порядок дій при відмові вузла: звідки беруться конфігурації, як розгортаються диски, які час і точка відновлення вважаються нормою.
- Журнал змін — конфігурації в системі версіонування, ревізії, хто і коли змінював.
Окремо розбираємо регламент з інженерами замовника: документ, який ніхто не проходив на практиці, залишається файлом.
Кейс: як зросла щільність машин на одному вузлі
Замовник — внутрішня платформа сервісної компанії: десяток вузлів віртуалізації під продукти й тестові контури, машини розгорталися вручну. Інвентар жив у таблиці, параметри доменів правили командами прямо на працюючих вузлах, а після перенесення конфігурації звіряли очима.
На 40–60 ручних операцій на місяць припадало 3–4 виклики чергового, і майже кожен — із зупинкою сервісу на 40+ хвилин.
Що змінили
Перевели керування на libvirt з декларативними описами: домени, мережі та сховища лежать у системі контролю версій, а на вузол розгортається той самий профіль. Типові ролі отримали шаблони, тому нова машина піднімається з опису, а не збирається вручну за чек-лістом.
Сховище перерозмітили в пули з тонким виділенням і політиками звільнення, ліміти процесора й пам’яті виставили за профілем навантаження, а не «із запасом на кожну машину». Будь-яка зміна проходить перевірку на тестовому вузлі й відкочується до попереднього опису однією операцією.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Ручних операцій на місяць | 40–60 | 5–7 |
| Віртуальних машин на вузлі | 9 | 17–19 |
| Простій на плановому обслуговуванні | 40+ хвилин | до 7 хвилин |
| Позапланових інцидентів | 3–4 на місяць | 0–1 на квартал |
Щільність зросла завдяки тому, що профілі вирівняли й прибрали подвійний резерв: частина вузлів звільнилася й пішла в гарячий резерв замість купівлі нового заліза. Кожен інцидент тепер розбирається за описом з історії змін — видно, що і коли змінювалося.
Чим централізоване керування відрізняється від ручних команд
Різниця не в зручності, а в тому, де живе стан конфігурації. Під час роботи через libvirt віртуальна машина описується декларативно — розмітка дисків, мережеві інтерфейси, ресурси, — і цей опис застосовується до вузла цілком, а не відтворюється покроками.
Ручні команди на вузлах задають те саме, але лише як послідовність дій: після кількох правок у чужих сесіях уже ніхто не скаже, чим поточний вузол відрізняється від початкового задуму.
Ручні команди виграють там, де потрібна одна операція за фактом: зняти завислу машину, подивитися журнал, підняти стенд на єдиному вузлі. Програють на масштабі — за двох десятків вузлів однакові кроки повторюються з розбіжностями, і дрейф конфігурації накопичується непомітно. Окрема ціна — відновлення: за журналом команд вузол не відтворити, його доводиться збирати заново.
Централізоване керування переносить зміни в єдину точку входу. Описи лежать поруч з інвентарем і історією правок, тому повторюваність операцій перестає залежати від того, хто саме зайшов на вузол сьогодні.
Одна операція дає однаковий результат і на першому вузлі, і на останньому: відкат — це повернення попереднього опису, а не пошук винної команди в історії.
Програє централізація рівно у двох випадках: одиничний вузол у лабораторії та аварійна діагностика, коли керуючий шар недоступний.
Тому прямий доступ до вузлів зберігають — але кожну ручну зміну потім переносять в опис, інакше найближче застосування його перезапише і розбіжність стане непередбачуваною.
Технічні сумніви: розбираємо вузькі місця
libvirt — керуючий шар над KVM: демон веде реєстр доменів, зберігає їхні описи в конфігураційних файлах і надає єдиний інтерфейс для virsh, програмних викликів і панелей керування.
Впровадження починається не з перевстановлення гіпервізора, а з інвентаризації того, що вже працює на вузлах.
Нижче — сумніви, які найчастіше спливають на старті: сумісність із поточним парком, ризики перенесення, поведінка при відмові вузла та вимоги до майданчика.
Чи сумісний libvirt із нашим поточним парком?
У більшості випадків достатньо штатного пакета з репозиторію дистрибутива. Машини, які вже працюють на KVM, описуються заново в конфігурації, але гостьові системи при цьому не перевстановлюються.
Якщо частина вузлів керується напряму, домени можна заводити під керування поступово — по одному, без простою решти.
Що станеться при відмові вузла?
Сам libvirt машини не «оживляє» — за це відповідає кластерний шар: перевірка живучості вузла, антиафінність і правила перезапуску. Ми заздалегідь описуємо, які машини переїжджають автоматично, а які чекають на ручне рішення, — відмова перестає бути сюрпризом.
Які вимоги до майданчика та вузлів?
Потрібні вузли з апаратною віртуалізацією та спільним сховищем, якщо планується переїзд машин між ними, плюс доступи для служб керування. Окремо перевіряємо, що диски й мережеві пристрої коректно видно з гостьових систем.
Важливе обмеження: шар керування не замінює резервне копіювання та моніторинг — їх проєктуємо окремо, інакше перенесення машин залишається без точки відкату.
Обговоримо задачу та повернемося з оцінкою й планом
Щоб оцінка спиралася на факти, а не на припущення, на вході збираємо інвентаризацію та обмеження. Надішліть те, що вже є під рукою — цього достатньо, щоб зрозуміти масштаб і повернутися з планом робіт та схемою впровадження.
- Список гіпервізорів: скільки хостів у контурі, які віртуальні машини на них живуть і які з них критичні для сервісів.
- Поточне керування: працюєте через virsh вручну, скриптами чи панеллю — і що саме в цьому заважає зараз.
- Сховище: де лежать образи й томи, чи використовуються пули libvirt, чи потрібні знімки та тонке виділення місця.
- Мережа: мости, VLAN, адресація, чи потрібен проброс портів та ізоляція між групами машин.
- Шаблони: як створюються нові машини, чи є еталонні образи та XML-описи доменів.
- Доступи: яким способом готові відкрити доступ до гіпервізорів — окремий шлюз, тимчасові ключі, лише читання на першому етапі.
- Обмеження: вікна обслуговування, вимоги до відкату, правила зберігання резервних копій.
Далі уточнюємо те, що з листування не видно: схему розміщення, права, порядок викочування змін і точки перевірки після кожного кроку. На виході отримуєте план робіт за етапами, схему впровадження та склад робіт з інфраструктури — з явними критеріями готовності.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом.
