Настройка libvirt/virsh для управления KVM виртуальными машинами

Настройка libvirt: точки отказа в управлении машинами

Узел виртуализации выпадает в самый неудобный момент — после планового обновления ядра, переполнения пула хранения или сбоя сетевого накопителя. Часть машин на нём остаётся в состоянии, которое libvirt считает запущенным, хотя гостевые системы уже не отвечают. Хуже того, теряется доступ к консоли: точка входа одна и живёт на том же узле, поэтому вместе с хостом пропадает и возможность управлять виртуальными машинами. Диагностика превращается в обход хостов по очереди через virsh прямо в терминале.

Вторая, менее заметная проблема — несогласованные конфигурации. Описания доменов правят точечно на одном узле, чтобы «быстрее поднять сервис»: меняют тип диска, лимиты, привязку к сети. Эти ручные правки в обход регламента нигде не фиксируются, и через месяц уже никто не помнит, чем боевой узел отличается от резервного. При живой миграции всплывают залипшие машины: домен на новом узле числится активным, но ресурсы под него не выделены, и он молча не работает до ручного разбора.

Разбираем, как это закрывается: единое описание парка, управляемый доступ к консоли и сверка состояния, которая ловит расхождения до того, как они станут аварией.

Что меняет аккуратная конфигурация гипервизора

Аккуратная конфигурация гипервизора — это не «поставить и запустить», а набор решений, каждое из которых окупается на своём горизонте. Мы проверяем места, где небрежная настройка libvirt превращается в ручную работу: пулы хранения, шаблоны, лимиты, порядок старта, копии и воспроизводимость.

• Хранилище вынесено в отдельный пул на быстром томе: клонирование из шаблона идёт секундами, а развёртывание новой машины — одной операцией вместо ручной установки.
• Один обновляемый шаблон с гостевым агентом: машины получают одинаковую базовую конфигурацию, донастройка после первого запуска не нужна.
• Лимиты и приоритеты ресурсов распределены по группам машин: узел держит больше гостей без «тихих» перегрузок, плотность растёт предсказуемо, а не до первой пиковой нагрузки.
• Автозапуск и порядок старта описаны явно: после перезагрузки узла инфраструктура поднимается сама, дежурный у консоли не нужен.
• Наблюдаемость по состоянию машин, хранилищу и ресурсам: деградация видна до отказа узла — уходит класс сбоев «узнали от пользователей».
• Копии конфигураций и снимки по расписанию: восстановление после отказа узла измеряется минутами, а не поиском уцелевших дисков.
• Описание узла и машин хранится декларативно рядом с кодом: новый узел поднимается повторяемо, без «сделай как на первом».

Эти пункты проверяем до передачи в эксплуатацию. Итог виден в трёх метриках: время развёртывания, число машин на узле и время восстановления после сбоя.

Варианты настройки libvirt: сравнение подходов

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

Как только узлов становится больше двух-трёх, а машины мигрируют между ними, прямой доступ превращается в источник расхождений: пулы хранения, мосты и модели виртуальных сетей настраиваются руками и постепенно разъезжаются. Автоматизация поверх такого разнобоя ломается на первом же шаге — поэтому ограничения вариантов важнее их удобства.

Три рабочих варианта

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

Порядок внедрения: от аудита до передачи

Порядок работ выстроен так, чтобы настройка libvirt опиралась на схему размещения, а не наоборот. Иначе гипервизоры настраивают вслепую: гости оказываются не на тех узлах, пулы переполнены, а перенос упирается в расхождения конфигурации между хостами.

1. Аудит инфраструктуры. Инвентаризация узлов и гостей: какие сети и пулы хранения заданы, где параметры правили вручную и они разошлись между хостами, какие машины не поднимаются после перезагрузки. На выходе — перечень расхождений и узких мест с приоритетами.

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

3. Настройка узлов и политик. Единый профиль libvirt на всех хостах: сети, пулы, права доступа, автозапуск гостей, поведение при потере питания. Правки руками закрываются, конфигурация приводится к одной базе.

4. Проверка на отказ. Имитируем отказ узла, диска и сети: смотрим, как ведёт себя гость, проходит ли перенос, за какое время сервис возвращается к работе. Найденные слабые места закрываем до передачи.

5. Передача в эксплуатацию. Отдаём регламенты, карту размещения и инструкции по типовым операциям — создание машины, перенос, снятие резервной копии, реакция на отказ.

Что остаётся у заказчика: схемы, политики, регламенты

После сдачи стенда у заказчика остаётся не только работающий гипервизор, но и комплект артефактов, по которому его инженеры смогут вводить новые узлы, выдавать доступы и восстанавливаться после сбоя без обращения к нам. Всё, что настроено в libvirt, фиксируем в текстовом виде и версионируем — не «на словах у администратора».

• Конфигурации узлов — описания доменов, шаблоны под типовые роли, параметры привязки к ядрам и памяти: новый узел вводится копированием шаблона и правкой нескольких полей.
• Схемы сетей — топология мостов и виртуальных сетей, привязка к VLAN, адресация, выход наружу; зафиксировано, какой трафик куда ходит.
• Схемы хранилищ — пулы, размещение образов и данных по уровням: где быстрые диски, где архив, как подключаются снимки.
• Политики доступа — роли и группы, правила разграничения прав: кто вправе запускать, гасить и переносить домены, кто только смотрит консоль и журналы.
• Инструкции для инженеров — сценарии: создать домен, расширить диск, перевести на другой узел, снять и откатить снимок.
• Регламент восстановления — порядок действий при отказе узла: откуда берутся конфигурации, как разворачиваются диски, какие время и точка восстановления считаются нормой.
• Журнал изменений — конфигурации в системе версионирования, ревизии, кто и когда менял.

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

