RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1431074 - remote-viewer doesn't open additional monitor in fullscreen mode for Windows7 guest
Summary: remote-viewer doesn't open additional monitor in fullscreen mode for Windows7...
Keywords:
Status: CLOSED DUPLICATE of bug 1064495
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-viewer
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jonathon Jongsma
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1064495
Blocks: 1431091
TreeView+ depends on / blocked
 
Reported: 2017-03-10 10:12 UTC by Andrei Stepanov
Modified: 2017-03-17 21:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1431091 (view as bug list)
Environment:
Last Closed: 2017-03-17 21:55:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
remote-viewer --spice-debug --debug (51.54 KB, text/plain)
2017-03-10 10:12 UTC, Andrei Stepanov 		no flags Details
View All

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 ***
Note You need to log in before you can comment on or make changes to this bug.