Kvm как сделать снимок машины
Обновлено: 03.07.2024
Подготовить систему к использованию в качестве гипервизора можно, как с помощью ansible-ролей, так и вручную — путем установки и настройки необходимых пакетов. Ниже будут рассмотрены оба способа.
Установка необходимых пакетов.
Прежде, чем ис п ользовать сервер в качестве гипервизора, проверим включена ли в BIOS аппаратная виртуализация. Для Intel следующий вывод должен содержать инструкции “vmx”, для AMD — “svm”:
Можно так же проверить командой:
Для установки пакетов и использования системы в качестве гипервизора подойдет как серверный, так и desktop-дистрибутив. Ниже будет рассмотрена установка на Centos 7.x, Debian Stretch, Ubuntu 16.x, но в других версиях этих дистрибутивов установка может быть абсолютно идентична.
Ubuntu.
Debian.
Centos.
Для Centos пакеты лучше устанавливать из EPEL репозитория:
или из oVirt, где они новей:
Непосредственно сама установка пакетов:
Настройка Bridged Network.
По умолчанию, все создаваемые виртуальные машины будут в дефолтной сети KVM, которая находится за NAT’ом. Её можно удалить:
Список всех сетей для KVM можно получить командой:
Для того, чтобы создаваемые виртуальные машины находились в одной сети необходимо настроить network bridge.
Убедимся, загружен ли модуль bridge:
Если нет, то загрузим:
Ubuntu/Debian.
Устанавливаем пакет bridge-utils и редактируем настройки сетевых интерфейсов:
Для статических адресов:
Переподнимаем интерфейс и перегружаем daemon:
Centos.
Для конфигурации можно использовать текстово-графический интерфейс network manager’а:
Непосредственно сам bridge:
Для статических адресов:
Если интерфейс не управляется network manager’ом следует добавить строчку:
Переподнимаем интерфейс и перегружаем daemon:
Подготовка хоста виртуализации с помощью Ansible.
Перед тем как управлять хостами с помощью Ansible для Debian/Ubuntu дополнительно может потребоваться установить python (или python-minimal):
Нам понадобятся три роли: epel-repo для установки репозитория Epel, network — для создания network bridge и kvm — непосредственно для самой подготовки хоста виртуализации. Устанавливаем Ansible. Для Ubuntu/Debian:
Установку для других дистрибутивов смотрите в официальной документации. Указываем в конфиге путь к скачанным ролям — например, /home/username/ansible/roles:
Приводим файл inventory приблизительно к следующему виду:
И далее задаем в playbook’е, вызывающем роли kvm и network необходимые параметры — настройки сети (IP-адресс хоста не меняется), имя bridge-интерфейса:
В некоторых дистрибутивах (Centos) создание bridged interface может завершиться с ошибкой (bug пока что не исправлен), поэтому лучше явно указать, к какому интерфейсу подключать bridge. Задаем его имя, исправляя перед запуском playbook’а:
Управление гипервизором проще всего осуществлять через virt-manager. Устанавливаем в локальной системе:
Предположим, что подключаться к гипервизору будем под пользователем user. Создаем пользователя:
Для того, чтобы пользователь имел возможность управлять libvirt’ом его нужно добавить в соответствующую группу: в Centos — это группа libvirt, в Ubuntu — libvirtd. Проверим:
Следовательно, добавляем пользователя user в группу libvirtd:
В некоторых дистрибутивах (Debian 9.x) пользователя так же необходимо будет добавить в группу “libvirt-qemu”. Просмотреть список групп можно:
Теперь необходимо сгенерировать ключ ssh и установить его на сервер, к которому будем подключаться через libvirt. Поскольку virt-manager по умолчанию запускается от обычного пользователя (не из под root), то и ключ генерируем не из под root’а. Обычно ключи лежат в папке /home/user/.ssh/id_rsa. Если их нет, то создаем:
и устанавливаем на сервер с libvirt:
Далее подключаемся в virt-manager к серверу виртуализации (рис. 1).
Помимо графического интерфейса virt-manager возможно так же подключение из консоли (virsh). Подробную инструкцию можно найти на сайте libvirt.
Создание и управление виртуальными машинами.
Создание виртуальных машин из virt-manager’а тривиально и в дополнительном описании не нуждается. Что касаемо CLI, то создание виртуальной машины с именем “ubuntu-vm” ОС Ubuntu с 1024 килобайтами RAM и 1 ядром CPU будет выглядеть:
После создания виртуальная машина сама запустится, в противном случае запустить можно командой:
Завершить работу ВМ можно командой:
Завершить работу принудительно (hard power-off):
Просмотреть список всех виртаульных машин можно командой:
а только запущенных (running):
“Заморозить” (suspend) и запустить далее (resume) виртуальную машину можно командами:
Сохранить состояние машины можно командой:
По умолчанию все конфигурации виртуальных машин находятся в xml-формате папке /etc/libvirt/qemu. Можно открыть их на редактирование любым привычным редактором, а можно выполнить команду (откроется в vi):
Просмотреть конфигурацию в более читаемом виде можно командой:
Отобразить потребляемые ресурсы (CPU и Memory) можно командой:
Если пакет не установлен в системе, то:
Клонирование виртуальных машин может быть осуществлено через графический интерфейс virt-manager’а, или через консольный virt-clone. Следующая команда создаст клон оригинальной <vm-name> и автоматически сгенерирует образ диска:
Принудительно задать имя клона:
Задать имена виртуальных дисков (например, если клонируемая ВМ имеет два диска):
Если в качестве носителей ВМ используется LVM:
Подключение к консоли.
Spice.
Для подключения через virt-manager достаточно, чтобы в качестве сервера был выбран Spice (см. настройки на рис. 2), а в качестве дисплей адаптеров виртуальной машины — QXL, или VGA. Подключение через virt-manager необходимо осуществлять по SSH-ключу (не по паролю). В большинстве случаев дефолтные конфиги libvirt уже пригодны для подключения к Spice, в противном случае стоит сверить следующие настройки:
Все остальные параметры Spice должны быть дефолтными (обычно закомментированы).
VNC.
Для подключения по VNC аналогично достаточно в virt-manager выбрать “VNC Server” (рис. 3), а в качестве display-адаптеров в гостевых системах использовать QXL, или VGA.
Можно так же отредактировать настройки видео через CLI:
Приведенный пример будет слушать подключения на всех IP-адресах KVM сервера и при подключении запрашивать пароль “yourpassword”. Если убрать параметр passwd, то можно будет подключиться без пароля. Для того, чтобы определить IP-адрес и порт для подкючения к виртуальной машины по VNC выполните команду:
К полученному значению порта нужно прибавить 5900. Таким образом, в приведенном примере, подключение возможно с любого IP-адреса по порту 5901.
tty.
Подключение к текстовой консоли так же возможно напрямую через CLI. Но для этого предварительно нужно указать некоторые параметры загрузки. Для Centos/RHEL:
Альтернативно можно дописать в /etc/grub следующие параметры:
Подключаемся к консоли:
Использование NUMA.
По умолчанию libvirt использует дефолтную политику гипервизора, которая в свою очередь подразумевает запуск виртуальной машины на любых свободных вычислительных ресурсах (процессорах и ядрах). Но бывают случаи, когда явное задание ресурсов процессора бывает рациональней, особенно для систем с архитектурой NUMA (Non-Uniform Memory Access). Рассмотрим пример конфига, когда нужно назначить виртуальной машины определенные ядра процессора. Но для начала просмотрим информацию о процессорных ресурсах:
Таким образом видим, что установлен два процессора с 4 ядрами и двумя потоками на каждом ядре. Из вывода так же видим, что имеется две NUMA-ноды. Дополнительные параметры CPU можно получить командой:
Но назначение ресурсов CPU конкретной ноде не даст никакой пользы, если у этой NUMA-ноды недостаточно памяти. libvrit хранит информацию о доступной памяти на каждой NUMA-ноде. Получить информацию можно:
Таким образом видим, что для запуска ВМ с 3Гб оперативной памяти лучше использовать первую NUMA-ноду (cell 1). Просмотреть информацию можно так же через numactl. Устанавливаем:
Для примера создадим виртуальную машину, которой назначено по 2 ядра от каждого процессора:
Просмотреть результат CPU affintiy можно командой:
Подробней об использовании NUMA можно узнать на сайте Fedora и RedHat.
Проброс устройств (Passthrough).
Рассмотрим проброс устройств на примере проброса Ethernet-порта с хоста гипервизора внутрь гостевой системы в режиме PCI Passthrough. Вообще, Network адаптеры создаваемые для виртуальных машин в KVM можно так же назначать (assign) к любому ethernet-интерфейсу, но тогда теряется часть функционала hardware, а трафик пойдет через ядро хостовой системы. Для работы PCI Passthrough нужно чтобы процессор и чипсет поддерживали технологию виртуализации (в Intel — это VT-d, в AMD — AMD-Vi) и была активирована опция intel_iommu/amd_iommu. В первую очередь необходимо проверить, активированы ли данные опции в BIOS. Далее проверяем доступна ли IOMMU в самой ОС. Для AMD:
Обновляем grub и перезагружаемся:
Ubuntu/Debian:
Centos:
Теперь необходимо добавить адрес PCI-устройства:
Соответственно, адрес устройства 01:00.0, или 01:00.1. Находим его в virt-manager’е в настройках ВМ:
или добавляем через CLI при создании машины, добавив следующую строчку:
Работа со snapshots.
Наиболее простой способ управления snapshots — это virt-manager, который в свою очередь использует команды qemu. “Замораживаем” виртуальную машину, создаем snapshot и по завершении “размораживаем” виртуальную машину:
QEMU также поддерживает временные снимки, в которых пользователю не нужно создавать отдельный img-файл: флаг “-snapshot” позволяет создавать временные файлы пока виртуальная машина включена и, как только она будет выключена, все изменения удалятся:
Но QEMU в отличие от virsh не может создавать snapshot виртуальных машин “на ходу”, но для того, чтобы воспользоваться этой возможностью необходимо в гостевой системе установить qemu-guest-agent и добавить для этой виртуальной машины устройство “QEMU channel device”. Заходим в свойства виртуальной машины в virt-manager (рис. 4) и добавляем устройство:
Или через консоль:
Устройство так же может быть добавлено и для запущенной виртуальной машины. Создаем xml:
Теперь на виртуальной машине <vm-name> (так же еще называют “dom name”) необходимо установить “гостевой агент”. Ubuntu/Debian:
Centos/RHEL:
Запускаем агент и добавляем в автозагрузку:
Для того, чтобы проверить доступность гостевого агента с хоста виртуализации можно выполнить команду:
Получим следующий вывод:
Но по факту, для создания snapshots нам потребуется поддержка “заморозки” гостевой файловой системы (fsreeze). Проверяем, выполнив команду с хоста гипервизора:
Если получим вывод вида:
Дампим настройки машины в xml:
Создаем snapshot непосредственно с самими данными:
В последствии подобные snapshots, содержащие только состояние дисков, удобно использовать для backup’ов (за счет использования опции blockcommit). Во всех остальных случаях удобней пользоваться полными снимками виртуальных машин. Создадим полный snapshot:
Как видно, можно так же задать имя (ключ “name”) и описание (ключ “description). За списком остальных ключей следует обратиться к документации на сайте RedHat.
Просмотреть список всех snapshots для виртуальной машины можно командой:
В результате получите список полных snapshots. Snapshot’ы содержащие только блочные устройства (ключи “--disk-only --quiesce --no-metadata”) можно получить командой:
Получить информацию о каком-либо конкретном snapshot’e:
Получим примерно следующий вывод:
Откатить состояние ВМ к определенному snapshot’у можно командой:
Иногда snapshot может быть случайно удален. Если виртуальная машина не остановлена, то snapshot можно восстановить: на Stackoverflow есть post, описывающий пошаговое восстановление образов/snapshots виртуальных машин.
Работа со Storage Pools.
Образы жестких дисков виртуальных машин располагаются в так называемых Storage Pools. libvirt поддерживает различные типы storage pool’ов — от обычной локальной папки (local storage, или filesystem pool), или LVM-based до NFS, iSCSI, CEPH и тд. По умолчанию libvirt хранит образы дисков в локальном filesystem pool, который располагается в /var/lib/libvirt/images. Как обычно, большую часть операций со storage pools можно производить из virt-manager:
Что касаемо, консоли, то получить список доступных для хоста pool’ов можно командой:
Если требуется вывести так же список неактивных pool’ов, то следует воспользоваться ключом “--all”:
Информацию о конкретном pool’е можно получить:
Обновить имеющиеся образы в storage pool’е:
К примеру, если требуется создать дополнительный storage pool, расположенный локально в папке /mnt/somefolder, то для начала требуется создать xml:
Создаем pool из этого xml, проверяем результат и запускаем:
Если по каким-то причинам Pool неактивен, можно активировать командой:
Или даже добавить в автозапуск:
Если требуется удалить Pool, то для того, чтобы избежать проблем с виртуальными машинами использующими этот Pool, требуется вначале выполнить:
При желании, если вы хотите удалить каталог, в котором находится пул хранилищ, используйте следующую команду:
Удалить предопределяющие Pool данные можно командой:
Операции с образами дисков.
Операции с образами виртуальных дисков обеспечивает пакет QEMU, который в свою очередь поддерживает множество различных форматов: qcow, qcow2, raw, vdi, vmdk, vhdx и тд (более полный список опубликован здесь). Проще всего управлять образами через virt-manager, однако функционал QEMU будет несколько ограничен (например, нельзя изменить размер образа, или сконвертировать образ из одного формата в другой). Через консоль создание образа диска в нативном для KVM формате qcow2:
с последующим attach’ем к виртуальной машине <vm-name> как устройство vdb будет выглядеть следующим образом:
В целом интерфейс virsh c функцией attach-disk используется в следующем формате:
В качестве driver’а в большинстве случаев указывается “qemu”, в качестве cache можно указать “writethrough”. Подробней о режимах дискового кэширования можно ознакомиться здесь. Если параметр кэширования не задан, то используются параметры “Hypervisor defaults”.
Альтернативным способом будет добавление уcтройства через его xml-конфиг:
Изменим размер образа (увеличим на 10Гб):
Но при этом в virt-manager’е не отображается ни одного снимка, а команда:
так же е выводит никаких результатов о созданных snapshots. Вероятней всего, snapshot был создан через qemu и получить информацию об образе можно командой:
которая, к примеру, выдает:
Как видим, перед расширением образа необходимо удалить snapshot по его ID:
Смотрим информацию об образе можно командой:
Зачастую бывает нужно сконвертировать образ из одного формата в другой (например, для того, чтобы native-формат qcow2 работал быстрей, чем vmdk от VMware). Для этого можно воспользоваться пакетом qemu-img:
Пакет qemu-img поддерживает vmdk, qcow2, vhd, vhdx, raw, vdi. По факту нужно указать исходный и конечный формат. Сконвертируем vdi в qcow2:
Возможно использовать следующие опции:
Многое (за исключением специфических для RedHat компонентов) можно так же почерпнуть по следующим ссылкам:
Информацию по распоространенным проблемам при работе с livbirt можно найти в отдельном разделе сайта RedHat:
Как известно, бэкапы нужно делать, мало того, нужно делать их так, чтобы потом с них можно было развернуться. Особенно это касается виртуальных машин (ВМ). Рассмотрим, как можно сделать бэкап виртуальных дисков машины в среде QCOW/KVM. Основных проблем здесь две: во-первых, нужно получить консистентый (целостный) бэкап, т.е. если у нас есть СУБД или другое ПО, которое активно использует собственный кэш на запись, то перед бэкапом его нужно попросить сбросить кэш и заморозить запись на диск, иначе данные-то в снэпшот попадут, но не те, и при восстановлении СУБД может не понять такой финт. Второй вопрос — производительность ВМ в режиме снэпшота, неплохо было бы, что бы ВМ не слишком тормозила, когда мы снимаем копию, и не зависала бы, когда мы удаляем снэпшот.
Сразу дам ответ на первый вопрос — чтобы получить консистентный бэкап, нужно перед созданием бэкапа выключить ВМ средствами гостевой ОС, тогда бэкап точно получится целостным. Если вас устраивает такая ситуация — статью можно дальше не читать. Если же нет — прошу под кат.
Итак, чтобы получить консистентный бэкап, не выключая ВМ, нужно использовать гостевой агент для QEMU (не путать с гостевым агентом для QEMU SPICE и паравиртуальными драйверами для QEMU вообще). В репозитории Debian Jessie это пакет qemu-guest-agent, в Wheezy пакет доступен только через wheezy-backports. QEMU guest agent — это небольшая утилита, которая принимает команды от хоста через virio-канал с именем org.qemu.guest_agent.0 и исполняет их в контекста гостя. На стороне гипервизора канал заканчивается unix-сокетом, в который можно писать текстовые команды с помощью утилиты socat. Libvirt, правда, любит сама занимает этот канал, так что в случае, если вы для управления гипервизором используйте Libvirt, общаться с гостем придется через команду “virsh qemu-agent-command”. Команды QEMU guest agent умеет разные, вот, например, мой список:
- guest-set-vcpus
- guest-get-vcpus
- guest-network-get-interfaces
- guest-suspend-hybrid
- guest-suspend-ram
- guest-suspend-disk
- guest-fstrim
- guest-fsfreeze-thaw
- guest-fsfreeze-freeze
- guest-fsfreeze-status
- guest-file-flush
- guest-file-seek
- guest-file-write
- guest-file-read
- guest-file-close
- guest-file-open
- guest-shutdown
- guest-info
- guest-set-time
- guest-get-time
- guest-ping
- guest-sync
- guest-sync-delimited
Среди всего списка команд нас интересуют guest-fsfreeze-freeze и guest-fsfreeze-thaw. Как следует из названия, первая из них “замораживает” файловую систему гостя, а вторая “размораживает” ее. Команда (точнее IOCTL) fsfreeze — это не фича QEMU, а способность виртуальной файловой системы гостя, которая появиласть в ядре Linux довольно давно. То есть, замораживать ФС можно не только в виртуальной среде, но и на реальном железе, достаточно воспользоваться утилитой fsfreeze из пакета util-linux. В man-е fsfreeze сказано, что поддерживаются Ext3/4, ReiserFS, JFS, XFS, но у меня fsfreeze “заморозил” и Btrfs. Перед собственно “заморозкой”, но уже после того, как отработали все потоки записи, кодом ядра вызвается sync() (файл fs/super.c, строка 1329), так что за целостность данных можно не беспокоиться. Вообще, “заморозка” ФС нужна ядру для получения целостных снэпшотов LVM-томов, а не для сомнительных забав с системами виртуализации.
Libvirt все-таки умеет замораживать гостевую ФС Как подсказывает уважаемый Infod, оболочке virsh из состава Libvirt можно при создании снэпшота передать параметр --quiesce, который вызовет guest-fsfreeze-freeze при создании снэпшота:Для MySQL сервера первый пришедший на ум, но неработающий скрипт может выглядеть примерно так:
На самом деле блокировка с базы будет снята сразу по завершении команды
из-за того, что все блокировки в MySQL работают лишь пока пользователь, поставивший их, присутствует в системе. Для правильного бэкапа придется писать дополнительный небольшой сервис (например, на Python) который будет открывать базу MySQL и ставить блокировку по команде freeze, а затем не закрывать базу и ждать команду thaw.
Итак, мы заблокировали MySQL-таблицы и “заморозили” ФС гостя, пришла пора снимать бэкап. Предположим, что мы храним образа дисков ВМ в файлах формата qcow2, а не, например, в виде LVM-томов. Даже в этом случае нам предлагается множество вариантов, неплохо бы в них разобраться.
| Internal QEMU snapshot | External QEMU snapshot | QEMU backup | Снэпшот LVM-тома с файлами qcow2 | Снэпшот ФС Brtfs с файлами qcow2 | |
|---|---|---|---|---|---|
| Средство | QEMU | QEMU | QEMU | ОС | ОС |
| Команда QEMU | savevm/snapshot_blkdev_internal | snapshot_blkdev | drive_backup | ||
| Команда libvirt/virsh | snapshot-create/snapshot-create-as | snapshot-create/snapshot-create-as | |||
| Команда ОС | lvcreate | btrfs subvolume snapshot | |||
| Вид | Записи внутри образа диска | Отдельный файл — образ диска | Отдельный файл — образ диска | Блочное устройство | ФС (каталог) с образами дисков |
| Область действия | Конкретная ВМ | Конкретная ВМ | Конкретная ВМ | Всё хранилище | Всё хранилище |
| Технология | Перенаправление записи в другую область того же файла | Перенаправление записи в другой файл | Полное копирование дисков машины в другой файл | Копирование оригинальных данных на устройство снэпшота при их изменении | Перенаправление записи в другую область файловой системы |
| Копирование снэпшота в хранилище резервных копий | qemu-nbd/nbd-client | Копирование файла | Копирование файла | Монтирование снэпшота, копирование файла | Копирование файла |
| Быстродействие дисков ВМ на запись, когда снэпшот создан | Среднее (на каждую запись нужно сделать два sync(), опция qcow2:lazy refcounts улучшает ситуацию) | Высокое | Высокое | Ниже обычного примерно в 2 раза | Высокое |
| Нагрузка на хранилище при удалении (commit) снэпшота | Ниже средней (нужно перезаписать метаданные) | Высокая (нужно скопировать данные в исходный образ и перезаписать метаданные) | Низкая (нужно удалить файл) | Низкая (нужно удалить блочное устройство) | Ниже средней (нужно перезаписать метаданные) |
| Нагрузка на хранилище при откате (rollback) на снэпшот | Ниже средней (нужно перезаписать метаданные) | Низкая (нужно удалить файл) | Низкая для Libvirt (нужно заменить файл), высокая для Proxmox (нужно распаковать файл из архива) | Высокая (нужно скопировать данные на исходное блочное устройство) | Ниже средней (нужно перезаписать метаданные) |
У каждого способа есть свои плюсы и минусы. Так, способ «Internal» является, по-сути, стандартом в утилите Virt-Manager и среде Proxmox, и получение снэпшотов такого формата автоматизировано. Однако для того, чтобы «выдернуть» снэпшот из файла, нужно поднять NBD-сервер на базе qemu-nbd и подключить файл образа к нему. В способе «External» готовый для копирования файл с резервной копей получается в процессе создания снэпшота, но процесс удаления снэпшота непрост и предусматривает «возвращение» (block-commit) записанных данных из файла снэпшота в базовый образ, что сопровождается кратным увеличением нагрузки на запись в процессе удаления снэпшота. К примеру, VMWare ESXi в такой же ситуации «проседает» по производительности на запись в 5 раз.. Надо сказать, что есть еще и другой способ удаления снэпшота типа «External» — копирование всех блоков из исходного образа в снэпшот. Способ этот называется block-stream, о целесообразности применения его в продакшене судить не берусь, но, очевидно, для хранилища это будет неплохой бенчмарк.
Снэпшот LVM-тома вызвает падение производительности основного тома на запись, так что его лучше использовать тогда, когда мы уверены, что во время существования снэпшота на диск не будут интенсивно писать.
Большие перспективы открывает использование в качестве файловой системы для хранилища образов дисков файловой системы BTRFS, поскольку в этом случае снэпшоты, сжатие и дедупликация обеспечиваются самой архитектурой ФС. Минусы — Btrfs нельзя использовать в качестве разделяемой ФС в кластерной среде, кроме того, Btrfs — относительно новая ФС и, возможно, она менее надежна, чем связка LVM и ext4.
Метод получения бекапов командой drive_backup хорош тем, что можно сразу создать резервную копию на примонтированном удаленном хранилище, однако в этом случае он создает большую нагрузку на сеть. Для остальных же способов можно предусмотреть передачу только измененных блоков с помощью rsync. К сожалению, QEMU backup не поддерживает передачу только “грязных” (измененных с момента последнего бэкапа) блоков, как это реализовано, например, в механизме VMWare CBT. Обе попытки реализовать такой механизм - livebackup и in-memory dirty bitmap не были приняты в основную ветку QEMU, судя по всему, первый — из-за архитектуры (добавляется лишний демон и отдельный сетевой протокол только для этой операции), второй — из-за очевидных ограничений в применении: карта “грязных” блоков может храниться только в оперативной памяти.
В заключение рассмотрим ситуацию, при которой ВМ имеет несколько подключенных образов дисков. Очевидно, для такой ВМ нужно создавать снэпшоты всех дисков одновременно. Если вы используйте Libvirt, то волноваться вам нечего — библиотека берет все заботы по синхронизации снэпшотов на себя. Но, если вы хотите выполнить эту операцию на «чистом» QEMU, то существует два способа сделать это: остановить ВМ командой stop, получить снэпшоты, а затем продолжить исполнение ВМ командой cont или же использовать механизм транзакционного выполнения команд, имеющийся в QEMU. Нельзя использовать для этой цели только гостевой агент QEMU и команды guest-fsfreeze-freeze/guest-fsfreeze-thaw, поскольку хоть агент и «замораживает» все смонтированные ФС за одну команду, однако делает это не одновременно, а последовательно, так что возможна рассинхронизация между томами.
Если вы нашли в статье ошибку, или же вам есть, что сказать — прошу в комментарии.
[KVM Series 07] Используйте libvirt для создания снимков QEMU / KVM и снимков экземпляров Nova
В этой статье мы разберемся в знаниях о снимках состояния QEMU / KVM и о процессе использования libvirt в OpenStack Nova для создания снимков виртуальных машин QEMU / KVM.
1. Снимок QEMU / KVM
1.1 Концепция
Определение снимка QEMU / KVM:
Снимки также можно разделить на оперативные снимки (горячие снимки) и снимки Clod:
- Живой моментальный снимок: моментальный снимок, сделанный в рабочем состоянии системы.
- Холодный снимок: снимок, когда система остановлена.
Libvit выполняет различные API снимков:
Давайте посмотрим, как работают эти API:
1. virDomainSnapshotCreateXML (virDomainPtr domain, const char * xmlDesc, unsigned int flags)
Функция: Создайте снимок виртуальной машины в соответствии с xml снимка и флагами, указанными xmlDesc.
| флаги содержат | Практика снэпшотов при запущенной виртуальной машине | Как сделать снимок, когда виртуальная машина выключена |
| 0 | Создание системных контрольных точек, включая состояние диска и состояние памяти, например содержимое памяти. | Сохранять состояние диска при выключении |
| VIR_DOMAIN_SNAPSHOT_CREATE_LIVE | Во время создания снимка виртуальная машина не будет приостановлена. Это увеличит размер файла дампа памяти, но может сократить время простоя системы. Некоторые гипервизоры устанавливают этот флаг только при выполнении контрольных точек внешней системы, что означает, что обычные снимки состояния все еще должны приостанавливать работу виртуальной машины. | |
| VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY | Сделайте снимок только указанного диска. Что касается работающей виртуальной машины, моментальный снимок диска может быть неполным (аналогично ситуации, когда блок питания внезапно отключается). | Сделайте снимок только указанного диска. |
В зависимости от рабочего состояния виртуальной машины ее внутренняя реализация имеет две ситуации:
- Для работающей виртуальной машины API использует QEMU Monitor для создания снимка. Файл образа диска должен быть в формате qcow2. ЦП виртуальной машины останавливается и перезапускается после завершения снимка.
- Для остановленной виртуальной машины API вызывает метод qemu-img для управления всеми файлами образа диска.
ВотС его кодом реализации вы можете увидеть его основные этапы реализации:
2. Несколько API, связанных с virDomainSave
Эти функции API относительно похожи:
| virDomainSave | Этот метод приостанавливает работающую виртуальную машину и сохраняет содержимое памяти периода в файл. После успешного звонка домен перестанет находиться в рабочем состоянии. Используйте virDomainRestore для восстановления виртуальной машины. |
| virDomainSaveFlags | Подобно API virDomainSave, можно использовать несколько флагов. Некоторые гипервизоры необходимо вызвать перед вызовом этого метода.virDomainBlockJobAbort(), чтобы остановить операцию копирования блока. |
| virDomainManagedSave | Также похож на API virDomainSave. Основное отличие состоит в том, что libvirt сохраняет свою память в файл, управляемый libvirt, поэтому libvirt всегда может отслеживать состояние моментального снимка; при вызове метода virDomainCreate / virDomainCreateWithFlags для перезапуска домена libvirt будет использовать управляемый файл вместо пустого File, чтобы вы могли восстановить снимок. |
Features/SnapshotsMultipleDevicesВ этой статье обсуждается проблема одновременного создания снимков нескольких дисков.
1.2 Экспериментируйте с virsh
1.2.1 команда virsh save
Выполните команду "virsh save" в работающем домене d-2. После выполнения команды d-2 переходит в состояние «выключено».
Взгляните на файл образа диска и файл снимка домена:
Данные памяти сохраняются в файл в необработанном формате.
Если вы хотите восстановить, вы можете запустить команду «vish restore d-2.snap1» для восстановления из сохраненного файла.
1.2.2 virsh snapshot-create/snapshort-create-as
Сначала посмотрите на его использование:
Некоторые из этих параметров, такие как --atomic, не поддерживаются в некоторых старых библиотеках QEMU, и их необходимо обновить до новой версии. Согласно сЭта статья, Atomic нужно добавить в QEMU 1.0.
(1) По умолчанию эта команда создает все диски и память виртуальной машины как внутренний моментальный снимок.Виртуальная машина находится в состоянии паузы, когда создается моментальный снимок, и переходит в рабочее состояние после завершения моментального снимка. Длится дольше.
Файл образа каждого диска содержит информацию о снимке:
Вы можете запустить команду snapshot-revert, чтобы вернуться к указанному снимку.
Согласно сЭта статья, Libvirt сохраняет состояние памяти в определенный файл образа диска («состояние сохраняется внутри одного из дисков (как в реализации контрольной точки системы qemu'savevm)). При необходимости в будущем мы также можем добавить атрибут, указывающий _which_ disk сохранил внутреннее состояние; возможно, disk = 'vda'.)
(2) Вы можете использовать параметры «--memspec» и «--diskspec», чтобы делать внешние снимки памяти и дисков. В это время виртуальная машина Pause необходима до того, как будет получен статус памяти, и будет сгенерировано время простоя службы.
(3) Вы можете использовать параметр «--disk-only». В это время будут сделаны внешние снимки всех дисков, но снимки памяти не будут включены. Если имя файла моментального снимка не указано, он будет помещен в тот же каталог, что и исходный файл на диске. После нескольких снимков формируется внешняя цепочка снимков, и новый снимок использует зеркальный файл предыдущего снимка в качестве файла резервной копии.
Файл образа первого внешнего снимка использует исходный файл образа виртуальной машины в качестве файла поддержки:
В настоящее время откат к определенному крайнему моментальному снимку диска не поддерживается.Эта статьяКстати об обходном пути.
(4) Вы также можете использовать параметр «--live» для создания точки восстановления системы, включая состояние диска, памяти и устройства. При использовании этого параметра виртуальная машина не будет приостановлена (как этого добиться?). Следствием этого является то, что размер файла дампа памяти увеличивается, но время простоя системы сокращается. Этот параметр может использоваться только как внешняя точка восстановления системы (внешняя контрольная точка).
Обратите внимание, что моментальный снимок, созданный путем добавления «--live», и моментальный снимок, созданный без этого параметра, не будут связаны вместе:
Однако странно то, что при использовании QEMU 2.3, даже если добавлен параметр --live, виртуальная машина все равно будет временно приостановлена:
Таким образом, для команды snapshot-create-as
| параметр | результат |
| Внутренние внутренние снимки всех дисков и памяти | |
| Внешние снимки диска и памяти, виртуальная машина должна быть приостановлена | |
| --live --memspec snapshot=external --diskspec vda,snapshot=external | Создавайте системные контрольные точки (включая снимки диска и памяти), и виртуальная машина не будет приостановлена (? Результаты теста показывают, что она все равно будет приостановлена, но время приостановки будет короче, чем если бы --live не использовался) |
| --disk-only | Создание внешних снимков всего или части диска |
Вы можете использовать команду sanpshot-revert для отката до указанной точки восстановления системы, но вы должны использовать параметр «-force»:
1.3 Удаление внешних снимков
В настоящее время libvirt не поддерживает прямое удаление внешнего снимка, см.Эта статьяВведено обходное решение.
2. Снимки в OpenStack
Снимок OpenStack можно разделить на следующие ситуации:
2.1 Сделайте снимок Nova Instance
(1) Сделайте снимок виртуальной машины, запущенной из файла-зеркала.
- Просто превратите корневой диск (первый диск vd или hd) работающей виртуальной машины в образ и загрузите его для просмотра.
- Live Snapshot: для соответствия определенным условиям (QEMU 1.3+ и Libvirt 1.0.0+ и source_format не в ('lvm', 'rbd'), а не CONF.ephemeral_storage_encryption.enabled и не CONF.workarounds.disable_libvirt_livesnapshot, и может вызываться как обычно libvirt.blockJobAbort, предварительные требования могут ссылаться наЭта статья) Сделаю живой снимок. Live Snapshot позволяет пользователям делать снимки, не останавливая виртуальную машину во время работы виртуальной машины.
- Холодный снимок: холодный снимок для виртуальных машин, который нельзя использовать для снимков в реальном времени. Этот вид моментального снимка должен сначала приостановить виртуальную машину.
(2) Сделайте снимок виртуальной машины, запущенной с тома
- Вызовите Cinder API, чтобы сделать снимки для каждого подключенного тома виртуальной машины.
- Метаданные снимка будут сохранены в Glance, но изображение снимка не будет загружено в Glance.
- Этот снимок также появится в базе данных cinder и будет виден API-интерфейсу cinder.
2.2 Сделайте снимок тома
- Вызовите api драйвера cinder, чтобы сделать снимок тома в серверной части.
- Этот снимок появится в базе данных cinder и будет виден API-интерфейсу cinder.
3. Сделайте снимок виртуальной машины Nova, запущенной из файла образа.
Строго говоря, снимок виртуальной машины Nova - это не полный снимок виртуальной машины, а снимок виртуальной машины.Загрузочный диск(Корневой диск, а именно vda или hda). Сделайте снимок, чтобы сгенерировать файл формата qcow2 и передать его в Glance. Его функция часто заключается в облегчении использования образа, созданного снимком, для развертывания новой виртуальной машины. Моментальные снимки Nova делятся на Live Snapshot (непрерывный снимок) и Clold Snapshot (стоповый снимок).
3.1 Nova Live Snapshot
Когда выполнены условия, описанные в 2.1.1, запустите команду "После nova image-create ",Нова выполнит Live Snapshot. Процесс выглядит следующим образом:
- Найдите корневой диск (vda или hda) виртуальной машины.
- Создайте временную папку в папке, указанной в CONF.libvirt.snapshots_directory (по умолчанию / var / lib / nova / instance / snapshots), и создайте в ней дельта-файл в формате qcow2. Имя файла - строка uuid. Резервный файл файла такой же, как резервный файл файла корневого диска (шаг a ниже).
- Вызовите virDomainGetXMLDesc, чтобы сохранить xml-конфигурацию домена.
- Вызовите virDomainBlockJobAbort, чтобы остановить операцию активного блока на корневом диске (отменить задание активного блока на данном диске).
- Вызовите virDomainUndefine, чтобы изменить домен на транзитный тип, потому что API BlockRebase не может быть вызван для постоянного домена.
- перевод virDomainBlockRebaseЧтобы скопировать различные данные из файла образа корневого диска в файл дельта-диска. (Шаг b ниже)
- Шаг 6 - это непрерывный процесс, потому что могут быть приложения, которые записывают данные на диск. Нова вызывается каждые 0,5 секундыvirDomainBlockJobInfoAPI, чтобы проверить, закончилась ли копия.
- После завершения копирования вызовите virDomainBlockJobAbort, чтобы завершить копирование данных.
- Вызовите virDomainDefineXML, чтобы вернуть домен из транзитного в постоянный.
- Вызовите команду qemu-img convert, чтобы изменить файл дельта-изображения и файл резервной копии в файл qcow2 (шаг c ниже)
- Перенесите метаданные изображения и файл qcow2 в Glance.
Давайте посмотрим на один из ключевых API-интерфейсов int virDomainBlockRebase (virDomainPtr dom, const char * disk, const char * base, unsigned long bandwidth, unsigned int flags)
ВотСуществует PoC-код процесса, описывающий процесс.
ВотСуществует полный анализ журнала libvirt для этого процесса.
ВотЕсть статья о Libvirt Features / SnapshotsMultipleDevices.
3.2 Nova Cold Snapshot
Когда виртуальная машина не запущена или не соответствует условиям оперативного снимка, Nova выполнит холодный снимок. Основной процесс выглядит следующим образом:
(1) Когда виртуальная машина находится в рабочем или приостановленном состоянии:
- detach PCI devices
- detach SR-IOV devices
- Вызовите virDomainManagedSave API, чтобы приостановить виртуальную машину и сохранить состояние памяти в файл на диске.
(2) Вызовите команду qemu-img convert, чтобы преобразовать файл образа корневого диска в файл образа того же формата.
(3) Вызовите virDomainCreateWithFlags API, чтобы вернуть виртуальную машину в начальное состояние.
(4) Переустановите устройства PCI и SR-IOV, удаленные на шаге 1.
(5) Перенести метаданные и файлы qcow2 в Glance.
4. Снимок экземпляра Nova, запущенного с тома
(0) Запустите виртуальную машину с тома, смонтируйте другой том, а затем выполните команду nova image-create.
(1) Получите список блочных устройств (сопоставление блочных устройств) виртуальной машины из БД.
(2) Вызовите Cinder API, чтобы сделать снимок каждого тома в списке. Для тома драйвера LVM выполняемая команда аналогична "lvcreate --size 100M --snapshot --name snap / dev / vg00 / lvol1".
(3) Поместите метаданные снимка в Glance. (Примечание: изображение представляет собой просто набор некоторых атрибутов, таких как отображение блочного устройства, идентификаторы ядра и виртуального диска и т. Д., У него нет данных изображения, поэтому его размер равен 0.)
5. Ограничения текущего снимка Nova
Тогда почему Nova реализует не снимок виртуальной машины, а только снимок системного диска? Говорят, что сообщество обсудило эту функцию, и результатом обсуждения являетсяНе присоединяйсяУ этой функции есть несколько основных причин:
В данной статье мы рассмотрим несколько вариантов резервного копирования виртуальных машин на гипервизоре KVM, а так сценарии восстановления из бэкапов. Хочется сразу отметить, что как таковых удобных инструментов для резервного копирования под KVM нет, и каждый администратор использует свои варианты, скрипты и костыли. Есть 2 сценария бэкапа ВМ в KVM: с остановкой ВМ (самый простой, но используется крайне редко) и без остановки виртуальной машины.
Прежде всего хочется отметить, что особенности резервного копирования в вашем KVM сильно зависят от типа используемых виртуальных дисков: LVM, RAW (IMG) или qcow2. На моих серверах KVM диски виртуальных машин имеют формат qcow2. Я считаю, что данный формат выигрывает у остальных по двум причинам:
- Размер диска всегда имеет размер по занимаемому пространству внутри машины, его достаточно просто увеличить и уменьшить;
- Данный формат поддерживает снапшоты.
Поэтому виртуальные диски в формате qcow2 для меня бэкапить проще всего.
Создание резервных копий в KVM с остановкой виртуальной машины
Если ваш проект допускает кратковременную остановку виртуальной машины, то можно воспользоваться самым простым способом создания резервной копии. Для того, чтобы у вас всегда под рукой были актуальные резервные копии, вам нужно скопировать файл диска и конфигурационный файл самой виртуальной машины (на случай если меняется конфигурация).
С помощью virsh выведем список виртуальных машин в KVM:
Так же у меня есть директория, куда я планирую сохранять резервные копии виртуальных машин:
Конфигурационный файл виртуальной машины, можно скопировать следующей командой:
Где VM – это имя вашей виртуальной машины.
Теперь, чтобы создать резервную копию диска виртуальной машины, нужно остановить виртуальную машину и скопировать образ диска в целевой каталог:
После того, как диск полностью скопировался, нужно запустить виртуальную машину:
Для каждой виртуальной машины, можно создавать отдельную директорию и автоматизировать процесс создания копий, добавив команды скрипт и настроить задания в cron. Ранее мы размещали статью о резервном копировании в Linux с помощью скриптов. Вы можете использовать скрипты под свои нужды, адаптировав их для KVM.
Либо можете воспользоваться небольшим и простым скриптом:
Добавьте данный скрипт в крон и выполняйте так часто, как вам это требуется. Скрипт автоматически останавливает виртуальную машину, бэкапит файл диска и файл конфигурации, после чего автоматически запускает виртуальную машину.
В результате выполнения скрипта, у вас будут созданы директории для каждой виртуальной машины и в них помещены файл диска и дамп конфигурации, а также удалены старые резервные копии (количество дней укажите сами):
KVM: резервное копирование без остановки виртуальной машины
Естественно, в большинстве случае администраторы хотят использовать вариант “живого” резервного копирования виртуальных машин KVM без остановки. Он немного сложнее первого варианта и требует дополнительных действий. В данном варианте используется создание снапшота и последующее его объединение с файлом диска виртуальной машины. В самом начале статьи я писал, что использую формат дисков qcow2 и как раз это и позволяет создать живой бэкап. Для того, чтобы вы могли корректно создать копию виртуальной машины, в ВМ должен быть добавлен Channel Device с именем org.qemu.guest_agent.0 (можно добавить через конфигурационный файл или virt-manager).
Совет. Если не установить настроить агент для гостевые ВМ, при создании снапшота будет появляться ошибка:Не забудьте добавить конфигурационный XML файл виртуальной машины следующий блок:
Добавляется он в секцию “Device”, после чего нужно сохранить конфигурацию и выполнить ребут машины.
Затем в гостевой ОС нужно установить пакет qemu-guest-agent (установите его через yum/dnf):
Для создания снашшотов ВМ с Windows нужно установить virtio-win.Для создания снапшота ВМ используется следующая команда:
Где VM — это имя виртуальной машины. Далее нужно создать бэкап файла диска:
Где vda – это результат выполнения команды:
Для хранения резервных копий вы можете использовать удаленные сервера (можно копировать данные через Rsync) или хранилища . В одной из статей мы настраивали подключения к популярным облачным сервисам, таким образом вы можете сэкономить дисковое пространство на своем сервере.
Читайте также: