Qemu guest agent что это
Qemu-guest-agent
Contents
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:
Installation
You have to install guest-agent in each VM and then enable it, you can do that in the Proxmox VE Webinterface (GUI)
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:
After that, you have to install the qemu-guest-agent:
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
if the qemu-guest-agent is correctly runnning in the VM, it will return without an error message.
Русские Блоги
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.
Мониторинг связанных операций в процессе создания облачного хоста:
Монитор службы однофазного мониторинга съемки информации и толкатель
Интеллектуальная рекомендация
Gensim Skip-Gram модель для Word2Vec
Встраиваем VSCode в OpenCV IDE (C ++, window10 1803)
Каталог статей вступление окружение шаг 1. Конфигурация Visual Studio Code 2. Конфигурация OpenCV 3. Конфигурация MinGw 4. Конфигурация cmake 5. Конфигурация проекта 6. Ссылка на ссылку В конце концов.
Интеграция и инструменты fastDFS + spring + maven
Основы Linux
Пользователи Linux делятся на два типа: Пользователь суперадминистратора: root, хранится в каталоге / root Обычные пользователи: хранятся в каталоге / home Каталог Linux /: [*] Корневой каталог. Как п.
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-guest-agent на VM в Proxmox
Сегодня расскажу как подключить на виртуальную машину (ВМ) в Proxmox утилиту qemu-guest-agent для просмотра IP-адреса через WEB-интерфейс и правильной завершении работы ВМ.
Что такое qemu-guest-agent
qemu-guest-agent — это вспомогательный демон, который устанавливается в гостевой системе. Он используется для обмена информацией между хостом и гостем, а также для выполнения команды в госте.
В Proxmox VE qemu-guest-agent используется в основном для двух вещей:
Установка qemu-guest-agent
На Proxmox
Вы должны установить гостевой агент в каждой виртуальной машине, а затем включить его, вы можете сделать это в веб-интерфейсе Proxmox VE (GUI).
На виртуальной машине в Linux
В Linux вам нужно просто установить qemu-guest-agent.
Здесь мы покажем команды для систем на базе Debian/Ubuntu и Redhat:
В системах на Debian/Ubuntu выполняем следующие команды:
На системах на базе Redhat:
Настройка qemu-guest-agent
Linux
В зависимости от дистрибутива гостевой агент может не запускаться автоматически после установки. Для запуска воспользуемся следующими командами:
Windows
Сначала вы должны скачать драйвер virtio-win iso (см. Windows VirtIO Drivers).
Затем установите драйвер virtio-serial:
После этого необходимо установить qemu-guest-agent:
После этого qemu-guest-agent должен быть запущен. Вы можете проверить это в списке оконных служб или в PowerShell с помощью:
Если он не запущен, вы можете использовать панель управления Службами, чтобы запустить его и убедиться, что он запустится автоматически при следующей загрузке.
Проверка того, что связь с гостевым агентом работает
если qemu-guest-agent правильно запущен в виртуальной машине, он выдаст пустое сообщения.
Если есть вопросы, то пишем в комментариях.
Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы.
Заранее всем спасибо.
Резервное копирование виртуальных машин в среде гипервизора 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, поскольку хоть агент и «замораживает» все смонтированные ФС за одну команду, однако делает это не одновременно, а последовательно, так что возможна рассинхронизация между томами.
Если вы нашли в статье ошибку, или же вам есть, что сказать — прошу в комментарии.