Windows 7 guests hang on bootup when qxl video is used

Bug #1585008 reported by James Johnston on 2016-05-24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
qemu (Ubuntu)

Bug Description

I installed libvirt-bin and virt-manager on Ubuntu 16.04. I created a new VM for Windows 7, basically with default settings, which includes qxl video.. The Windows boot process hangs with the "Starting Windows" animation. CPU and disk I/O drop to zero, and it continues animating.... forever and ever... It never finishes booting. But it doesn't fully "hang" either: the animation continues to animate.

As a workaround, I set the video mode to "Cirrus" and then Windows boots but it is slow and limited. And also apparently to be avoided:

I can confirm it's only when qxl is enabled, because if I switch from Cirrus back to qxl, it hangs again - and going back to Cirrus again "fixes" the problem.

This issue is also reported elsewhere:


IUC this is not a bug in libvirt or virt-manager or qemu. The problem
is that windows 7 does not ship with the needed qxl drivers. You need
to download those and install them in the windows 7 guest.

James Johnston (mail-codenest) wrote :

I also tested Windows Server 2012 R2 with UEFI / OVMF instead of BIOS. This installed without issue with qxl. The guest just used a generic display driver until I could install the qxl one built by Fedora project.

Shouldn't the Windows 7 guest on BIOS behave the same way? It's kind of hard to install display drivers when you *can't even boot the Windows setup DVD.*

Or are you saying that, by design, qxl can't be used with clients that use generic VGA/VESA display modes? (but how did I get to the point of seeing BIOS load screen, and then "Starting Windows" which is certainly using some kind of VESA mode?)

I'd like to point out that this bug is a regression. I previously installed Win 7 using qxl just as Mr Johnston installed W2012R2, and got the generic drivers until I was able to install qxl drivers. Neither qxl nor stdvga work any more, only cirrus, and that only seems to work under Seabios now, whereas it used to function under OVMF, yes even for Windows 7. As I'm using Arch, and haven't reinstalled Windows 7 every day, I can't say when this bug appeared.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in qemu (Ubuntu):
status: New → Confirmed
Serge Hallyn (serge-hallyn) wrote :

@Anthony - are you saying this affects you under Arch? (If so I'll mark it as affecting upstream qemu project)

Yes, it's an upstream bug. I've verified that it exists under an older version of OVMF, and also with the qemu command line, so it's a qemu or kernel thing, not libvirt or ovmf.

Serge Hallyn (serge-hallyn) wrote :


Downgraded to qemu-2.4.0-1 (on Arch), problem doesn't exist there.

and doesn't exist in qemu-2.5.1-1; the next version I have in Arch is qemu-2.6.0-1, which is the current one where the problem exists. So, something changed between 2.5 and 2.6

Sorry about the multiple posts.

This is a dupe of LP#1581936 and LP#1591724. The issue is fixed by upstream QEMU commit 94ef4f337fb6.

Serge Hallyn (serge-hallyn) wrote :

Thanks - so it's fixed upstream and in ubuntu yakkety. I'll mark it as a dup of bug 1591724.

Changed in qemu (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers