Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 590070 - QEMU misses DESKTOP-RESIZE event if it is triggered during client connection initialization
Summary: QEMU misses DESKTOP-RESIZE event if it is triggered during client connection ...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-07 16:14 UTC by Daniel Berrange
Modified: 2013-01-09 22:33 UTC (History)
5 users (show)

Fixed In Version: qemu-kvm-
Doc Type: Bug Fix
Doc Text:
Clone Of: 586074
Last Closed: 2010-11-10 21:24:51 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Daniel Berrange 2010-05-07 16:14:00 UTC
--- Additional comment from on 2010-04-26 14:24:59 EDT ---

I have finally reproduced this problem with virt-viewer too. There are two bugs involved.

 1. The root cause is that QEMU is forgetting to send a DESKTOPRESIZE message if the guest resizes the guest at the time the VNC connection is still in its setup phase. This is incredibly unlikely to occur, unless your VNC client happens to connect at exactly the time the guest resizes its display. Unfortunately when a guest first boots there are typically 2-3 resizes from BIOS to GRUB to guest OS. With virt-manager automagically opening connections when a guest starts the odds of hitting the QEMU flaw are non-trivial

 2. GTK-VNC is not checking the bounds of the framebuffer updates against its known framebuffer size. Thus it tries to draw a 720x400 pixel image on a 600x480 pixel window. X gets unhappy, sends back an XError and GTK gives up & aborts the whole process.

I'm going to fix GTK-VNC to check update boundaries & close the VNC connection if it gets an out of bounds update. virt-manager should auto-reopen the VNC connection and all will likely be well since its past the resize. I'm also going to take the QEMU problem upstream.

--- Additional comment from on 2010-04-26 18:57:33 EDT ---

cf discussion about qemu vnc bug

Comment 1 RHEL Product and Program Management 2010-05-07 16:31:27 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Gerd Hoffmann 2010-06-01 19:59:37 UTC
Patch series committed upstream

Comment 9 Mike Cao 2010-08-16 10:30:55 UTC
bcao --> berrange

Hi, Daniel

For the first bug ,I want to reproduced on qemu-kvm- try several times .but can not catch the time that vnc client connect at exactly the time the guest resizes its display.Could you tell me how to reproduce it ?

For the second bug,As your words "it tries to draw a 720x400 pixel image on a
600x480 pixel window. X gets unhappy," Could you tell me how to reproduce this manually?


Comment 10 Daniel Berrange 2010-08-16 11:11:01 UTC
You just have to run 'virt-viewer $GUEST' very quickly after starting the guest with virsh start. It might help to run 'virt-viewer --wait $GUEST' immediately *before* starting the guest.

Comment 11 Mike Cao 2010-08-17 08:27:54 UTC
Run 10 times on qemu-kvm-

steps: virt-manager.
2.# virsh start RHEL6_64 on the host and almost at the same time ,start #virt-viewer RHEL6_64.

Actual Results:
testing 10 times,virt-viewer works fine .

steps: virt-manager.
2.on the host terminal ,#virt-viewer --wait RHEL6_64
3.on the host terminal ,#virst start  RHEL6_64.
Actual Results:
Also test 10 times ,virt-viewer works fine.

Retest on qemu-kvm-
Repeat the steps above .virt-viewer also works fine.


Hi, Daniel
I still can not reproduced it.Are the steps above correct? If correct,May I close this issue?


Comment 12 Daniel Berrange 2010-08-17 09:56:04 UTC
This should be sufficient test hit the problem.

Comment 13 Mike Cao 2010-08-17 10:44:54 UTC
According to comment #12, Change status to VERIFIED. If any time hit the issue again,I will re-test it.

Comment 14 2010-11-10 21:24:51 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.