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) 2. 3. 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.
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.
moving to 3.4 as no blocker flag proposed, never has a pm ack, and we are at RC phase.
I can reproduce this here.
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::0.5.1.0 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.
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: http://cgit.freedesktop.org/spice/win32/vd_agent/commit/?id=e55103589a62460a1128625740ec8c9126adeb64
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.
(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
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. https://rhn.redhat.com/errata/RHSA-2015-0197.html