Windows Virtio Drivers

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 Repo

There is a yum 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 -0 /etc/yum.repos.d/virtio-win.repo

Then install the virtio-win package:

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

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. (only on the .iso in build -103 and later)
• guest-agent/: QEMU Guest Agent 32bit and 64bit MSI installers
• qemupciserial/: INF files for QEMU's PCI serial device. More info from qemu.git
• *.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.

Convenience links for the ISOs:

• 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 can be found here:

https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/

Note: these .iso files haves a different file layout then the ones previously hosted at alt.fedoraproject.org

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

TODO

Better version numbers

Right now the RPM and .iso version numbers are rather arbitrarily based on an incrementing number used with the internal Red Hat builds.

Though the upstream KVM driver repo doesn't do formal releases, maybe we can switch version numbers to mirror the upstream git commit the build is derived from. That way interested users can go find a fine grained list of changes.

Better changelogs

The current RPMs don't have much in the way of changelogs. If we use git numbering as suggested above, then we could copy those bits into the RPM changelog. Or possibly grab them from the matching internal RHEL build.

Ship spice agent or spice-guest-tools

Currently the ISO/RPM does distribute the spice agent or spice-guest-tools installer. We probably should

Document how to manually use the drivers

Screenshots, description of non-WHQL issues, .ISO vs .VFD, install time vs already installed OS, etc

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

Links

• KVM windows guest drivers upstream code: https://github.com/YanVugenfirer/kvm-guest-drivers-windows
• QXL XPDM 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