Bug 1431074

Summary: remote-viewer doesn't open additional monitor in fullscreen mode for Windows7 guest
Product: Red Hat Enterprise Linux 7 Reporter: Andrei Stepanov <astepano>
Component: virt-viewerAssignee: Jonathon Jongsma <jjongsma>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.4CC: dblechte, rbalakri
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1431091 (view as bug list) Environment:
Last Closed: 2017-03-17 21:55:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1064495    
Bug Blocks: 1431091    
Attachments:
Description Flags
remote-viewer --spice-debug --debug none

Description Andrei Stepanov 2017-03-10 10:12:37 UTC
Created attachment 1261894 [details]
remote-viewer --spice-debug --debug

Number of active virtual displays should be synchronized with number of real/physical displays at client during connection in fullscreen mode. This fails if:

1. Guest is Windows7. (bug is not reproducible if guest is RHEL).
and
2. Console to the guest is already opened.
and
3. Client has two real monitors.


virt-viewer-2.0-12.el7.x86_64
or
spice-client-msi-x86-4.1-6.el7ev.noarch
Win7 has installed RHEV-toolsSetup_4.1_4.iso


How reproducible: always


Steps to Reproduce:

Requirements:

Have a client_1.
Have a client_2 with 2 physical monitors.

On client_1:

1. Login to oVirt portal.
2. Connect to Windows7 guest in window mode.
3. Make sure that remote-viewer has one active display.
4. Do not close remote-viewer.

On client_2:

1. Login to oVirt portal.
2. Select VM with Windows7.
3. Edit console options, set: Open in Full Screen == True
4. Connect to VM. 

Actual results: remote-viewer actives only one display.

Expected results: remote-viewer should be active on both displays of client_2.

Additional info:

1. No special mapping config for RV
2. VM is configured for 4 qxl heads
3. This bug easy to reproduce using 1 client with physical monitors. . Just make two sequential connections with RV: 1.RV in window mode with one active virtual display. 2.FS mode.

Comment 2 Jonathon Jongsma 2017-03-14 14:18:22 UTC
I've reproduced it here as well. One thing that looks suspicious in my logs (and is similar in yours above) is the following:

After connecting, the client immediately sends the new monitor configuration to the guest. But when the guest had been connected to a different client at the time of connection, we see the following line in the log soon afterwards:

> (remote-viewer:27113): GSpice-DEBUG: channel-main.c:1582 agent connected: no

It later re-connects to the agent, but this is enough to prevent fullscreen configuration from working properly. This line does not occur when the guest was *not* connected to a different client when we connect.

Comment 3 Jonathon Jongsma 2017-03-14 19:47:34 UTC
It appears that this is caused by the behavior of the Windows vdagent. In order to prevent leaking information (e.g. clipboard contents, etc) between one client and another, the vdagent state must be reset when a client becomes disconnected. The windows and linux vdagents take different approaches to this: The linux agent simply cancels any file transfers and clears all of its data and then waits for the next client to connect. The windows agent, on the other hand, takes a more drastic approach: it simply exits. Since it is registered as a service, it will be automatically restarted, but that can take several seconds. 

This behavior is obviously time-sensitive. When a new client connects to a guest, the server will disconnect the existing client. This will result in a message sent to the vdagent indicating that the client has become disconnected. Soon thereafter, the agent exits, and qemu will inform the spice server. The server will then send a message to the client indicating that the agent has become disconnected. So it will take a variable amount of time between the initial client disconnection and the message that will be sent to the client. This time represents the time when the new client thinks the agent is connected, but it is in fact in the process of shutting down. If the client sends its fullscreen configuration during that time, it will essentially be ignored. The client will think that it did its job, but the configuration will not be applied.

I hadn't remembered until i spent some time digging into this issue, but this same bug actually popped up a while ago (see Bug 1018145). That bug was closed because newer versions of virt-viewer (at the time) were apparently not susceptible to the timing issue mentioned above. We did file bug 1064495 to fix the underlying root cause (the windows vdagent behavior), but it hasn't been fixed yet.

Comment 4 Jonathon Jongsma 2017-03-17 21:55:43 UTC
Since the root cause is in the windows vdagent, and I've now posted a potential fix for bug 1064495, I'm going to close this bug.

*** This bug has been marked as a duplicate of bug 1064495 ***