Description of problem:
spice-gtk shows outdated screen state after migration.
Version-Release number of selected component (if applicable):
client RHEL 7.2:
host RHEL 7.2:
guest RHEL 7.1 & 7.2:
Gnome-shell desktop environment, KMS driver
Steps to Reproduce:
1. run an application for some time
2. close the application
3. migrate the VM
1. after migration, an old screen state is displayed for few dozen of seconds. when movement of some currently-existing window occurs, parts of ghost window start disappearing
2. after some time, the screen readjusts to the current state
3. after repeated migration, old screen state is displayed again
no caching artifacts occur
Created attachment 1045535 [details]
Example. What I did is:
0. connection established, migration started
1. started screencast
2. minimized Firefox in the guest (0:02)
3. migration finished, Firefox's guest appeared (0:13)
4. click into the desktop that pretends to be Firefox triggers update (0:20)
5. end of screencast
* Without click in point 4., the stale image would linger far longer.
* happens with rhel7 client and guest against rhel7 and fedora hosts, rhel6 wasn't tested (yet), no other guest was tested (yet)
Where does this stale image came? Was it before the screencast?
Created attachment 1118554 [details]
screencast including admin portal
(In reply to Frediano Ziglio from comment #2)
> Where does this stale image came? Was it before the screencast?
Yes, it's what was on the screen ~1 m before the migration. The bug is still present as of RHEL 7.2 (all of client/host/guest) as you can see in this full screencast (client and portal):
0:10 start of migration with static desktop
0:13 window layout change
0:24 migration finished, layout from before 0:13 is shown till desktop redraw
0:31 resuming video playback
0:44 start of another migration
1:03 (approx.) video gets choppy, migration gets stuck (bug 1247237)
1:07 video is paused, migration finishes, client displays pre-0:13 state again
With upstream git code running on a Fedora-23 host:
I can reproduce with Fedora-23 guest.
But works-for-me with Windows 7 guest.
RHEL 7 guest status @ 7.2 host:
7.0/KMS, 7.2/KMS - affected
7.2/UMS - not affected
I think the problem is in qemu-kvm, specifically reverting
commit e25139b34d27847ff19140adada77ea4c5398863 seems to solve this problem.
Moving to qemu-kvm component
(In reply to Uri Lublin from comment #6)
> I think the problem is in qemu-kvm, specifically reverting
> commit e25139b34d27847ff19140adada77ea4c5398863 seems to solve this problem.
> Moving to qemu-kvm component
Gerd, please take a look.
Author: Yonit Halperin <firstname.lastname@example.org>
Date: Wed Feb 15 11:22:15 2012 +0200
qxl: set only off-screen surfaces dirty instead of the whole vram
We used to assure the guest surfaces were saved before migration by
setting the whole vram dirty. This patch sets dirty only the areas
that are actually used in the vram.
Signed-off-by: Yonit Halperin <email@example.com>
Signed-off-by: Gerd Hoffmann <firstname.lastname@example.org>
(In reply to Ademar Reis from comment #7)
> (In reply to Uri Lublin from comment #6)
> > I think the problem is in qemu-kvm, specifically reverting
> > commit e25139b34d27847ff19140adada77ea4c5398863 seems to solve this problem.
> > Moving to qemu-kvm component
> Gerd, please take a look.
> commit e25139b34d27847ff19140adada77ea4c5398863
> Author: Yonit Halperin <email@example.com>
> Date: Wed Feb 15 11:22:15 2012 +0200
> qxl: set only off-screen surfaces dirty instead of the whole vram
> We used to assure the guest surfaces were saved before migration by
> setting the whole vram dirty. This patch sets dirty only the areas
> that are actually used in the vram.
> Signed-off-by: Yonit Halperin <firstname.lastname@example.org>
> Signed-off-by: Gerd Hoffmann <email@example.com>
Doesn't handle primary surfaces correctly in case they are living in vram not ram. Thats why it happens with newer (kms) linux guests only, all other guest drivers place the primary surface in ram.
Fix included in qemu-kvm-rhev-2.6.0-15.el7
Reproduce this issue with qemu-kvm-rhev-2.6.0-14.el7.x86_64.
Guest used: rhel7.3 guest
Follow steps in comment 1, I record a video reproducer
Verified with qemu-kvm-rhev-2.6.0-20.el7.x86_64, also record a video to show bug fixed
Created attachment 1200197 [details]
Created attachment 1200198 [details]
bug fix video
Move to verified per comment 12 & 13 &14
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
*** Bug 1130356 has been marked as a duplicate of this bug. ***