Кейс: как выросла плотность машин на одном узле

Заказчик — внутренняя платформа сервисной компании: десяток узлов виртуализации под продукты и тестовые контуры, машины разворачивались вручную. Инвентарь жил в таблице, параметры доменов правили командами прямо на работающих узлах, а после переноса конфигурации сверяли глазами. На 40–60 ручных операций в месяц приходилось 3–4 вызова дежурного, и почти каждый — с остановкой сервиса на 40+ минут.

Что изменили

Перевели управление на libvirt с декларативными описаниями: домены, сети и хранилища лежат в системе контроля версий, а на узел разворачивается один и тот же профиль. Типовые роли получили шаблоны, поэтому новая машина поднимается из описания, а не собирается руками по чек-листу.

Хранилище переразметили в пулы с тонким выделением и политиками освобождения, лимиты процессора и памяти выставили по профилю нагрузки, а не «с запасом на каждую машину». Любое изменение проходит проверку на тестовом узле и откатывается к предыдущему описанию одной операцией.

Метрики до и после

Плотность выросла за счёт того, что профили выровняли и убрали двойной резерв: часть узлов освободилась и ушла в горячий резерв вместо покупки нового железа. Каждый инцидент теперь разбирается по описанию из истории изменений — видно, что и когда менялось.

Чем централизованное управление отличается от ручных команд

Разница не в удобстве, а в том, где живёт состояние конфигурации. При работе через libvirt виртуальная машина описывается декларативно — разметка дисков, сетевые интерфейсы, ресурсы, — и это описание применяется к узлу целиком, а не воспроизводится по шагам. Ручные команды на узлах задают то же самое, но только как последовательность действий: после нескольких правок в чужих сессиях уже никто не скажет, чем текущий узел отличается от исходного замысла.

Ручные команды выигрывают там, где нужна одна операция по факту: снять зависшую машину, посмотреть журнал, поднять стенд на единственном узле. Проигрывают на масштабе — при двух десятках узлов одинаковые шаги повторяются с расхождениями, и дрейф конфигурации накапливается незаметно. Отдельная цена — восстановление: по журналу команд узел не воспроизвести, его приходится собирать заново.

Централизованное управление переносит изменения в единую точку входа. Описания лежат рядом с инвентарём и историей правок, поэтому повторяемость операций перестаёт зависеть от того, кто именно зашёл на узел сегодня. Одна операция даёт одинаковый результат и на первом узле, и на последнем: откат — это возврат предыдущего описания, а не поиск виноватой команды в истории.

Проигрывает централизация ровно в двух случаях: единичный узел в лаборатории и аварийная диагностика, когда управляющий слой недоступен. Поэтому прямой доступ к узлам сохраняют — но каждое ручное изменение затем переносят в описание, иначе ближайшее применение его перезапишет и расхождение станет непредсказуемым.

Технические сомнения: разбираем узкие места

libvirt — управляющий слой над KVM: демон ведёт реестр доменов, хранит их описания в конфигурационных файлах и отдаёт единый интерфейс для virsh, программных вызовов и панелей управления. Внедрение начинается не с переустановки гипервизора, а с инвентаризации того, что уже работает на узлах.

Ниже — сомнения, которые чаще всего всплывают на старте: совместимость с текущим парком, риски переноса, поведение при отказе узла и требования к площадке.

Что произойдёт при отказе узла?

Сам libvirt машины не «оживляет» — за это отвечает кластерный слой: проверка живости узла, антиаффинность и правила перезапуска. Мы заранее описываем, какие машины переезжают автоматически, а какие ждут ручного решения, — отказ перестаёт быть сюрпризом.

Какие требования к площадке и узлам?

Нужны узлы с аппаратной виртуализацией и общим хранилищем, если планируется переезд машин между ними, плюс доступы для служб управления. Отдельно проверяем, что диски и сетевые устройства корректно видны из гостевых систем.

Важное ограничение: слой управления не заменяет резервное копирование и мониторинг — их проектируем отдельно, иначе перенос машин остаётся без точки отката.

Обсудим задачу и вернёмся с оценкой и планом

Чтобы оценка опиралась на факты, а не на предположения, на входе собираем инвентаризацию и ограничения. Пришлите то, что уже есть под рукой — этого достаточно, чтобы понять масштаб и вернуться с планом работ и схемой внедрения.

• Список гипервизоров: сколько хостов в контуре, какие виртуальные машины на них живут и какие из них критичны для сервисов.
• Текущее управление: работаете через virsh вручную, скриптами или панелью — и что именно в этом мешает сейчас.
• Хранилище: где лежат образы и тома, используются ли пулы libvirt, нужны ли снимки и тонкое выделение места.
• Сеть: мосты, VLAN, адресация, нужен ли проброс портов и изоляция между группами машин.
• Шаблоны: как создаются новые машины, есть ли эталонные образы и XML-описания доменов.
• Доступы: каким способом готовы открыть доступ к гипервизорам — отдельный шлюз, временные ключи, только чтение на первом этапе.
• Ограничения: окна обслуживания, требования к откату, правила хранения резервных копий.

Дальше уточняем то, что из переписки не видно: схему размещения, права, порядок выката изменений и точки проверки после каждого шага. На выходе получаете план работ по этапам, схему внедрения и состав работ по инфраструктуре — с явными критериями готовности.

Опишите задачу в свободной форме — вернёмся с оценкой и планом.