This is directory listing for a user on Fedora People. You can read more about Fedora People here.
This is a community maintained site. Red Hat is not responsible for content. File a ticket if this contains anything that is not permitted.
Name Last modified Size Description
Parent Directory - CHECKSUM 2024-08-06 03:26 0 archive-qemu-ga/ 2025-04-07 09:24 - archive-virtio/ 2025-04-07 09:24 - latest-qemu-ga/ 2025-04-07 09:24 - latest-virtio/ 2025-04-07 09:26 - stable-virtio/ 2025-04-07 09:26 - upstream-virtio/ 2024-06-03 00:22 - virtio-win-pkg-scripts-input/ 2025-04-07 09:24 -
Contents
- 1 Overview
- 2 Yum|Dnf Repo
- 2.1 RPM contents
- 2.2 ISO contents
- 3 Direct download
- 4 FAQ
- 4.1 What license are these drivers?
- 4.2 Why aren’t the drivers shipped as part of Fedora?
- 4.3 Where do the builds come from?
- 4.4 What is the reasoning behind the RPM/ISO layout?
- 4.5 Are these drivers signed?
- 4.6 How are these drivers different from what is shipped with RHEL?
- 4.7 How does lack of WHQL signature affect use of these drivers?
- 5 Bugs
- 6 Links
Overview
This page describes how to obtain and use virtio drivers for Windows virtual machines running on KVM, and additional software agents for Windows VMs.
Yum|Dnf Repo
There is a yum|dnf repo shipping ‘virtio-win’ RPMs. The RPMs install driver binaries and agent installers on your host machine into /usr/share. These bits can then be shared with Windows VMs.
Install the repo file:
sudo wget https://fedorapeople.org/groups/virt/virtio-win/virtio-win.repo -O /etc/yum.repos.d/virtio-win.repo
Then install the virtio-win package with DNF or YUM:
sudo dnf install virtio-win sudo yum install virtio-win
The .repo file provides two different repositories:
- virtio-win-stable
- This provides builds of virtio-win that roughly correlates to what was shipped with the most recent RHEL release, meaning they have received a decent chunk of testing.
- This repo is enabled by default.
- virtio-win-latest
- This provides the latest driver builds. They may be development quality, or bug free, or complete broken. Caveat emptor
- This repo is disabled by default. If you want to update from virtio-win-stable to the latest bits, do:
sudo yum --enablerepo=virtio-win-latest update virtio-win
- This provides the latest driver builds. They may be development quality, or bug free, or complete broken. Caveat emptor
or with dnf: sudo dnf --enablerepo=virtio-win-latest upgrade virtio-win
RPM contents
- /usr/share/virtio-win/*.iso: ISO CDROM containing all the drivers. See details below
- /usr/share/virtio-win/*.vfd: VFD floppy images for using during install of Windows XP
- /usr/share/virtio-win/drivers: Copy of the extracted VFD driver contents
- /usr/share/guest-agent/*.msi: QEMU Guest Agent 32bit and 64bit MSI installers
ISO contents
The .iso contains the following bits:
- NetKVM/: Virtio Network driver
- viostor/: Virtio Block driver
- vioscsi/: Virtio SCSI driver
- viorng/: Virtio RNG driver
- vioser/: Virtio serial driver
- Balloon/: Virtio Memory Balloon driver
- qxl/: QXL graphics driver for Windows 7 and earlier. (build virtio-win-0.1.103-1 and later)
- qxldod/: QXL graphics driver for Windows 8 and later. (build virtio-win-0.1.103-2 and later)
- pvpanic/: QEMU pvpanic device driver (build virtio-win-0.1.103-2 and later)
- guest-agent/: QEMU Guest Agent 32bit and 64bit MSI installers
- qemupciserial/: QEMU PCI serial device driver
- *.vfd: VFD floppy images for using during install of Windows XP
Direct download
Direct downloads are available for the .iso, .vfd, and qemu-ga installers.
- Stable virtio-win iso: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso
- Stable virtio-win x86 floppy: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win_x86.vfd
- Stable virtio-win amd64 floppy: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win_amd64.vfd
- Latest virtio-win iso: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso
- Latest virtio-win x86 floppy: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win_x86.vfd
- Latest virtio-win amd64 floppy: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win_amd64.vfd
- Latest qemu-ga files: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-qemu-ga/
- Full archive: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/
- Changelog: https://fedorapeople.org/groups/virt/virtio-win/CHANGELOG
If you previously used isos from alt.fedoraproject.org, note that these new isos have a different file layout (matching RHEL isos). If you need to access the old isos you can do so here. However these isos are deprecated and only kept around for back compatability. No new isos will be added there.
FAQ
What license are these drivers?
The drivers are licensed under the GPLv2.
Why aren’t the drivers shipped as part of Fedora?
The drivers cannot be shipped as part of Fedora because they can’t be built in Fedora’s build system; the only way to build the drivers is on a Windows machine. Shipping pre-compiled sources is generally against Fedora policies. There’s likely other objections as well.
Where do the builds come from?
All the windows binaries are scooped up from builds done on Red Hat’s internal build system, which are generated using publicly available code.
See the README in this repo for some more details about how the RPM and repo are built: https://github.com/crobinso/virtio-win-pkg-scripts
What is the reasoning behind the RPM/ISO layout?
For starters, the primary purpose of the RPM/ISO is to mirror exactly the layout that is shipped with the latest RHEL release. This is so user/developers don’t have to deal with differences between the two distros.
(Note: Historically the .iso files shipped on alt.fedoraproject.org did _not_ match the layout of the .iso shipped in RHEL. This changed in April 2015)
- The .iso directories are named after the driver code directories from the upstream driver git tree. There isn’t much more to it than that.
- Below the driver directories, the $winversion/$arch/ directory naming is a windows convention.
- The RPM layout is kind of arbitrary in that it ships the .vfd content in the drivers/ dir, but not many of the other drivers from the .iso. This seems to be an historical oversight and should probably be fixed.
Are these drivers signed?
These drivers are cryptographically signed with Red Hat’s vendor signature. However they are not signed with Microsoft’s WHQL signature.
How are these drivers different from what is shipped with RHEL?
The RPMs from the stable repository are the same driver builds as what is shipped in RHEL. However, the public drivers are not signed with Microsoft’s WHQL signature.
How does lack of WHQL signature affect use of these drivers?
FIXME: Lack of WHQL signature causes windows to complain, need to explicitly document how
Bugs
Please file any bug reports against Product=Virtualization Tools Component=virtio-win
When filing a bug, please provide the following info:
- The virtio-win version
- The host distro
- The qemu version
- If using libvirt: sudo virsh dumpxml $vmname
- The qemu command line. If using libvirt this can be found at /var/log/libvirt/qemu/$vmname.log
Questions/Comments about the RPMs or yum|dnf repos should be sent to regular fedora virt locations: https://fedoraproject.org/wiki/Virtualization#Mailing_list_and_IRC
Questions/Comments about the actual drivers are probably best send to the upstream qemu-devel or kvm mailing lists
Links
- KVM windows guest drivers upstream code: https://github.com/YanVugenfirer/kvm-guest-drivers-windows
- QXL XDDM driver code: http://cgit.freedesktop.org/spice/win32/qxl
- QXL WDDM driver code: https://github.com/vrozenfe/qxl-dod
- Tree used by gnome-boxes for automatic driver installation: https://zeenix.fedorapeople.org/drivers/
- Windows spice agent git repo: http://cgit.freedesktop.org/spice/win32/vd_agent
- Spice guest tools installer code: http://cgit.freedesktop.org/~teuf/spice-nsis/
- spice-guest-tools downloads: http://www.spice-space.org/download/binaries/spice-guest-tools/
- Fedora virtio-win build scripts: https://github.com/crobinso/virtio-win-pkg-scripts
Windows VirtIO Drivers
The source for the Windows drivers is hosted in a repository on GIT hub. Anonymous users can clone the repository
git clone git://github.com/virtio-win/kvm-guest-drivers-windows.git
Browse GIT repository online
Binary Drivers
Binary drivers are provided by some Linux distributions including WHQL Certified drivers.
For example the binary drivers for Ubuntu can be found here.
64-bit versions of Windows Vista and newer (this currently includes Windows Server 2008, Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012) require the drivers to be digitally signed to load.
If your distribution does not provide binary drivers for Windows, you can use the package from the Fedora Project. These drivers are digitally signed, and will work on 64-bit versions of Windows:
Latest VirtIO drivers for Windows from Fedora
Code signing drivers for the Windows 64bit platforms
- Drivers should be signed for Windows 64bit platforms.
- Here are some links how to self sign and install self signed drivers:
- Installing Test-Signed Driver Packages
- How to Release-Sign File System Drivers
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.
В данной статье мы подробно рассмотрим как правильно настроить систему виртуализации KVM/libvirt в Fedora и установим в качестве гостевой ОС Microsoft Windows 10.
Введение
Многие пользователи для запуска виртуальных машин до сих пор предпочитают использовать VirtualBox, поэтому в данной статье мы решили рассмотреть альтернативу, имеющую ряд серьёзных преимуществ:
- нет необходимости в установке out-of-tree модулей ядра, т.к. они уже входят в его состав;
- корректная работа на конфигурациях с активной технологией UEFI Secure Boot;
- более быстрая работа гипервизора за счёт отсутствия необходимости переключения между режимами ядра и пользователя.
Первым делом установим ряд необходимых пакетов:
sudo dnf install libvirt qemu-kvm virt-manager
По окончании активируем автоматическую загрузку сервиса libvirtd при помощи systemd:
sudo systemctl enable --now libvirtd.service
Внимание! Сразу после этого действия может отключиться текущее сетевое соединение из-за изменения в конфигурации адаптеров и появления новых виртуальных. Это нормальное явление. Именно по этой причине не следует пытаться установить KVM через SSH подключение.
Перезагрузим систему:
sudo systemctl reboot
Выбор режима работы KVM
KVM поддерживает работу в двух режимах:
- системный сеанс — qemu:///system — виртуальные машины будут запускаться с повышенными правами от имени пользователя libvirt с полноценной поддержкой сети и общими для всех пулами данных;
- пользовательский сеанс — qemu:///session — виртуальные машины будут запускаться с правами текущего пользователя с индивидуальным пулом и поддержкой сети при помощи qemu-bridge.
Более полное сравнение можно найти здесь (на английском языке).
Системный сеанс считается enterprise-ready решением, а пользовательский наиболее безопасным.
Настройка системного сеанса KVM
Настройка прав доступа
Для работы с виртуальными машинами внутри системного сеанса необходимо состоять в особой группе libvirt, поэтому добавим нашу основную учётную запись в неё:
sudo usermod -a -G libvirt $(whoami)
Создание подключения к пулу
Запустим Менеджер виртуальных машин (virt-manager) из меню используемой графической среды.
Если в списке отсутствует пункт QEMU/KVM, добавим его, вызвав диалог создания нового подключения через меню Файл — Добавить соединение.
В поле Гипервизор выберем пункт QEMU/KVM, затем установим флажок в чекбокс Подключаться автоматически и нажмём Подключиться. Новый пункт появится в списке как показано на скриншоте выше.
Создание каталогов для образов
По умолчанию предлагается использовать каталог /var/lib/libvirt/images для хранения дисковых образов виртуальных машин, однако место внутри корневого раздела у большинства ограничено, поэтому мы создадим новое на отдельном разделе диска.
Внимание! Для системного сеанса не следует указывать в качестве хранилища каталоги, расположенные внутри /home, т.к. SELinux настроен на полную блокировку доступа к домашним каталогам пользователей для любых системных сервисов и по этой причине гипервизор не сможет работать с ними.
В главном окне менеджера выделим пункт QEMU/KVM, затем в меню Правка выберем пункт Свойства подключения и переключимся на вкладку Пространство данных.
Создадим новый раздел диска, отформатируем его в любую поддерживающую Unix-права доступа файловую систему (рекомендуется ext4 или xfs), пропишем в /etc/fstab и смонтируем например в качестве /media/virt.
Перейдём в созданный раздел и создадим два каталога: images для дисковых образов виртуальных машин и iso для ISO образов, из которых будет производиться установка операционных систем:
sudo mkdir /media/virt/{images,iso}
sudo chown $(whoami):libvirt /media/virt/{images,iso}
В левой панели окна менеджера пространств данных нажмём кнопку Добавить пул (с символом плюс).
В поле Название для пула с дисковыми образами укажем images, Тип — каталог в файловой системе, а Target Path — каталог на диске (в нашем случае — созданный ранее /media/virt/images). Нажмём Готово и пул появится в списке. Подтвердим сохранение изменений.
Повторим то же самое, но для ISO образов:
- название — iso;
- target path — /media/virt/iso.
Если всё сделано верно, в левой панели появятся два новых пула — images и iso. Выберем каждый и убедимся, что в чекбоксе Автозапуск при загрузке установлен флажок. Если это не так, исправим и нажмём Применить.
Пул с именем default теперь допускается удалить, хотя это и не обязательно. Для этого выберем его, нажмём кнопку Остановить пул, а затем Удалить пул и подтвердим намерение.
На этом базовая настройка завершена и можно приступать к установке гостевых операционных систем.
Настройка пользовательского сеанса KVM
Создание подключения к сеансу
Запустим Менеджер виртуальных машин (virt-manager) из меню используемой графической среды.
В главном окне менеджера виртуальных машин, нажмём правой кнопкой мыши по QEMU/KVM, затем в контекстном меню выберем вариант Отключиться и Удалить. Подтвердим удаление.
В меню Файл выберем Добавить соединение.
В поле Гипервизор выберем пункт QEMU/KVM сеанс пользователя, затем установим флажок в чекбокс Подключаться автоматически и нажмём Подключиться. Новый пункт появится в списке.
Создание каталогов для образов
По умолчанию предлагается использовать каталог ~/.local/share/libvirt/images для хранения дисковых образов виртуальных машин, однако для удобства мы создадим новые.
Это опциональное действие. Можно использовать пул default для любых целей.
В главном окне менеджера выделим пункт QEMU/KVM сеанс пользователя, затем в меню Правка выберем пункт Свойства подключения и переключимся на вкладку Пространство данных.
Создадим два каталога: images для дисковых образов виртуальных машин и iso для ISO образов, из которых будет производиться установка операционных систем:
mkdir -p ~/virt/{images,iso}
В левой панели окна менеджера пространств данных нажмём кнопку Добавить пул (с символом плюс).
В поле Название для пула с дисковыми образами укажем images, Тип — каталог в файловой системе, а Target Path — каталог на диске (в нашем случае — созданный ранее ~/virt/images). Нажмём Готово и пул появится в списке. Подтвердим сохранение изменений.
Повторим то же самое, но для ISO образов:
- название — iso;
- target path — ~/virt/iso.
Если всё сделано верно, в левой панели появятся два новых пула — images и iso. Выберем каждый и убедимся, что в чекбоксе Автозапуск при загрузке установлен флажок. Если это не так, исправим и нажмём Применить.
Пул с именем default теперь допускается удалить, хотя это и не обязательно. Для этого выберем его, нажмём кнопку Остановить пул, а затем Удалить пул и подтвердим намерение.
Настройка сети в пользовательском сеансе
Создадим сетевой мост для виртуальных машин:
sudo nmcli con add type bridge autoconnect yes ifname virbr0 ipv4.method shared ipv4.address 192.168.122.1/24
Добавим основное проводное соединение в качестве ведущего для моста:
sudo nmcli con add type bridge-slave autoconnect yes ifname enp3s0 master virbr0
Здесь вместо enp3s0 укажем физический интерфейс проводного соединения (может быть получен из вывода nmcli device status).
Разрешим использование моста в qemu-bridge-helper:
echo allow virbr0 | sudo tee -a /etc/qemu/bridge.conf
Добавим правила для файрвола:
sudo firewall-cmd --zone libvirt --add-interface virbr0 --permanent sudo firewall-cmd --zone libvirt --add-service dhcp --permanent sudo firewall-cmd --zone libvirt --add-service dhcpv6 --permanent sudo firewall-cmd --zone libvirt --add-service dns --permanent sudo firewall-cmd --reload
На этом настройка пользовательского сеанса завершена и можно приступать к установке гостевых операционных систем.
Подготовка к установке
Для установки нам потребуются:
- официальный ISO образ операционной системы Windows 10, который можно скачать с официального сайта Microsoft (30-дневная пробная версия);
- ISO образ с набором драйверов Virtio для гостевых операционных систем;
- образ дискеты с драйверами Virtio для ранней стадии установки.
Скачаем указанные образы, скопируем их в каталог /media/virt/iso (системный сеанс), либо ~/virt/iso (пользовательский сеанс).
Создание гостевой ОС Windows 10
На главной панели инструментов нажмём кнопку Создать виртуальную машину или выберем одноимённый пункт из меню Файл.
В появившемся окне мастера на первом шаге выберем пункт Локальный ISO или cdrom.
На втором шаге мастера нажмём кнопку Обзор, выберем из списка загруженный ранее ISO образ и нажмём Выбор тома.
Оставляем флажок в чекбоксе Automatically detect from installation media/source, чтобы Virt Manager самостоятельно подобрал оптимальные параметры для виртуальной машины и жмём Вперёд.
Указываем выделяемый виртуальной машине объём оперативной памяти и количество ядер процессора.
Теперь создадим локальный дисковый образ для гостевой ОС.
Установим флажок в чекбокс Настроить пространство хранения данных, а также точку около пункта Выбрать или создать дополнительное пространство данных и нажмём кнопку Настроить.
В левой панели переключимся на пул images, затем нажмём кнопку Создать том.
Создадим новый том для гостевой ОС:
- название — любое, но без пробелов и русских букв;
- формат — qcow2;
- максимальный размер — не менее 40 ГБ.
Выберем созданный том в списке и нажмём кнопку Выбор тома.
На заключительном шаге мастера будет предложено указать название для виртуальной машины (пробелы и русские буквы также не допускаются).
Обязательно установим флажок в Проверить конфигурацию перед установкой и нажмём Готово.
Настройка гостевой ОС Windows 10
Мы не будем подробно описывать все параметры конфигурации гостевой ОС, а лишь остановимся лишь на самых важных, от правильной установки которых зависит успех всей нашей задачи.
Переключимся на страницу SATA диск 1, выберем пункт Дополнительные параметры и изменим шину диска с SATA на VirtIO.
Здесь же допускается явно задать серийный номер накопителя, который будет передан гостевой ОС (если не указано, то генерируется автоматически), а также включить поддержку процедуры TRIM в случае если хранилище было создано на SSD накопителе.
Нажмём кнопку Добавить оборудование, выберем тип Хранилище.
Изменим Тип устройства на Устройство чтения дискет, затем установим точку в Выбрать или создать дополнительное пространство данных и нажмём кнопку Настроить.
В появившемся окне переключимся на пул iso, выберем образ дискеты, нажмём Выбор тома, а затем Готово.
Переключимся на страницу Видео и в поле Модель убедимся, что установлено значение QXL. Если это не так, внесём правки.
Все остальные параметры оставим по умолчанию и нажмём кнопку Начать установку.
Установка гостевой Windows 10
Запускаем стандартную установку данной ОС, выбираем редакцию, вводим или пропускаем (для получения 30 дневной пробной версии) серийный номер, принимаем лицензионное соглашение с конечным пользователем, затем Выборочная установка ибо нам требуется создать разделы на диске и установить драйвер VirtIO для ранней стадии загрузки системы.
Когда появится сообщение об ошибке о том, что не удалось загрузить драйверы, нажмём кнопку Загрузить, а затем в появишемся окне разрешим автоматический поиск при помощи нажатия OK.
Укажем версию драйвера Red Hat VirtIO SCSI controller для Windows 10 и нажмём Далее.
С этого момента программа установки наконец обнаружит наш виртуальный накопитель и предложит создать разделы, а затем установить на него операционную систему.
Далее весь процесс установки вполне стандартный и описывать его мы не будем.
Установка драйверов Virtio гостевой ОС
По окончании установки сразу завершаем работу виртуальной машины (Пуск — Выключение), нажимаем кнопку Показать виртуальное оборудование на панели инструментов, переходим на страницу SATA CDROM 1, жмём Browse и внутри пула iso выбираем ISO-образ с гостевыми драйверами Virtio.
Применим изменения, а затем перейдём на страницу Дисковод 1, нажмём кнопку Удалить и Применить, т.к. он более нам не требуется.
На панели инструментов нажмём кнопку Показать графическую консоль, а затем Включить виртуальную машину.
Откроем Проводник Windows, перейдём на виртуальный CD диск D: и запустим программу установки virtio-win-gt-x64.exe.
Выберем рекомендуемые Red Hat компоненты.
Разрешим установку драйверов с цифровой подписью Red Hat, нажав Установить.
Установка гостевых дополнений SPICE
Для того, чтобы в гостевой ОС появилась полная поддержка обмена данными с буфером обмена хостовой ОС, динамическое изменение разрешения виртуального дисплея и т.д., установим внутри гостя пакет SPICE Guest Tools по прямой ссылке.
Запустим скачанный файл и выполним установку всех предложенных по умолчанию компонентов, включая дополнительные драйверы виртуального дисплея QXL. Перезагрузим виртуальную машину для вступления изменений в силу.
Установка окончена.