Qemu kvm windows guest

KVM/QEMU Windows guest drivers (virtio-win)

This repository contains KVM/QEMU Windows guest drivers, for both paravirtual and emulated hardware. The code builds and ships as part of the virtio-win RPM on Fedora and Red Hat Enterprise Linux, and the binaries are also available in the form of distribution-neutral ISO and VFD images. If all you want is use virtio-win in your Windows virtual machines, go to the Fedora virtIO-win documentation for information on obtaining the binaries.

If you’d like to build virtio-win from sources, clone this repo and follow the instructions in Building the Drivers. Note that the drivers you build will be either unsigned or test-signed with Tools/VirtIOTestCert.cer, which means that Windows will not load them by default. See Microsoft’s driver signing page for more information on test-signing.

If you want to build cross-signed binaries (like the ones that ship in the Fedora RPM), you’ll need your own code-signing certificate. Cross-signed drivers can be used on all versions of Windows except for the latest Windows 10 with secure boot enabled. However, systems with cross-signed drivers will not receive Microsoft support.

If you want to produce Microsoft-signed binaries (fully supported, like the ones that ship in the Red Hat Enterprise Linux RPM), you’ll need to submit the drivers to Microsoft along with a set of test results (so called WHQL process). If you decide to WHQL the drivers, make sure to base them on commit eb2996de or newer, since the GPL license used prior to this commit is not compatible with WHQL. Additionally, we ask that you make a change to the Hardware IDs so that your drivers will not match devices exposed by the upstream versions of KVM/QEMU. This is especially important if you plan to distribute the drivers with Windows Update, see the Microsoft publishing restrictions for more details.

How to properly configure Virt-Manager (QEMU/KVM) with Windows guest

I’m currently switching to Virt-Manager (QEMU/KVM) and leave VirtualBox behind (as it is slow), but I find Virt-Manager hard to configure. In VBox and VMware, all you have to do is install the guest additions, then everything will work including the display, folder sharing, etc..

I would like to have a Windows guest (either 7 or 10) with at least a working network, display drivers, and folder sharing. Setting a Filesystem passthrough does not seem to work in Windows guests (and I also got sick and tired of trying Samba to work).

What’s the proper way to create a Windows guest with working display and sharing? Maybe I missed some dependencies or Virt-Manager specific settings?

«How to» guides I followed:

I tried the nautilus-share , and the manual /etc/samba/smb.conf configuration, and try to mount the folder in guest OS with \\IP.ADDRESS\SHARED_FOLDER , but nothing worked.

Sadly, no 3D acceleration support for Windows guest. Guess I’ll just stick to VirtualBox/VMware for now.

For future reference, here’s my fully working Network, Display, and Folder Sharing QEMU/KVM setup on Ubuntu-based 18.04 LTS (specifically, Pop! OS 18.04). Initially, I’m using the Android Emulator for development with KVM installed. So, then I decided to switch from VBox and VMware to Virt-Manager for OS testing, and primarily, for softwares I used in Windows, since it also target Kernel-based VMs and is faster.

Setup

1. Install and verify KVM:

Needs restart to work properly.

2. Install Red Hat Virtual Machine Manager:

3. Create Windows VM:

I use dynamically allocated QCOW2 storage format:

with VirtIO-type Storage and Network (requires VirtIO drivers):

Include VirtIO drivers image file:

4. Windows guest installation:

Load VirtIO Storage and Network drivers (and proceed to standard installation):

For the Network driver, you’ll probably don’t see any listed drivers while loading it during installation. This occurred to me when I use NAT in network interface, but not in Bridge mode. If that’s the case, then you can manually update the driver later on.

5. Install and configure Samba for basic public folder sharing over network:

Install Samba on host OS:

Add a basic public folder config:

Append the following lines:

Restart Samba service (or perform a full reboot ):

You can then map the folder in Windows guest with \\ \Public :

6. Download the SPICE guest tools for Display and other VirtIO drivers, etc..

You can then use the public shared folder to install it to the Windows guest OS.

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

Краткое описание команд есть в файле qga/qapi-schema.josn в исходниках QEMU, а полное можно получить путем анализа файлов qga/commands-posix.c и qga/commands-win32.c. Из анализа можно, например, узнать, что команды guest-set-vcpus, guest-get-vcpus, guest-network-get-interfaces, guest-suspend-hybrid, guest-suspend-ram, guest-suspend-disk под Windows не поддерживаются, а команды guest-fsfreeze-freeze/guest-fsfreeze-thaw пытаются под Windows использовать теневое копирование тома — VSS. Однако, поскольку в статье речь пойдет о Linux в качестве гостя, нас эти тонкости касаться не будут.

Среди всего списка команд нас интересуют 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 надо править исходные коды соответствующих продуктов, что выходит за рамки этой статьи.

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

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

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