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 1018145 - --full-screen=auto-conf sometimes (but frequently) doesn't work correctly
Summary: --full-screen=auto-conf sometimes (but frequently) doesn't work correctly
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.5.0
Assignee: Jonathon Jongsma
QA Contact: Desktop QE
Depends On: 1103366
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
Reported: 2013-10-11 10:41 UTC by David Jaša
Modified: 2015-02-11 17:43 UTC (History)
10 users (show)

Fixed In Version: mingw-virt-viewer-0.6.0-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1064495 (view as bug list)
Last Closed: 2015-02-11 17:43:16 UTC
oVirt Team: ---
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0197 normal SHIPPED_LIVE Moderate: rhevm-spice-client security and bug fix update 2015-02-11 22:35:16 UTC

Description David Jaša 2013-10-11 10:41:45 UTC
Description of problem:
The monitor auto configuration doesn't work reliably. The reproducers are not 100% yielding different results in otherwise unchanged environment. When there is another client connected and the new client takes over its session, the problems are more likely to occur.
What always works:
1) fullscreening window with existing monitors
2) enabling another guest monitors (when guest monitor count < client monitor count)

What sometimes does work and sometimes doesn't:
3) disabling another guest monitor (when active guest monitor count > client monitor count)
4) when 2 or more guest monitors get enabled at the same time, they get enabled one-by-one and in seemingly random layout that sometime gets fixed afterwards. This causes lots of flicker before things settle down
5) this is not actually a subject of this bug but it may shed a bit more light: when connecting without full screen to a client that was previously run with full-screen=auto-conf, screens 2-4 are displayed in tiny windows (my guesstimate: 50x150)

Based on 4) and the greater odds of hitting the problems when taking over existing session, I'd suspect that --full-screen=auto-conf is actually somehow racy - doing interdependent actions in parallel instead of doing them in one go (or if that is not possible, in order where latter action won't override former one)

Version-Release number of selected component (if applicable):
mingw-virt-viewer-0.5.6-6.el6 @ Windows 7 32b
vdagent-win-3.3-1 @ Windows 7 64b

How reproducible:
sometimes not, frequently yes

Steps to Reproduce:
1. connect with --full-screen=auto-conf to a guest:
    * with more enabled displays than the client has
    * with some client already connected (taking over its session)

Actual results:
  * "redundant" guest monitors don't get disabled
  * it takes quite some time before monitors settle

Expected results:
  * guest display count always matches client monitor count
  * display geometry is reconfigured just once - guest monitors flashes just once and that's it

Additional info:
part of this bug was already described in bug 973664 comment 7.

Comment 1 Marc-Andre Lureau 2013-11-07 13:52:59 UTC
I have not been able to reproduce this issue locally, but I can imagine some of the reasons we still have configuration races over WAN. I would need a remote VM to conduct more testing (that can be arranged easily I guess). This is probably not mingw specific, and although it's quite annoying that it just doesn't work all the time, I think we can minor the relative importance of this bug, since the user should be able to accommodate his configuration manually. So I'd move to 3.4, where we are still working on other multi-monitors bugs.

Comment 2 David Blechter 2013-12-08 20:47:25 UTC
moving to 3.4 as no blocker flag proposed, never has a pm ack,  and we are at RC phase.

Comment 3 Jonathon Jongsma 2013-12-10 20:36:40 UTC
I can reproduce this here.

Comment 4 Jonathon Jongsma 2013-12-10 21:40:00 UTC
From my initial investigation, it seems that the root problem is probably that the windows vdagent gets restarted whenever a client disconnects. So when client B connects to the guest, it disconnects client A which triggers the vdagent to restart itself.

[log excerpt from windows vdagent.log]
2940::INFO::2013-12-10 15:05:26,549::set_displays::Set display mode 0x0
2940::INFO::2013-12-10 15:10:05,893::dispatch_message::Client disconnected, agent to be restarted
2940::INFO::2013-12-10 15:10:05,893::handle_control_event::Control command 0
2940::INFO::2013-12-10 15:10:05,893::run::Agent stopped
288::INFO::2013-12-10 15:10:08,909::run::***Agent started in session 1***
288::INFO::2013-12-10 15:10:08,909::log_version::

But according to the virt-viewer debug logs, client B does actually see the vdagent as connected initially, but then gets a 'agent disconnected' message soon thereafter:

[log excerpt from client]
(virt-viewer:8673): virt-viewer-DEBUG: main channel: opened
(virt-viewer:8673): GSpice-DEBUG: spice-channel.c:1104 main-1:0: channel up, state 2
(virt-viewer:8673): GSpice-DEBUG: spice-session.c:1972 set mm time: 616807192
(virt-viewer:8673): GSpice-DEBUG: spice-session.c:1975 spice_session_set_mm_time: mm-time-reset, old 954421725, new 616807192
(virt-viewer:8673): GSpice-DEBUG: channel-main.c:1375 agent connected: yes
(virt-viewer:8673): GSpice-DEBUG: spice-gtk-session.c:464 clipboard_get_targets:
(virt-viewer:8673): GSpice-DEBUG: spice-gtk-session.c:464 clipboard_get_targets:
(virt-viewer:8673): GSpice-DEBUG: channel-main.c:1375 agent connected: no
(virt-viewer:8673): GSpice-DEBUG: spice-channel.c:127 usbredir-9:0: spice_channel_constructed
(virt-viewer:8673): virt-viewer-DEBUG: New spice channel 0x263ac00 SpiceUsbredirChannel 0
(virt-viewer:8673): GSpice-DEBUG: spice-channel.c:127 record-6:0: spice_channel_constructed
(virt-viewer:8673): virt-viewer-DEBUG: New spice channel 0x2633180 SpiceRecordChannel 0
(virt-viewer:8673): GSpice-DEBUG: spice-channel.c:127 playback-5:0: spice_channel_constructed
(virt-viewer:8673): virt-viewer-DEBUG: New spice channel 0x26c2000 SpicePlaybackChannel 0
(virt-viewer:8673): virt-viewer-DEBUG: new audio channel
(virt-viewer:8673): GSpice-DEBUG: spice-channel.c:127 cursor-4:3: spice_channel_constructed
(virt-viewer:8673): virt-viewer-DEBUG: New spice channel 0x26c9c90 SpiceCursorChannel 3
(virt-viewer:8673): GSpice-DEBUG: spice-channel.c:127 display-2:3: spice_channel_constructed
(virt-viewer:8673): virt-viewer-DEBUG: New spice channel 0x26cc7c0 SpiceDisplayChannel 3

Then some time later, we get a notification that the agent is again connected.  Perhaps virt-viewer attempts to do auto-conf in the ~3 seconds between the time that the agent disappears and re-appears again. That would probably explain some of the racy-ness. Investigation continues.

Comment 5 Jonathon Jongsma 2013-12-11 21:17:53 UTC
After initially reproducing this bug, I had quite a bit of trouble re-reproducing it.  But I finally managed to. I can reproduce the racy behavior with e.g. the remote-viewer version from rhel6.  But I cannot reproduce it with virt-viewer from git master.  The way that fullscreen auto-conf is done has changed quite a lot upstream, so I'm quite sure that virt-viewer is no longer susceptible to this particular issue. Unfortunately the changes to this particular functionality touch quite a bit of code, so backporting a patch for this issue may not be trivial.

However, It seems to me that it's not necessarily desirable for the windows vdagent to restart itself upon client disconnection. Especially when the client disconnection is caused by another client connection, this will inevitably be a bit racy. The Linux vdagent does not behave this way -- it simply cleans up some things such as the clipboard / file transfers, etc when a client disconnects. So perhaps it would be useful to re-assign this to the windows vdagent to change this behavior?

FYI, here's the commit that caused the windows agent to restart itself on client disconnections:

Comment 6 Jonathon Jongsma 2013-12-12 17:36:13 UTC
Since upstream virt-viewer isn't susceptible to this issue, I'm moving this to POST, and we can re-test it after we re-base.

Comment 7 David Blechter 2014-04-17 19:44:03 UTC
(In reply to Jonathon Jongsma from comment #6)
> Since upstream virt-viewer isn't susceptible to this issue, I'm moving this
> to POST, and we can re-test it after we re-base.

We'll re-base in in the next release, moving to 3.5

Comment 10 errata-xmlrpc 2015-02-11 17:43:16 UTC
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.

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