--- Additional comment from email@example.com 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 firstname.lastname@example.org on 2010-04-26 18:57:33 EDT ---
cf discussion about qemu vnc bug
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
Patch series submitted upstream
Patch series committed upstream
bcao --> berrange
For the first bug ,I want to reproduced on qemu-kvm-0.12.1.2-2.64.I 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?
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.
Run 10 times on qemu-kvm-0.12.1.2-2.48.el6.
2.# virsh start RHEL6_64 on the host and almost at the same time ,start #virt-viewer RHEL6_64.
testing 10 times,virt-viewer works fine .
2.on the host terminal ,#virt-viewer --wait RHEL6_64
3.on the host terminal ,#virst start RHEL6_64.
Also test 10 times ,virt-viewer works fine.
Retest on qemu-kvm-0.12.1.2-2.109.el6.
Repeat the steps above .virt-viewer also works fine.
I still can not reproduced it.Are the steps above correct? If correct,May I close this issue?
This should be sufficient test hit the problem.
According to comment #12, Change status to VERIFIED. If any time hit the issue again,I will re-test it.
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.