Qemu ga что это

Резервное копирование виртуальных машин в среде гипервизора 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-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-томов, а не для сомнительных забав с системами виртуализации.

Итак, мы знаем, что для получения целостного снэпшота нам нужно из гостя с помощью QEMU guest agent вызвать функцию guest-fsfreeze-freeze. Однако, быть может, мы зря волнуемся и эта функция вызвается при создании снэпшота? Увы, и для Libvirt (2.9), и для Proxmox (ветка pvetest), и для Openstack это не так, а значить, чтобы автоматизировать вызов функции guest-fsfreeze-freeze надо править исходные коды соответствующих продуктов, что выходит за рамки этой статьи.

Libvirt все-таки умеет замораживать гостевую ФС

Как подсказывает уважаемый Infod, оболочке virsh из состава Libvirt можно при создании снэпшота передать параметр —quiesce, который вызовет guest-fsfreeze-freeze при создании снэпшота:

virsh snapshot-create-as myvm snapshot1 "snapshot1 description" --disk-only --atomic --quiesce

Допустим, мы нашли способ (например, самописным скриптом), “замораживать” ФС гостя перед снятием снэпшота. Теперь перед нами стоит следующая задача — оповестить гостевое ПО непосредственно перед заморозкой. QEMU guest agent поддерживает параметр -F, который говорит о том, что перед “заморозкой” и после “разморозки” нужно вызвать скрипт /etc/qemu/fsfreeze-hook и параметрами freeze и thaw соответственно. Поэтому в Debian скрипт запуска агента (/etc/init.d/qemu-guest-agent) придется поправить: DAEMON_ARGS=”-F”. Имейте в виду, что если скрипт завершится с ошибкой, “заморозки” ФС не произойдет.

Для MySQL сервера первый пришедший на ум, но неработающий скрипт может выглядеть примерно так:

#!/bin/bash USER PASSWORD case "$1" in freeze ) /usr/bin/mysql -u $USER -p$PASSWORD -e "FLUSH TABLES WITH READ LOCK;" exit $? ;; thaw ) /usr/bin/mysql -u $USER -p$PASSWORD -e "UNLOCK TABLES;" exit $? ;; * ) logger Fsfreeze script has activated with unknown parameter: $1 exit 1 ;; esac exit 1

На самом деле блокировка с базы будет снята сразу по завершении команды

mysql -u $USER -p$PASSWORD -e "FLUSH TABLES WITH READ LOCK"

из-за того, что все блокировки в MySQL работают лишь пока пользователь, поставивший их, присутствует в системе. Для правильного бэкапа придется писать дополнительный небольшой сервис (например, на Python) который будет открывать базу MySQL и ставить блокировку по команде freeze, а затем не закрывать базу и ждать команду thaw.

А как обстоят дела с Windows в роли гостя?

Надо сказать, что для Windows и MS SQL эта же процедура не требует никаких теложвижений — QEMU guest agent автоматически вызывает соответствующую функцию службы теневого копирования тома VSS, VSS информирует всех подписчиков о том, что вот-вот начнется бэкап и неполохо было бы “сброситься” на диск и т.п.

Итак, мы заблокировали 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, поскольку хоть агент и «замораживает» все смонтированные ФС за одну команду, однако делает это не одновременно, а последовательно, так что возможна рассинхронизация между томами.

Если вы нашли в статье ошибку, или же вам есть, что сказать — прошу в комментарии.

Делайте бэкапы, господа!

Назначение опции qemu-guest-agent в параметрах ВМ

Для чего нужна опция qemu-guest-agent и обязателен ли ее выбор в параметрах ВМ для гостевой ОС? Необходима ли установка SPICE-VDAgent для Linux в качестве гостевой ОС?

Ответ

Ответ доступен с подключенной услугой «Техническая поддержка».

Внимание! Для авторизации используйте учетные данные Личного кабинета

Если учетная запись от новой версии личного кабинета отсутствует, просим писать на почту lk@astralinux.ru

Qemu-guest-agent

The qemu-guest-agent is a helper daemon, which is installed in the guest. It is used to exchange information between the host and guest, and to execute command in the guest.

In Proxmox VE, the qemu-guest-agent is used for mainly three things:

To properly shutdown the guest, instead of relying on ACPI commands or windows policies
To freeze the guest file system when making a backup/snapshot (on windows, use the volume shadow copy service VSS). If the guest agent is enabled and running, it calls guest-fsfreeze-freeze and guest-fsfreeze-thaw to improve consistency.
In the phase when the guest (VM) is resumed after pause (for example after shapshot) it immediately synchronizes its time with the hypervisor using qemu-guest-agent (as first step).

Installation

Host

You have to install guest-agent in each VM and then enable it, you can do that in the Proxmox VE Webinterface (GUI)

QEMU Guest Agent Option

or via CLI: qm set VMID —agent 1

Guest

Linux

On Linux you have to simply install the qemu-guest-agent, please refer to the documentation of your system.

We show here the commands for Debian/Ubuntu and Redhat based systems:

on Debian/Ubuntu based systems (with apt-get) run:

apt-get install qemu-guest-agent

and on Redhat based systems (with yum):

yum install qemu-guest-agent

Depending on the distribution, the guest agent might not start automatically after the installation.

Start it either directly with

systemctl start qemu-guest-agent

Then enable the service to autostart (permanently) if not auto started, with

systemctl enable qemu-guest-agent

(should work for most distributions) or reboot the guest.

Windows

First you have to download the virtio-win driver iso (see Windows VirtIO Drivers).

Then install the virtio-serial driver:

Attach the ISO to your windows VM (virtio-*.iso)
Go to the windows Device Manager
Look for «PCI Simple Communications Controller»
Right Click -> Update Driver and select on the mounted iso in DRIVE:\vioserial\\ where is your Windows Version (e.g. 2k12R2 for Windows 2012 R2)

After that, you have to install the qemu-guest-agent:

Go to the mounted ISO in explorer
The guest agent installer is in the directory guest-agent
Execute the installer with double click (either qemu-ga-x86_64.msi (64-bit) or qemu-ga-i386.msi (32-bit)

After that the qemu-guest-agent should be up and running. You can validate this in the list of Window Services, or in a PowerShell with:

PS C:\Users\Administrator> Get-Service QEMU-GA Status Name DisplayName ------ ---- ----------- Running QEMU-GA QEMU Guest Agent

If it is not running, you can use the Services control panel to start it and make sure that it will start automatically on the next boot.

Testing that the communication with the guest agent is working

The communication with the guest agent takes place over a unix socket located in /var/run/qemu-server/.qga You can test the communication qm agent:

qm agent ping

if the qemu-guest-agent is correctly runnning in the VM, it will return without an error message.

Установка QEMU-агента

Для корректной работы на ваш сервер должна быть установлена программа-демон QEMU Guest Agent . Она запускается внутри виртуальной машины и обеспечивает полноценную работу с сервером в панели управления.

Если QEMU-агент отсутствует или отключен, в панели будут недоступны следующие действия:

Создание бэкапа, в том числе автоматического
Создание снапшота
Добавление SSH-ключа
Удаление SSH-ключа
Сброс пароля root
Клонирование сервера
Создание образа сервера
Открытие или закрытие доступа для поддержки
Корректное отображение графиков дашборда

Если при создании сервера вы установили на него любое ПО из маркетплейса, QEMU-агент будет установлен автоматически. В остальных случаях вы можете установить его вручную по этой инструкции.

Проверка наличия QEMU-агента

Чтобы проверить, установлен ли агент QEMU на вашем сервере:

Подключитесь к серверу через веб-консоль в панели или по SSH.
Выполните команду:

systemctl status qemu-guest-agent

Подобный вывод означает, что агент не установлен:

Unit qemu-guest-agent.service could not be found.

А в данном случае агент есть, но отключен — нужно его перезапустить:

 Active: inactive (dead) since .

Перезапуск qemu-guest-agent

Если вы уже устанавливали QEMU-агент, но описанный функционал панели недоступен, попробуйте перезапустить его — скорее всего, это решит проблему.

Подключитесь к серверу через веб-консоль в панели или по SSH.
Выполните команду:

systemctl restart qemu-guest-agent.service

Проверьте, что все работает корректно, с помощью команды:

systemctl status qemu-guest-agent.service

Если все в порядке, вывод команды будет следующим:

qemu-guest-agent.service - QEMU Guest Agent
Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
Active: active (running)

Установка qemu-guest-agent

Чтобы установить QEMU-агент, подключитесь к серверу по SSH и выполните в консоли приведенные ниже команды, выбрав вариант для вашей операционной системы.

Ubuntu 12.04, 14.04, 16.04

apt-get update; \
apt-get install wget -y; \
wget -O ./agent.deb $(wget -qO- https://packages.ubuntu.com/xenial-updates/amd64/qemu-guest-agent/download | grep -oP 'http://mirrors.kernel.org.*?\.deb'); \
dpkg -i ./agent.deb;

Ubuntu 18.04 и выше

apt update && apt install qemu-guest-agent -y;

CentOS 6

yum update -y; \
rpm -ivh https://download.opensuse.org/repositories/home:/aevseev/CentOS6/x86_64/qemu-guest-agent-2.12.1-2.4.el6.x86_64.rpm;

CentOS 7 и 8

yum update -y; \
yum install qemu-guest-agent -y;

Debian 7

wget http://archive.debian.org/debian/pool/main/q/qemu/qemu-guest-agent_2.1+dfsg-12+deb8u5a~bpo70+1_amd64.deb
dpkg -i qemu-guest-agent_2.1+dfsg-12+deb8u5a~bpo70+1_amd64.deb

Debian 8 и выше

apt update; \
apt install qemu-guest-agent -y