libvirt и virsh без панели: управление из командной строки

MAATRIX

Если вы поставили на сервер голый KVM без Proxmox или другой панели, рано или поздно встаёт вопрос: как вообще управлять виртуалками. Через qemu-system-x86_64 руками — неудобно и не масштабируется, а тянуть веб-интерфейс ради пары VM часто избыточно. Решение — libvirt и его консольный клиент virsh: они дают полный набор команд для создания, запуска, снапшотов и редактирования конфигурации виртуальных машин без единого браузерного окна.

Что такое libvirt и зачем он между вами и KVM

KVM сам по себе — это модуль ядра и набор низкоуровневых интерфейсов, а не удобный инструмент управления. libvirt — это демон (libvirtd или его модульные преемники в новых дистрибутивах) и библиотека, которая садится поверх KVM/QEMU и даёт единый API: создать домен (так libvirt называет виртуальную машину), запустить, остановить, подключить диск, настроить сеть. Panель вроде Proxmox — это, по сути, веб-обвязка поверх того же libvirt с дополнительным слоем кластеризации, хранилищ и бэкапов.

Если вы ещё выбираете между готовой панелью и голым подходом — это отдельный разговор про то, сколько VM вы держите и нужна ли вам кластеризация из коробки: разбор в статье Proxmox или голый KVM: что выбрать. Здесь предполагается, что выбор уже сделан в пользу минимализма, и разговор идёт о конкретных командах.

Установка на Ubuntu/Debian сводится к одному пакету:

apt install libvirt-daemon-system libvirt-clients qemu-kvm
systemctl enable --now libvirtd

После этого virsh подключается к локальному демону без дополнительных настроек — сессия по умолчанию использует URI qemu:///system, который даёт доступ ко всем VM на хосте (в отличие от qemu:///session, привязанного к конкретному непривилегированному пользователю).

Просмотр состояния: virsh list

Первая команда, которую вы наберёте после входа на сервер — список виртуалок:

virsh list

Она покажет только запущенные VM. Чтобы увидеть все, включая выключенные:

virsh list --all

Вывод выглядит так:

 Id   Name        State
--------------------------------
 1    web-01      running
 -    db-backup   shut off
 -    test-vm     paused

Колонка State — первое, на что стоит смотреть при разборе инцидентов: running, shut off, paused (заморожена в памяти, ресурсы не освобождены), pmsuspended (ушла в suspend-to-RAM), crashed. Дополнительно полезны флаги --inactive (только выключенные) и --name (только имена, удобно для скриптов вида for vm in $(virsh list --name); do ...; done).

Жизненный цикл VM: start, shutdown, destroy

Запуск выключенной машины:

virsh start web-01

Корректная остановка — она отправляет ACPI-сигнал гостевой ОС, и та должна сама завершить процессы и выключиться, как при нажатии кнопки питания на физическом сервере:

virsh shutdown web-01

Ключевой нюанс: shutdown не гарантирует мгновенного результата. Если внутри гостя не настроен ACPI-демон (acpid на старых системах) или система зависла, команда просто ничего не сделает — VM останется running. Проверяйте состояние через virsh list после нескольких секунд ожидания, а не считайте команду выполненной сразу.

Если гость не реагирует, остаётся принудительное отключение — аналог выдёргивания шнура питания:

virsh destroy web-01

Несмотря на пугающее название, destroy не удаляет VM и её диски — она только останавливает работающий процесс QEMU. Данные на диске сохраняются, но при таком выключении есть риск потери несинхронизированных на диск данных внутри гостевой файловой системы, как при любом жёстком обрыве питания. Используйте destroy только когда shutdown не сработал.

Для перезагрузки без полного цикла есть virsh reboot web-01 (мягкая, через ACPI) и virsh reset web-01 (жёсткая, эквивалент кнопки reset).

Полное удаление VM с диска — отдельная операция, virsh undefine, и по умолчанию она не трогает файлы дисков:

virsh undefine web-01 --remove-all-storage

Флаг --remove-all-storage нужен явно, если вы хотите удалить и виртуальные диски, а не только запись о домене — без него образы останутся лежать в хранилище (обычно /var/lib/libvirt/images/), и место не освободится.

XML-конфигурация: virsh dumpxml и virsh edit

Здесь начинается главная особенность libvirt-подхода. Вся конфигурация домена — CPU, память, диски, сетевые интерфейсы, устройства — хранится в XML. Посмотреть её можно так:

virsh dumpxml web-01

Вывод — полное описание VM, например фрагмент про диск:

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2'/>
  <source file='/var/lib/libvirt/images/web-01.qcow2'/>
  <target dev='vda' bus='virtio'/>
</disk>

Или про память и CPU:

<memory unit='KiB'>4194304</memory>
<vcpu placement='static'>2</vcpu>

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

virsh edit web-01

Команда открывает XML в $EDITOR (по умолчанию обычно vi), проверяет синтаксис при сохранении и, если всё корректно, применяет изменения. Важный момент: большинство изменений в XML применяется только после перезапуска домена (shutdown + start), а не «на лету» — исключение составляют операции, у которых есть явная live-семантика (например, hotplug дисков или изменение количества vCPU в пределах заранее заданного максимума через virsh setvcpus --live, если это поддержано конфигурацией гостя).

Если нужно изменить что-то программно, а не руками через редактор, — правьте XML-файл и применяйте его через virsh define путь-к-файлу.xml (для новой или изменённой конфигурации, до следующего запуска) — это тот же принцип, что и edit, но без интерактивного редактора, что удобно для скриптов.

Снапшоты из командной строки

Снапшоты в libvirt создаются без единого клика мышью:

virsh snapshot-create-as web-01 before-upgrade "снапшот перед обновлением ядра"

Первый аргумент после имени VM — имя снапшота, второй (в кавычках) — опциональное описание. Список снапшотов конкретной VM:

virsh snapshot-list web-01

Откат к снапшоту:

virsh snapshot-revert web-01 before-upgrade

Удаление, когда снапшот больше не нужен:

virsh snapshot-delete web-01 before-upgrade

Нюанс, который стоит проговорить честно: снапшоты через virsh snapshot-create-as по умолчанию работают на уровне диска (qcow2 с его внутренним форматом снапшотов) и не обязательно захватывают состояние памяти, если не указан флаг --live для VM, работающей на лету, и если сам образ диска — qcow2, а не raw. Для VM на raw-дисках снапшот такого рода не сработает без дополнительной настройки внешних (external) снапшотов — это одно из мест, где голый libvirt требует больше понимания механики, чем панель, где всё скрыто за одной кнопкой.

Подключение к консоли: virsh console

Когда сеть внутри VM ещё не поднята или сломана, а зайти нужно — выручает консоль:

virsh console web-01

Команда подключает терминал к серийному порту VM, если он определён в конфигурации (<console type='pty'> в XML). Для Linux-гостей это обычно работает из коробки после установки, если в ядре есть параметр console=ttyS0 в GRUB — иначе вывод будет пустым, потому что гостевая ОС не пишет в serial-консоль. Выход из консоли — комбинация Ctrl+].

Это не полноценная графическая консоль вроде VNC/SPICE (для неё есть отдельный доступ через virsh vncdisplay или virt-viewer), а именно текстовая — аналог физического последовательного порта на сервере, полезная в первую очередь для Linux-систем и для отладки на раннем этапе загрузки.

Почему XML — это плюс, а не минус

На первый взгляд текстовый XML вместо форм в панели выглядит как шаг назад. На практике для инженерного, а не «кликового» использования это преимущество:

• Версионирование в git. Файл virsh dumpxml vm-name > vm-name.xml можно закоммитить, посмотреть diff между конфигурациями до и после изменения, откатить через git revert вместо ручного восстановления по памяти.
• Программная генерация. XML легко собирается шаблонизатором (Jinja2 в связке с Ansible, например) — один шаблон плюс переменные (имя, память, диск, сеть) дают воспроизводимое создание десятков одинаковых VM без ручного клика по мастеру.
• Естественная интеграция в Infrastructure-as-Code. Модуль community.libvirt в Ansible и провайдер dmacvicar/libvirt в Terraform работают именно поверх этого XML-описания и API libvirt — то есть тот же самый механизм, которым вы пользуетесь вручную через virsh edit, лежит в основе автоматизированного пайплайна. Если у вас уже есть Ansible-плейбуки для настройки серверов, добавить туда управление виртуалками — вопрос модуля, а не смены подхода; общие принципы построения таких плейбуков разобраны в статье пример плейбука для настройки сервера.
• Отсутствие промежуточного слоя. Панель хранит свою модель данных (базу, конфиги) поверх libvirt и должна с ним синхронизироваться. При прямой работе через virsh такого расхождения между «что думает панель» и «что реально в libvirt» просто не может возникнуть — источник истины один.

Терраформ-провайдер для libvirt менее развит и более нишевый, чем провайдеры облачных платформ, — если инфраструктура уже описана в Terraform для VPS у провайдера, стоит сначала прикинуть, оправдан ли для локальных VM тот же инструмент или проще ограничиться Ansible; базовые принципы работы с Terraform для VPS есть в статье Terraform: основы для VPS.

Графический клиент без панели: virt-manager

Не всё нужно делать в терминале. Для тех, кому нужна визуальная картина — список VM, графики нагрузки, консоль в отдельном окне — есть virt-manager. Это важно понимать правильно: это не веб-панель, а десктопное GUI-приложение (на GTK), которое подключается к libvirt по тому же протоколу, что и virsh, в том числе удалённо через SSH:

virt-manager --connect qemu+ssh://user@server-ip/system

Оно даёт наглядное создание VM через мастер, просмотр консоли через VNC/SPICE и графики использования ресурсов — но требует, чтобы на машине, с которой вы подключаетесь, был установлен X-сервер (то есть локальный Linux-десктоп или X-forwarding). Для управления с телефона или из браузера оно не подходит — в этом смысле оно ближе к virsh по духу (прямое подключение к libvirt, без веб-сервера и своей базы данных), чем к Proxmox или другим панелям.

Когда прямой virsh оправдан, а когда лучше панель

Прямая работа с libvirt и virsh имеет смысл в двух случаях:

• Виртуализация — часть более крупного автоматизированного пайплайна (Ansible/Terraform), и веб-панель добавила бы лишний слой синхронизации состояния без реальной пользы.
• Вы держите одну-две VM на сервере и предпочитаете минимализм — меньше процессов, меньше поверхности для обновлений и уязвимостей, меньше того, что может сломаться при апгрейде дистрибутива.

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

Частые вопросы