This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

can you investigate whether the issue appears more often because of vdagent update or client update?

I did before reporting - comment 0 presented in table looks like this:

client \ agent       3.2                   3.3
--------------------------------------------------------------------
3.2                  never                 never
3.3 and RHEL 6.5     sometimes happens     sometimes does not happen

therefore I filed the bug against client components.

is this with happening only with windows guest? (spice-gtk as no notion of primary monitor, so it's quite likely a vdagent bug)

We (Spice QE) don't know for sure as we don't have reliable tools to recognize the primary monitor in RHEL, but some indices such as icons moving to 2nd monitor say that it does happen there, too.

(In reply to David Jaša from comment #5)
> We (Spice QE) don't know for sure as we don't have reliable tools to
> recognize the primary monitor in RHEL, but some indices such as icons moving
> to 2nd monitor say that it does happen there, too.

afaik, xrandr tell you which screen is primary.

needinfo is for about 1 month, so pushing to 6.6 as no blocker flag proposed and it is too late for 6.5.

David Jaša, are you sure this is related to the size of the displays? Also, when the taskbar switches to the other monitor, does the arrangement of the monitors also get switched? (in other words, is the display with the taskbar always aligned to the 'left' of display without the taskbar?)

I can reproduce this primary-switching behavior with e.g. 0.5.6-9 using the following steps, but the relative size of the displays doesn't seem to matter. I suspect that this is the same issue you're describing, and the display size is actually just a red herring:

- start virt-viewer and enable 2 displays
- make sure both virt-viewer windows are at a non-zero X position (e.g. not maximized, not fullscreen, not aligned with the left edge of the screen)
- resize window for display 1 ("primary") => taskbar will switch to display 2
- resize window for display 2 => taskbar will switch back to display 1
- etc.

If this is the same bug from your original report, it is caused by the auto-alignment in spice-gtk and has already been fixed in upstream virt-viewer (we do all display alignment in virt-viewer now and don't depend on spice-gtk to do auto-alignment). If it's not the same issue, getting a debug log from virt-viewer would be useful.

(In reply to Jonathon Jongsma from comment #8)
> David Jaša, are you sure this is related to the size of the displays? Also,
> when the taskbar switches to the other monitor, does the arrangement of the
> monitors also get switched? (in other words, is the display with the taskbar
> always aligned to the 'left' of display without the taskbar?)
> 
> I can reproduce this primary-switching behavior with e.g. 0.5.6-9 using the
> following steps, but the relative size of the displays doesn't seem to
> matter. I suspect that this is the same issue you're describing, and the
> display size is actually just a red herring:
> 
> - start virt-viewer and enable 2 displays
> - make sure both virt-viewer windows are at a non-zero X position (e.g. not
> maximized, not fullscreen, not aligned with the left edge of the screen)
> - resize window for display 1 ("primary") => taskbar will switch to display 2
> - resize window for display 2 => taskbar will switch back to display 1
> - etc.
> 

This is how I usually test the thing. I can confirm that lately, the behaviour is slightly different and it's not coupled to what screen is bigger any more.

> If this is the same bug from your original report, it is caused by the
> auto-alignment in spice-gtk and has already been fixed in upstream
> virt-viewer (we do all display alignment in virt-viewer now and don't depend
> on spice-gtk to do auto-alignment). If it's not the same issue, getting a
> debug log from virt-viewer would be useful.

Based on your description, it sounds like the same issue.

OK, moving to POST for now.

(In reply to Jonathon Jongsma from comment #8)
> and has already been fixed in upstream
> virt-viewer (we do all display alignment in virt-viewer now and don't depend
> on spice-gtk to do auto-alignment). If it's not the same issue, getting a
> debug log from virt-viewer would be useful.

Trying on F20:
virt-viewer-0.5.7-1.fc20.x86_64
spice-gtk-0.21-5.fc20.x86_64

If the "has already been fixed in upstream virt-viewer" applies on versions above, then unfortunately, the bug was not fixed - 2nd resize was just enough to make primary monitor switched (Windows 7 guest).

The fixes for this particular issue went in after 0.5.7, so it's not available in a released version yet, I'm afraid.

*** Bug 1011077 has been marked as a duplicate of this bug. ***

*** Bug 1009018 has been marked as a duplicate of this bug. ***

QE: when verifying, please also verify related scenario from duplicate bug described here: https://bugzilla.redhat.com/show_bug.cgi?id=1009018#c6

Jonathon, please fill the Doc Text. thanks

I can reproduce with virt-viewer-0.5.6-8.el6.x86_64

Verify with virt-viewer-0.6.0-5.el6.x86_64

Steps:
1. Prepare a guest with two displays on rhevm
2. connect the guest in windowed mode
3. Make sure two displays come out.
4. resize the primary display small than another display
5. resize the dispay in step 4 bigger than another display
6. repeat step 4 and step 5 5 times

Result:
Primary display didn't switch to another display

Also test with win7 and windows xp guest.
As the result, VERIFIED

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.

http://rhn.redhat.com/errata/RHBA-2014-1379.html