Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
Как известно, бэкапы нужно делать, мало того, нужно делать их так, чтобы потом с них можно было развернуться. Особенно это касается виртуальных машин (ВМ). Рассмотрим, как можно сделать бэкап виртуальных дисков машины в среде 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-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-томов, а не для сомнительных забав с системами виртуализации.
Итак, мы знаем, что для получения целостного снэпшота нам нужно из гостя с помощью QEMU guest agent вызвать функцию guest-fsfreeze-freeze. Однако, быть может, мы зря волнуемся и эта функция вызвается при создании снэпшота? Увы, и для Libvirt (2.9), и для Proxmox (ветка pvetest), и для Openstack это не так, а значить, чтобы автоматизировать вызов функции 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.
В заключение рассмотрим ситуацию, при которой ВМ имеет несколько подключенных образов дисков. Очевидно, для такой ВМ нужно создавать снэпшоты всех дисков одновременно. Если вы используйте Libvirt, то волноваться вам нечего — библиотека берет все заботы по синхронизации снэпшотов на себя. Но, если вы хотите выполнить эту операцию на «чистом» QEMU, то существует два способа сделать это: остановить ВМ командой stop, получить снэпшоты, а затем продолжить исполнение ВМ командой cont или же использовать механизм транзакционного выполнения команд, имеющийся в QEMU. Нельзя использовать для этой цели только гостевой агент QEMU и команды guest-fsfreeze-freeze/guest-fsfreeze-thaw, поскольку хоть агент и «замораживает» все смонтированные ФС за одну команду, однако делает это не одновременно, а последовательно, так что возможна рассинхронизация между томами.
Если вы нашли в статье ошибку, или же вам есть, что сказать — прошу в комментарии.
Русские Блоги
QEMU Guest Agent
содержание
Каталог статьи
QEMU Guest Agent
Qemu Guest Agent, называемый QGA, является демоном QEMU-Gate-agent.service, бегающий внутри виртуальной машины QEMU, аналогично инструменту VMware, в первую очередь, чтобы помочь введению гипервизора к гостям.
QEMU реализует функции связи между ними, установив канал данных между хостом и гостями, которые усиливают возможности контроля хоста для гостей. Этот метод связи не зависит от и сетей, но полагается на Virtio-Serial или ISA-Serial, называется Org.QEMU.Guest_AGent.0 в файле XML домена. QEMU предоставляет канал моделирования и обмена данными последовательных устройств и в конечном итоге представляет последовательное устройство (гость) и файл сокета UNIX (хост).
LibVRIT также предоставляет специальный VIRDOMAINQEMUAGENTCOMMAND API, выставляет с помощью команды, общается Virsh QEMU-Агент-Command и работает с QGA, часто используется для осуществления мониторинга QEMU гость и управления фоном, таких как изменение виртуальной машины.
Установите QGA
В среде OpenStack, вы поддерживаете автоматическую установку из L версии, просто установить свойство hw_qemu_guest_agent для изображения:
Вы можете изменить пароль виртуальной машины с помощью Novaclient Смотрите https:. //spectack/nova-specs/specs/liberty/implement/libvirt-set-admin-password.html:
Интерфейс QGA
NOTE: Различные гости имеют разные инструкции поддержки, здесь необходимо отметить, что ОС Windows ограничен, потому что это операционная система замкнутого источника, поэтому вы можете увидеть: https: //fedoraproject.org/wiki/windows_virtio_drivers.
Гость синхронизация: Только не добавляя 0xFF символов в ответ.
guest-ping：Ping the guest agent, a non-error return implies success。
Гость-получить время: Получить время виртуальной машины (возвращаемое значение по отношению к 1970-01-01 в МАХ, время наносекунд).
Установка гостей: устанавливает время виртуального машины (вход относительно 1970-01-01 в UTC, время в наносекундах).
Информация о гостях: возвращает все команды, поддерживаемые qga.
Гостевое отключение: выключите виртуальную машину, поддерживайте HALT, PowerDown, Reboot и по умолчанию для powndown.
Гость-файл-закрыть: Закрыть файлы в открытой виртуальной машине.
Гость-файл чтение: считывает содержимое файла в виртуальной машине в соответствии с дескриптором файла (возврат к содержанию файла в формате base64).
Гостевой файл-запись: записывает содержимое файла в виртуальную машину в соответствии с дескриптором файла.
guest-file-seek：Seek to a position in the file, as with fseek(), and return the current file position afterward. Also encapsulates ftell()’s functionality, just Set offset=0, whence=SEEK_CUR。
guest-file-flush：Write file changes bufferred in userspace to disk/kernel buffers。
guest-fsfreeze-status：Get guest fsfreeze state. error state indicates。
guest-fsfreeze-freeze：Sync and freeze all freezable, local guest filesystems。
guest-fsfreeze-thaw：Unfreeze all frozen guest filesystems。
guest-fstrim：Discard (or “trim”) blocks which are not in use by the filesystem。
guest-suspend-disk*：Suspend guest to disk。
guest-suspend-ram*：Suspend guest to ram。
guest-suspend-hybrid：Save guest state to disk and suspend to ram（This command requires the pm-utils package to be installed in the guest.）。
guest-network-get-interfaces：Get list of guest IP addresses, MAC addresses and netmasks。
guest-get-vcpus：Retrieve the list of the guest’s logical processors。
guest-set-vcpus：Attempt to reconfigure (currently: enable/disable) logical processors inside the guest。
Использование OpenStack Cloud Мониторинг программы хоста QGA в
Как описано выше, поддержка OpenStack для QGA и в течение длительного времени, см.:
Вот схема мониторинга хоста OpenStack Count Coen в качестве примера, идей: сначала увеличивайте серийный конфигурацию по виртории для каждой виртуальной машины и запустите демон QGA. Затем запустите процесс службы монитора на хосте и получите информацию о мониторинге виртуальной машины, взаимодействуя с qga.
Мониторинг связанных операций в процессе создания облачного хоста: 
Монитор службы однофазного мониторинга съемки информации и толкатель 
Русские Блоги
Через QEMU-GuestAgent вводить и записывать файлы извне в виртуальную машину KVM
В этой статье будет приведен пример прямой записи файлов на хосте в виртуальную машину, чтобы объяснить, почему инъекция необходима и как ее реализовать.
оглавление
▪ Зачем «вводить» в ВМ
▪ Как добиться «инъекции»
▪ Шаг 1. Настройка канала для виртуальной машины
▪ Шаг 2. Развертывание QEMU-GA
▪ Шаг 3. Инструкция по эксплуатации впрыска
▪ Шаг 4. Расчет Base64
▪ Шаг 5. Начать инъекцию
▪ Прикреплено 1. Все команды, поддерживаемые qemu-ga
▪ Приложение 2. Настройка нескольких каналов
Зачем «вводить» в ВМ
Причина проста: он не может быть реализован вне виртуальной машины, он может быть реализован только внутри виртуальной машины.
Для виртуальных машин на основе KVM обычно предъявляются следующие требования:
▷ Изменить пароль онлайн
▷ Добавить открытый ключ онлайн
▷ Онлайн коллекция производительности(Например, использование процессора, загрузка, использование памяти и другие показатели производительности)
▷ Различные другие онлайн-функции
Общность вышеуказанных сценариев: это не может быть достигнуто только вне ВМ. Следовательно, существует несколько решений, но независимо от того, какое решение может быть реализовано, следующие две точки должны выполняться одновременно:
▷ придел: Открыть канал между внутренней частью виртуальной машины и внешним (хостом) для обмена данными
▷ agent: Установка агента внутри виртуальной машины для получения внешних инструкций и результатов обратной связи
Практику посадки агента внутри ВМ можно смело назвать«Инъекционные»
Как добиться «инъекции»
Есть 2 типа методов:
▷ Перейти сеть: Это будет сложнее. Необходимо заранее вставить сетевую карту управления или использовать существующую сетевую карту + специальную маршрутизацию, чтобы обеспечить возможность передачи данных, что приводит к более сложной топологии сети
▷ Оборудование для ходьбы: Это намного проще, просто установить канал устройства между виртуальной машиной и хостом. Например, добавьте символьное устройство к виртуальной машине KVM и сопоставьте его с файлом сокета на хосте. Между символьным устройством и сокетом формируется канал, через который можно передавать внутренние и внешние данные.
Запустите агент на виртуальной машине, прочитайте символьное устройство в режиме реального времени и осуществите взаимодействие данных с хостом.
Какие данные отправляются и принимаются в канале, вы можете определить самостоятельно, или вы можете использовать официальное решение KVM, называемое Qemu Guest Agent, или, для краткости, qemu-ga. Он содержит 2 аспекта:
▷ Определение протокола для передачи данных в канале: JSON-формат
▷ Агент в ВМ: Запустите процесс демона с именем qemu-ga, который получит входящую команду json от символьного устройства, затем выполнит соответствующую команду в соответствии с командой и вернет результат хосту через символьное устройство.
Полезность qemu-ga заключается в том, что инкапсулированные инструкции совместимы с некоторыми различными операционными системами, такими как инструкция записи файла guest-file-write, которая может использоваться как для Linux, так и для Windows.
Что касается конфигурации и использования qemu-ga, автор ранее написал статью «Взаимодействие с виртуальной машиной qemu на основе QMP», в которой подробно описываются принцип ее работы и основные методы использования. Вот адрес
Шаг 1. Настройте канал для ВМ
Виртуальная машина, запущенная libvirt, может добавить конфигурацию в XML
Примечание: вышеуказанная конфигурация должна быть размещена В пункте
Шаг 2. Развертывание QEMU-GA
1️⃣ Установить qemu-ga
Установочный пакет окон qemu-ga показан на рисунке
2️⃣ Начать QEMU-га
Возьмите centos7 в качестве примера
Проход после запуска systemctl status qemu-guest-agent Вы должны увидеть, что процесс начался, как показано
Примечание: некоторые qemu-ga будут отклонять некоторые команды.Это потому, что некоторые команды отключены в файле конфигурации qemu-ga. Например, в centos7, файл конфигурации это / etc / sysconfig / qemu-ga
3️⃣ Тест Кему-га
На хосте виртуальной машины выполните следующую команду:
Если возвращается следующее содержимое, qemu-ga доступна
Затем проверьте, какие инструкции поддерживает qemu-ga.
Вы должны увидеть, что многие команды поддерживаются. Поскольку следующие команды необходимы для следующего эксперимента, пожалуйста, подтвердите, все ли они поддерживают
▪ guest-exec: команда execute (асинхронная операция)
▪ guest-exec-status: просмотр результатов выполнения команд
▪ guest-file-open: откройте файл и получите дескриптор
▪ guest-file-write: записать файл (передать base64)
▪ guest-file-close: закрыть файл
Шаг 3. Инструкция по эксплуатации впрыска
Цель эксперимента:Запишите содержимое открытого ключа RSA в /root/.ssh/authorized_keys
Это включает в себя следующие 3 шага:
1. Создайте каталог /root/.ssh с разрешением 700
2. Создайте файл /root/.ssh/authorized_keys с разрешением 600
3. Кодируйте текст открытого ключа RSA с помощью Base64 (запись гостевого файла не поддерживает открытый текст, только base64) и запишите закодированное содержимое в /root/.ssh/authorized_keys
Шаг 4. Расчет Base64
Здесь сначала предположим, что содержимое открытого ключа RSA
Это получит содержимое в кодировке base64
Шаг 5. Начните инъекцию
1️⃣ Создайте каталог /root/.ssh с 700 разрешениями
2️⃣ Создайте файл /root/.ssh/authorized_keys с разрешением 600
3️⃣ Записать кодировку Base64 в /root/.ssh/authorized_keys
Проверьте эффект: проверьте /root/.ssh/authorized_keys в виртуальной машине в это время, вы должны увидеть недавно добавленную строку
Прикреплено 1. Все команды, поддерживаемые qemu-ga
Разные версии qemu-ga и разные операционные системы имеют разные поддерживаемые команды. Ниже приведены все текущие параметры, которые можно увидеть на официальном сайте.
Proxmox и гостевые системы Windows.
После установки гостевой системы на Proxmox для того чтобы не было проблем с производительностью и резервным копированием необходимо произвести некоторые действия.
1. Ballooning
Для эффективного использования ресурсов Proxmox поддерживает технологию ballooning.
Ballooning – это динамическое управление памятью. Другими словами, вы прописываете в настройках виртуальной машины минимальный и максимальный объем памяти, выделяемой этой машине, а далее Proxmox сам распределяет необходимые ресурсы. Таким образом уменьшается влияние гостевой системы на весь хост.
Для начала выставим желательные параметры в настройках машины.
Чтобы их применить, машину нужно выключить и включить обратно.
Чтобы ballooning заработал, нам потребуется скачать и установить дополнительные драйвера.
Перейдем на гостевую систему и создадим каталог Balloon в папке Program files (c:/ Program files /Balloon). В эту папку со скачанного диска нужно скопировать драйвера для вашей операционной системы.
В диспетчере устройств появится новое оборудование и на него нужно установить эти драйверы.
После этого необходимо установить ballooning как службу.
Win + X, Выполнить, cmd
Win + X, Выполнить, services.msc
Выделение памяти теперь работает коректно.
2. QEMU Guest agent
Следующее что нужно сделать – установить QEMU Guest agent. Без этого не будет работать поддержка VSS (Volume Shadow Copy Service) т.е. служба теневого копирования тома.
В настройках виртуальной машины включим агента. Чтобы настройки применились – выключим и включим снова данную виртуальную машину.
У нас появилось новое устройство:
Драйверы находятся на том же диске в папке vioserial
Устанавливаем и проверяем, что QEMU Guest agent запущен в сервисах.
Рекомендации (best practices) по установке Windows 10 и 11 на Proxmox
Я решил перевести заметку из proxmox wiki на тему рекомендаций по установке в качестве гостевой системы Windows 10. Там нет каких-то особых и критичных замечаний. Просто последовательно изложен порядок рекомендуемых действий и настроек для максимального быстродействия и стабильной работы системы.
Введение
В данной статье будут даны общие рекомендации, так называемые best practices на тему установки Windows 10 или 11 на гипервизор Proxmox. Данное руководство можно использовать как how to для проверки себя во время настройки виртуальных машин.
Подготовка к установке
Для того, чтобы получить хорошее быстродействие операционной системы Windows на хосте Proxmox, мы установим Windows VirtIO Drivers во время установки VM.
Запуск установки Windows в Proxmox
Подробно описанную процедуру можно лицезреть на видео на примере установки Windows Server 2016 на ProxMox. Установка Windows 10 или 11 будет проходить точно так же.
Установка Qemu Guest Agent на Windows
Для того, чтобы корректно работал Guest Agent на Windows, необходимо его установить отдельно. Он находит в iso образе virtio в корне диска, в папке guest-agent. Для x64 архитектуры установочный файл будет называться qemu-ga-x86_64.msi. Просто запустите установку и дождитесь окончания. Больше ничего делать не надо, агент автоматически установится и запустится.
Если всё прошло успешно, то вы сразу же в веб интерфейсе Proxmox увидите ip адреса на сетевых интерфейсах Windows.
Драйвера и Службы
Чтобы установить все недостающие драйвера для корректной работы Windows на Proxmox, запустите virtio-win-gt-x64.msi в корне диска virtio. Можете убрать установку тех драйверов и служб, что вы точно не будете использовать. Например, Qxl и Spice. После этого не только ip адреса, но и использования оперативной памяти должны корректно отображаться в веб интерфейсе.
Рекомендуется посмотреть менеджер устройств, чтобы убедиться в том, что там нет неопределённого оборудования. Если все драйверы установились корректно, то всё оборудование будет с драйверами и определено. Если это не так, то попробуйте установить драйвер устройства вручную. Для этого укажите в качестве источника драйвера виртуальный диск с virtio.iso и обязательно укажите использовать для поиска драйвера подпапки. Если драйвер будет найдет, то выберите его и установите, подтвердив, что доверяете установке драйверов от указанного поставщика.
Формат диска raw vs qcow2
Историю с выбором типа диска в proxmox я разбирал подробно в отдельной заметке. В общем случае формат raw обеспечивает лучшее быстродействие, но у qcow2 есть дополнительный полезный функционал. Речь идёт о технологии copy on write и возможности делать Live Snapshots. В настоящий момент формат qcow2 выбирается по умолчанию.
VirtIO drivers
Make it really easy: Build your ISO with drivers already included: