Qemu-guest-agent

Contents

Introduction — What is 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 two things:

1. To properly shutdown the guest, instead of relying on ACPI commands or windows policies
2. To freeze the guest file system when making a backup (on windows, use the volume shadow copy service VSS).

Installation

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

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:

and on Redhat based systems (with yum):

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

Start it either directly with

(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:

1. Attach the ISO to your windows VM (virtio-*.iso)
2. Go to the windows Device Manager
3. Look for «PCI Simple Communications Controller»
4. 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:

1. Go to the mounted ISO in explorer
2. The guest agent installer is in the directory guest-agent
3. 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:

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:

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

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 запущен в сервисах.

QEMU/KVM и установка Windows

Хотим мы того или нет, но программы, для которых необходима Windows, никуда из офисов не исчезли. В ситуации, когда их использование безальтернативно, лучше иметь виртуальную ОС, например для того, чтобы подключиться к аудио-конференции через Skype for Business.

В этой статье я расскажу, как можно с минимальными издержками установить гостевую ОС Windows на гипервизоре QEMU с помощью графического интерфейса virt-manager . Мы нанесем на карту все подводные камни и рифы, а жучков аккуратно посадим в банку.

Подготовка

Самый первый шаг — настройка параметров ядра. Обязательна поддержка KVM и vhost-net , желательна поддержка туннельных интерфейсов [1] и сетевого моста [2] . Полный список на Gentoo вики-странице QEMU.

Подготовьте дисковое пространство. Я выделил 70 GiB, и Windows 8.1 за пару месяцев использовала почти 50 GiB так, что для обновления до 10-й версии места на диске не хватило.

Далее, нам понадобится набор редхатовских драйверов virtio-win . Если у вас установлен RedHat, достаточно запустить

и образ iso будет записан в каталог /usr/share/virtio-win/ . Также можно его скачать с репозитариев Fedora.
Убедитесь, что поддержка аппаратной виртуализация включена в BIOS/UEFI. Без этого KVM не будет активирован, а virt-manager выдаст вот такую ошибку.

В качестве проверки можно прочитать файл устройства.

Если файл не обнаружен, а опции ядра выставлены верно, значит дело в настройках BIOS/UEFI .
Устанавливаем нужные пакеты.

Для RedHat 7 достаточно установить только virt-manager , так как QEMU устанавливается по умолчанию.

Дебианщикам надо установить пакет qemu .

Можно теперь переходить к установке.

Запуск и инсталляция

Запускаем virt-manager и создаем новую виртуальную машину из локального хранилища.

Указываем путь к установочному iso образу Windows.

Далее, на 3-м и 4-м шаге будет выбор количества CPU, объем RAM и размер дискового пространства, после чего на 5-м шаге следует выбрать дополнительные конфигурации перед настройкой.

Окно дополнительных настроек нужно для того, чтобы выполнить финт ушами. Его смысл в том, чтобы добавить виртуальный флопарь с драйверами из набора virtio-win . Это даст возможность изменить тип жесткого диска: удалить диск с шиной IDE и добавить его же, но с шиной VirtIO. Подробно, в доках RedHat.

Прописываем драйвер /usr/share/virtio-win/virtio-win.vfd и добавляем виртуальный флоппи-диск. Затем переходим на вкладку [Шина] Диск № и проделываем финт с заменой шины диска: удаляем с IDE и добавляем с VirtIO.

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

В принципе, уже можно начинать инсталляцию, но мы забыли добавить CD-ROM с драйверами virtio-win , а они нам пригодятся, когда диспетчер устройств засверкает желтыми иконками вопросительного знака.

Ну вот теперь можно начать установку.

Ну хорошо, начали мы установку. А что, если установщик Windows попросит сменить диск? Мне из-за этого пришлось пару раз прервать и начать всю карусель заново, но с вами такого уже не случится.

Драйвера и доводка

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

Нужно скормить им драйвера из набора virtio-win , что подключены через IDE CD-ROM в предыдущем разделе.

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

Вот весь список, а это соседняя страница RedHat доков, где установка драйверов показана подробнее.

• Balloon, the balloon driver, affects the PCI standard RAM Controller in the System devices group.
• vioserial, the serial driver, affects the PCI Simple Communication Controller in the System devices group.
• NetKVM, the network driver, affects the Network adapters group. This driver is only available if a virtio NIC is configured. Configurable parameters for this driver are documented in Appendix E, NetKVM Driver Parameters.
• viostor, the block driver, affects the Disk drives group. This driver is only available if a virtio disk is configured.

Оборудование

Тут постепенно начинается область безграничных возможностей и 101 способов сделать по-своему, поэтому я покажу, как это работает у меня, а вы можете настроить более точно под свои нужды.

У меня выбран дисплей Сервер Spice и звуковое устройство ich6 . Нет, конечно, если у вас уйма времени и желание во всем разобраться до самых тонкостей — дерзайте и пробуйте альтернативные подходы, но у меня звук взлетел, вернее завибрировал, только с такими настройками. Во второй части, посвященной прогулке по граблям и отлову багов, я расскажу об этом подробнее. В закладке видео я выставил QXL , ибо с этой опцией, благодаря волшебному драйверу, мне удалось добиться нормального разрешения экрана.

Подключаться к ВМ можно разнообразно.

1. Через графический интерфейс virt-manager
2. Выбрать дисплей VNC-сервер и подключаться через vnc-клиента
3. Установить Spice-клиента и подключаться через него
4. К Windows можно подключиться через rdp, если включен терминальный сервер

У меня вариант 3, для Gentoo это программа spice-gtk

Сеть для ВМ можно настроить по-разному, на Хабре умельцы уже об этом писали. Я перепробовал несколько способов, и в конце простота опять взяла вверх. Сама ВМ запускается из под рута [3] , но графический интерфейс spice-gtk — из под обычного непривилегированного пользователя. Это позволяет решить дилемму: для сетевых опций нужны права рута, а для звукового демона pulseaudio, рут запрещен. Я пробовал навешать все права на обычного пользователя, но ничего не получалось, то pulse не пульсирует, то сеть не создается, там много а тут мало. В итоге решил так и доволен. Буду рад, если в комментариях будет найден лучший способ.

Такой простой выбор сетевых опций дает результат превосходящий ожидания. Создаются 3 дополнительных сетевых интерфейса: virbr0, virbr0-nic, vnet0.

В iptables создается свод правил, вот основные:

Повторяю, все это libvirtd создает сам, ничего для этого делать не надо. В результате имеем нормальный роутинг между хостом и ВМ, можно обмениваться файлами по ssh / scp . Можно пойти дальше и создать шару на Windows, а на Linux хосте настроить samba, но мне это показалось избыточным.

В завершение

Трудно рассказать в одной статье обо всех аспектах Windows + QEMU/KVM, поэтому завершим в следующей. А там будет самый смак, командный интерфейс, разрешение экрана максимум 1024×768, Сцилла pulseaudio и Харибда сети, команда virsh и настройка ВМ из конфиг файла, фейл с tpm , двоичный синтаксис устройств и прочие тихие радости.

1. ↑TUN/TAP interfaces
2. ↑Ethernet bridging
3. ↑От английского root

Live (горячий) бэкап виртуальных машин KVM

Некоторое время назад озаботился решением вопроса бэкапа виртуальных машин kvm. Когда стал разбираться в теме, с удивлением обнаружил, что каких-то удобных, устоявшихся решений для горячего бэкапа виртуальных машин без остановки работы в kvm нет. Ни коммерческих решений не увидел, ни бесплатных. Пришлось самому вникать в суть и разбираться в теме.

Введение

С гипервизором kvm лично мне приходилось мало работать. Еще в первое мое знакомство с гипервизорами, когда я выбирал, какой использовать в своей работе, kvm мне не понравился вообще по следующим причинам:

1. Нет удобного инструмента для управления гипервизором под Windows. Для меня это критично, так как моя основная рабочая система ОС Windows.
2. Не увидел готового образа, который бы позволил быстро и без лишних движений развернуть гипервизор на новом железе.

В итоге я остановился на Xen там, где нужно поставить систему на программный рейд mdadm, и Hyper-V в тех случаях, где рейд либо не нужен совсем, либо он аппаратный. В своей работе так или иначе приходится сталкиваться с различными системами, поэтому разбираться приходится во всем, в том числе и в kvm.

Есть 2 различных способа сделать бэкап виртуальной машины kvm:

1. С остановкой или заморозкой системы на короткий промежуток времени.
2. Без остановки системы вообще.

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

Какой диск выбрать в kvm — lvm, raw (img) или qcow2

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

LVM. Тут все понятно. Использование lvm томов в виде дисков виртуальных машин. Такой диск будет блочным устройством и должен работать быстрее всех остальных типов, так как нет лишней прослойки в виде файловой системы.

• Снэпшоты средствами самого lvm, с них легко снять бэкап без остановки виртуальной машины.
• Максимальное быстродействие.
• Легко изменить размер диска.

• Более сложное управление по сравнению с дисками в виде отдельных файлов.
• Менее гибкое управление пространством диска. Если весь диск разбить на lvm разделы для виртуалок, то места на нем не останется, даже если вируталки будут пустые.
• Более сложный перенос на другой сервер.

RAW. Это обычный формат сырых данных. Среди дисков в виде файлов это будет самый простой и быстрый вариант. Все данные пишутся как есть без дополнительных обработок и служебной информации. Формат является универсальным для большинства популярных гипервизоров.

• Максимальная простота и производительность среди образов в виде файла.
• Универсальный формат с поддержкой в большинстве гипервизоров.
• Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.

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

QCOW2. Родной формат для гипервизора QEMU. Расшифровывается как QEMU Copy-on-write. Этот формат позволяет создавать динамические диски для виртуальных машин, а так же поддерживает снепшоты. Теоретически, скорость работы должна хоть и не сильно, но уступать RAW. Как обстоит дело на практике, я не знаю, не замерял и подробно эту информацию не проверял.

• Поддержка снепшотов и динамических дисков. Как следствие — более удобное управление дисковым пространством.
• Легкость переноса виртуальной машины на другой сервер. Достаточно просто скопировать файл.

• Более низкая производительность, по сравнению с другими типами образов.

У каждого типа есть свои преимущества и недостатки. Lvm проще всего бэкапить, но им сложнее всего управлять. Для того, кто хорошо знаком с lvm это не проблема, если сталкиваешься первый раз, то возникает много вопросов. У raw нет снепшотов, лично для меня это большой минус, я этот формат вообще не рассматриваю. Если нет максимальной нагрузки на дисковую подсистему, то QCOW2 мне кажется наиболее приемлемым вариантом. Собственно, ниже и пойдет рассказ, как совместить удобство управления QCOW2 и простоту бэкапов и снэпшотов lvm. Я покажу, как сделать живой бэкап виртуальной машины kvm в формате qcow2 без остановки виртуальной машины.

Бэкап виртуальной машины kvm без остановки

Перед практической реализацией живого бэкапа виртуальной машины, снова немного поговорим о теории. Для бэкапа виртуальной машины kvm достаточно просто скопировать ее диски в виде файлов. Это можно сделать даже при работающей машине. Но если в этот момент на виртуалке идет какая-то дисковая активность, вы скорее всего получите неработающий образ. И это логично. Значит нам, чтобы гарантированно скопировать диск, виртуальную машину нужно выключить, либо придумать что-то еще.

Это «что-то еще» является снепшот. Мы можем сделать во время бэкапа снепшот виртуальной машины, зафиксировав ее состояние и сделать копию с этого снепшота. После завершения копирования снепшот объединяется с основным файлом и машина продолжает работать в штатном режиме. Завершать работу или замораживать виртуальную машину в данном случае нет необходимости.

С самими снепшотами тоже есть нюансы. Есть 2 разных типа снепшота. Например, если вы сделаете снепшот qcow2 средствами virt-manager, то удивитесь, не увидев новый файл снепшота. Оказывается, снепшот будет создан внутри qcow2, а файл как был один, так и останется. Это очень неудобно, так как если у вас будет занят весь доступный для файла объем, вы гарантированно получите ошибку при старте вашей виртуалки. А контролировать объем диска, в котором находятся снепшоты трудно и неудобно. И бэкапы в таком случае делать тоже не получится. Хотя получится, но все равно не удобно. Нужно будет отдельными командами конвертировать состояние виртуальной машины до снепшота в отдельный файл и его уже забирать для бэкапа. Плюс ко всему машину в этом случае нужно будет заморозить на момент создания снимка. Заморозка будет кратковременной, но все равно без нее не обойтись. Я приведу для примера команды, которыми это можно делать, но сам я не стал использовать такой способ, потому что, во-первых, не смог найти команды на объединения снепшота и основного файла, во-вторых, меня не устраивает даже кратковременная заморозка системы.

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

Преобразовываем raw обратно в qcow2:

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

В рунете я вообще не нашел информации, как все сделать красиво, удобно и быстро. Нашел инструкцию на официальном сайте libvirt — http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit Дальше фактически будет перевод с моими пояснениями.

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

Мы будем делать снепшот средствами virsh. При этом остановки или заморозки системы не будет вообще. Чтобы этот вариант корректно работал, вам необходимо установить на виртуальную машину qemu-guest-agent. Для этого вам сначала нужно добавить Channel Device по имени org.qemu.guest_agent.0. Проще всего это сделать через virt-manager.

Затем в систему надо установить пакет qemu-guest-agent. Для debian и centos все просто:

Для windows надо с диска virtio-win установить пакет qemu-ga из папки guest-agent, которая находится в корне диска.

Подробнее об установке qemu-guest-agent можно прочитать в документации redhat. Теперь у нас все готово для выполнения живого бэкапа виртуальной машины в kvm без остановки этой виртуалки.

Выполняем снепшот виртуальной машины:

vm-name	имя виртуальной машины
backup-snapshot	название снэпшота, может быть любым
vda	имя диска, для которого указываем адрес снепшота
/snapshot/vm-name-backup.qcow2	путь и имя файла для снепшота

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

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

Когда выполнение бэкапа завершено, объединим снапшот с основным файлом:

После этого файл снэпшота можно удалить:

Для полноты картины забэкапим еще и настройки виртуалки:

И на этом все. Мы сделали полный бэкап работающей виртуальной машины kvm без ее остановки. Сама она даже не поняла, что с ней что-то сделали. Работающие БД на ней не испытывают никаких проблем. Проверял на postgresql. Терминальные сессии в windows server тоже чувствуют себя отлично.

Скрипт для автоматического бэкапа виртуальных машин KVM

По мотивам всего написанного выше я набросал простенький скрипт для автоматического живого бэкапа всех дисков всех работающих в момент выполнения скрипта виртуальных машин. Обращаю внимание, что бэкапятся все диски. Скрипт привожу просто для примера, не используйте его, если вам не нужны полные бэкапы всех дисков. Лично я бэкаплю только небольшие системные диски. Все, что много весит, предпочитаю архивировать другими способами уже изнутри виртуальной машины. Если это базы данных, то делаю бэкапы нужных баз postgresql, если это файловый сервер, то использую rsync для создания инкрементных бэкапов. Ну и так далее. Каждый выбирает средства на свой вкус.

Обращаю внимание на несколько моментов:

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

Снепшоты будут создаваться в той же папке, где хранится основной файл данных. На время отладки советую для начала закомментировать строку с удалением снепшота, на всякий случай. Рекомендую этот крипт прогнать сначала на тестовом сервере. Я его написал на примере одного гипервизора, больше нигде не проверял. Но работает он однозначно, я проверил несколько раз с разными списками VM. В итоге оставил его у себя на сервере в работе.

Для регулярной очистки бэкапов, если они у вас будут храниться где-то в доступном с этого сервера месте, можно добавить в самый конец условие очистки. Для полного бэкапа VM мне видится нормальной схема хранения бэкапов в несколько месяцев, с созданием архивов раз в неделю. Чаще бэкапить системные диски не вижу смысла, там редко бывают ежедневные изменения.

Данная команда удалит все файлы старше 90 дней в папках с названиями виртуальных машин, расположенных в /backup-vm.

Заключение

В начале статьи я сказал, что не встретил готового решения по живому бэкапу kvm. (upd. Уже после публикации статьи мне подсказали готовое решение kvmBackup.) На самом деле это не совсем верно. Есть хорошая готовая сборка на основе kvm — proxmox. Я подробно рассматривал ее в отдельном материале — Установка и настройка proxmox. Но все же это решение конкретного коллектива разработчиков со своими возможностями и ошибками. В проксмокс реализован живой бэкап виртуальных машин из коробки. К сожалению, я не смог быстро найти техническую реализацию их решения. Возможно, все было бы еще проще. Но так тоже ничего получилось.