QEMU is the Quick EMUlator, an open source virtualization solution. Many easy solutions include VMware or VirtualBox but QEMU has its own advantages, particularly the ability to emulate an architecture different than what is running. However, QEMU, when configured wrong, can massively underperform if it emulates instead of taking advantage of virtualization features. Nevertheless, QEMU mastery elevates one's 1337-ness over peers.

QEMU is often used by other hypervisor packages like oVirt, OpenNebular, and Proxmox. Those solutions greatly simplify using QEMU. It's also possible to just use QEMU natively and interacting with it through the Libvirt API. Utilizing QEMU with Linux virtual machines typically works much smoother than Windows virtual machines. Questions abound across forums and help exchanges on how to get the Windows virtual machines to be fully accessible like their Linux counterparts. Fortunately, the solution isn't too hard once you know what to do.

Getting the VM Ready

As with all virtual solutions, the hypervisor provides not only a virtualized hardware environment but also some virtual devices aimed to provide a backchannel for control. Naturally, device drivers are necessary to make that work. With QEMU, there are two particular devices that matter.

qemu devices to install

Whereas Linux distributions typically have the QEMU drivers baked into their standard repositories, Windows does not. Some packaged solutions leveraging QEMU may include Windows drivers on a .iso image file, but a barebones QEMU installation doesn't include anything.

Not including them as largely a function of modern Windows security measures requiring signed drivers. There really isn't a way for the casual user to compile their own QEMU drivers from source and sign them. Nor is it really feasible for most repositories to keep rolling new signed instances with code updates. Fortunately, RedHat maintains a github repository of signed binary drivers available in a variety of installable formats (.iso, .msi, etc) available at https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md.

In addition to the drivers, a QEMU guest agent can also be installed. The guest agent provides useful functionality to communicate with the hypervisor so that a given virtual machine could be gracefully shutdown or have status information reported on a dashboard (e.g. IP address, CPU use, uptime, etc.)

Getting the Hypervisor Ready

Technically, everything works fine. It's just a question of whether there's a need for the hypervisor to interact with the underlying virtual machine. For Linux virtual machines, the hypervisor is automatically configured with the appropriate settings. This does not seem to happen automatically for Windows virtual machines. The configurations are maintained in separate XML files generally stored at /etc/libvirt/qemu.

The problem is simple, the XML configuration file for Windows hosts does not reflect a communications "channel" to utilize the virtual "serial device" that qemu-ga uses to communicate with the hypervisor. Although tempting to just edit the XML file directly, a header at the top advises those local edits may be lost. However, it's easy to edit with the virsh utility.

<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit win10
or other application using the libvirt API.
-->

The first step is to use virsh in order enumerate the virtual machines being managed. Once the desired virtual machine is identified, virsh can be used to launch the appropriate text editor (usually vim or nano ... nobody likes emacs cultists). Virtual machines can be referenced using either an ID number or their name.

virsh list --all

 Id   Name             State
---------------------------------
 1    win10            running
 2    win11            running
 3    winxp            running
 -    centos-stream9   shut off
 -    debian13         shut off
 -    rocky9           shut off
 -    ubuntu24.04      shut off

virsh edit win11

There are three parts necessary in the XML file for the Hypervisor to actually communicate with the virtual machine. Often, two of them are correctly populated. The first defines the virtio-serial, virtual serial port, which serves as the communication link. It's usually automatically present and can be found in the <devices> section after the pci and sata block. But if missing, simply insert this block.

    <controller type="virtio-serial" index="0">
      <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
    </controller>

The second block that is usually automatically present is the spicevnc channel block. This one serves to allow a virtual console to the underlying VM. SPICE is more feature-rich method than the older VNC for remotely accessing a host. Once again, if missing, simply insert this block.

    <channel type="spicevmc">
      <target type="virtio" name="com.redhat.spice.0"/>
      <address type="virtio-serial" controller="0" bus="0" port="2"/>
    </channel>

The missing block is usually the unix channel which utilizes the virtual serial port to pass commands and receive data from the VM. Copy this missing block into the file editor. A good place to put the missing section is either above or below the spicevnc section.

    <channel type="unix">
      <target type="virtio" name="org.qemu.guest_agent.0"/>
      <address type="virtio-serial" controller="0" bus="0" port="1"/>
    </channel>

What "Right" Looks Like

Once in place, the hypervisor can now communicate with the underlying Windows virtual machine for common management tasks. It might be necessary to reboot the virtual machine in order to ensure a proper synchronization of configurations between the hypervisor and the qemu-ga. From the command line, virsh reboot VMNAME handles the task.

The Easy Way

Naturally, after fighting through the system and finding the XML configuration files, etc, I did find the solution was much more obvious if you want to click around with the virt-manager GUI. So for the less 1337 solution:

• Click "Add Hardware" at the bottom of the device list
• Click "Channel" in the left pane's device list
• Select "org.qemu.guest_agent.0" in the name dropdown
• Select "UNIX socket(unix)" in the device type dropdown

Add Hardware The Easy Way	Add The Missing Channel

This GUI method achieves the same goal - adding the missing channel and having it utilize the virtual serial device. As you revel in your functioning QEMU connectivity with the hypervisor, just pretend you used the command line when telling your friends how you fixed it.