This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1018145 - --full-screen=auto-conf sometimes (but frequently) doesn't work correctly
--full-screen=auto-conf sometimes (but frequently) doesn't work correctly
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.5.0
Assigned To: Jonathon Jongsma
Desktop QE
Depends On: 1103366
Blocks: 1009648 rhev3.5beta 1156165
  Show dependency treegraph
Reported: 2013-10-11 06:41 EDT by David Jaša
Modified: 2015-02-11 12:43 EST (History)
10 users (show)

See Also:
Fixed In Version: mingw-virt-viewer-0.6.0-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1064495 (view as bug list)
Last Closed: 2015-02-11 12:43:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Jaša 2013-10-11 06:41:45 EDT
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 08:52:59 EST
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 15:47:25 EST
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 15:36:40 EST
I can reproduce this here.
Comment 4 Jonathon Jongsma 2013-12-10 16:40:00 EST
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 16:17:53 EST
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 12:36:13 EST
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 15:44:03 EDT
(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 12:43:16 EST
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.