Bug 1129477 - Add ability for user to configure which guest monitors are used in fullscreen mode
Summary: Add ability for user to configure which guest monitors are used in fullscreen...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-viewer
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Virt Viewer Maint
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 957593 1009648 1129479
TreeView+ depends on / blocked
 
Reported: 2014-08-12 20:57 UTC by Jonathon Jongsma
Modified: 2016-05-17 15:20 UTC (History)
12 users (show)

Fixed In Version: virt-viewer-0.6.0-10.el7
Doc Type: Enhancement
Doc Text:
It is now possible to configure the position in which guest displays in multi-monitor setups. To do so, edit the ~/.config/virt-viewer/settings file. For more information about this feature, refer to the CONFIGURATION section of the remote-viewer(1) manual page.
Clone Of:
: 1129479 (view as bug list)
Environment:
Last Closed: 2015-03-05 13:39:40 UTC


Attachments (Terms of Use)
screen shot when connect the guest (2.49 MB, image/png)
2014-09-18 03:36 UTC, CongDong
no flags Details
click leave fullscreen with display list (2.13 MB, image/png)
2014-09-18 03:37 UTC, CongDong
no flags Details
virt-viewer with spice-debug log (127.74 KB, text/plain)
2014-09-18 03:38 UTC, CongDong
no flags Details
log for comment 16 (109.40 KB, text/plain)
2014-09-28 02:49 UTC, CongDong
no flags Details
screenshot for comment 16 (2.17 MB, image/png)
2014-09-28 02:50 UTC, CongDong
no flags Details
virt-viewer + spice-gtk debug log (130.31 KB, text/plain)
2014-10-08 11:20 UTC, David Jaša
no flags Details
screenshot (1.08 MB, image/png)
2014-10-08 11:22 UTC, David Jaša
no flags Details
irt-viewer + spice-gtk debug log (better) (64.58 KB, text/plain)
2014-10-08 13:13 UTC, David Jaša
no flags Details
Screenshot for comment 33 (2.08 MB, image/png)
2014-10-10 08:52 UTC, CongDong
no flags Details
virt-viewer log with spice-debug for comment 33 (74.82 KB, text/plain)
2014-10-10 08:56 UTC, CongDong
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0295 normal SHIPPED_LIVE virt-viewer bug fix and enhancement update 2015-03-05 17:33:00 UTC

Description Jonathon Jongsma 2014-08-12 20:57:27 UTC
Currently, when virt-viewer / remote-viewer is started in fullscreen mode, we attempt to place a fullscreen guest dislay on each local monitor. It should be possible for the user to customize this behavior

Comment 1 Jonathon Jongsma 2014-08-12 21:00:01 UTC
Support is upstream.

Relevant commits:
b684a76fa4147ecf5c241476d9c362cfff404c29
539e6724374f22194d38bcab876e48e97517b843
0ca9959f00d4970b4398d48b77fd3f08f78a1855

Comment 3 CongDong 2014-09-18 03:35:41 UTC
I test with virt-viewer-0.6.0-5.el7.x86_64:

1. Prepare a spice guest with qxl
#virsh dominfo test
Id:             5
Name:           test
UUID:           d004a4c8-9d71-46d3-9bcc-28ad9eed8df5
OS Type:        hvm
...
2. edit ~/.config/virt-viewer/settings
# vim ~/.config/virt-viewer/setting
[d004a4c8-9d71-46d3-9bcc-28ad9eed8df5]
monitor-mapping=1:3;2:4;3:2

3. start the guest and login it, configure it with only one display
# virsh start test
#virt-viewer test
Click View -> Display -> just enable display

4. reconnect the guest with -f
# virt-viewer test -f

Result:
Only monitor 3 and 4 have display, but the resolution is small, and two displays are same, the displays are mirror screens.
Click "Leave full screen" button, check the display list:
View -> Displays. only display 1 and display 3 are enabled.

The result is not expected as the settings file.
There should be 3 displays on monitor 3, 4, 2.

I will add the screen shot later.

Xrandr for host:
Screen 0: minimum 320 x 200, current 5520 x 1050, maximum 16384 x 16384
DisplayPort-0 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
HDMI-0 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1152x864       75.0  
   1280x720       60.0     50.0     59.9  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   720x480        60.0     59.9  
   640x480        75.0     60.0     59.9  
   720x400        70.1  
DVI-0 connected 1680x1050+2560+0 (normal left inverted right x axis y axis) 474mm x 296mm
   1680x1050      60.0*+   74.9  
   1600x1000      60.0  
   1280x1024      75.0     72.0     60.0  
   1440x900       75.0     59.9  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0  
   800x600        72.2     75.0     60.3  
   640x480        75.0     72.8     66.7     60.0  
   720x400        70.1  
DVI-1 connected 1280x1024+4240+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1

Comment 4 CongDong 2014-09-18 03:36:40 UTC
Created attachment 938735 [details]
screen shot when connect the guest

Comment 5 CongDong 2014-09-18 03:37:44 UTC
Created attachment 938737 [details]
click leave fullscreen with display list

Comment 6 CongDong 2014-09-18 03:38:20 UTC
Created attachment 938738 [details]
virt-viewer with spice-debug log

Comment 7 Jonathon Jongsma 2014-09-18 16:00:46 UTC
CongDong, I wonder if you're hitting another problem (possibly bug 1046458?).

If you remove monitor-mapping configuration for this guest, and then re-run 

  virt-viewer test -f

What is the behavior? Does it successfully enable fullscreen windows for all 4 displays?

Comment 8 Jonathon Jongsma 2014-09-18 16:23:53 UTC
According to the log, it appears that virt-viewer is behaving correctly:

(virt-viewer:7567): virt-viewer-DEBUG: Fullscreen config: mapping guest display 0 to monitor 2
(virt-viewer:7567): virt-viewer-DEBUG: Fullscreen config: mapping guest display 1 to monitor 3
(virt-viewer:7567): virt-viewer-DEBUG: Fullscreen config: mapping guest display 2 to monitor 1

...

(virt-viewer:7567): GSpice-DEBUG: channel-main.c:1176 main-1:0: monitor config: #0 1680x1050+2560+0 @ 32 bpp
(virt-viewer:7567): GSpice-DEBUG: channel-main.c:1176 main-1:0: monitor config: #1 1280x1024+4240+0 @ 32 bpp
(virt-viewer:7567): GSpice-DEBUG: channel-main.c:1176 main-1:0: monitor config: #2 1280x1024+1280+0 @ 32 bpp


So I think that the issue is that the guest is not being configured correctly due to some other bug. I'm interested in your results if you only define 1 or 2 displays.  For example:

monitor-mapping=1:3
monitor-mapping=1:3;2:4


(note that the display indices in the log are 0-based, whereas the indices in the config file are 1-based)

Comment 9 CongDong 2014-09-19 02:57:23 UTC
(In reply to Jonathon Jongsma from comment #7)
> CongDong, I wonder if you're hitting another problem (possibly bug 1046458?).
> 
> If you remove monitor-mapping configuration for this guest, and then re-run 
> 
>   virt-viewer test -f
> 
> What is the behavior? Does it successfully enable fullscreen windows for all
> 4 displays?

Ah, it's just one display.
So I re-configure the vm:
# virsh edit $vm
<domain type='kvm' id='5' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <qemu:commandline>
    <qemu:arg value='-global'/>
    <qemu:arg value='qxl-vga.vgamem_mb=32'/>
  </qemu:commandline>
</domain>

It shows 4 displays when I disable monitor-mapping this time.

I enable monitor-mapping again:
[d004a4c8-9d71-46d3-9bcc-28ad9eed8df5]
monitor-mapping=1:3;2:4;3:2

# virt-viewer test -f
Three displays come out, display 1 on monitor 3, but display 2 and 3 are all on monitor 4.

If configure monitor-mapping with two displays:
monitor-mapping=1:3;2:4
It works well.

After that I configure monitor-mapping with only one display:
monitor-mapping=1:3

Only one display comes out, but with a very large resolution(but I think the resolution is another problem)

Comment 11 Jonathon Jongsma 2014-09-24 15:23:40 UTC
Additional related commits:

f317e950969738783919ea7d7f3a2fa9ddd44c3b
f26a5fe16cc5d71a3edad17026ab35411286b140

Comment 15 Jonathon Jongsma 2014-09-26 19:34:05 UTC
Hi CongDong,

Can you get a new spice debug log for the latest package (and describe exactly what happens when you're collecting the log)?

Comment 16 CongDong 2014-09-28 02:49:12 UTC
(In reply to Jonathon Jongsma from comment #15)
> Hi CongDong,
> 
> Can you get a new spice debug log for the latest package (and describe
> exactly what happens when you're collecting the log)?

Steps:

 - # virsh start $vm
 - # virt-viewer $vm  and enable 4 displays
     Click "View-> displays -> check on (1,2,3,4) display"
     Close virt-viewer
 - # edit settings file like this
     [9a38373c-bc18-407a-9468-39eb4b1ca9a5]
     monitor-mapping=1:3;2:4
 - # virt-viewer -f $vm --debug --spice-debug

Result:
monitor 3 and monitor 4 are used.
But display 3 and display 1 are at monitor 3
display 4 and display 2 are at monitor 4.

I'll add the spice log and screenshot later

Comment 17 CongDong 2014-09-28 02:49:56 UTC
Created attachment 941931 [details]
log for comment 16

Comment 18 CongDong 2014-09-28 02:50:51 UTC
Created attachment 941932 [details]
screenshot for comment 16

Comment 20 Jonathon Jongsma 2014-10-01 21:33:23 UTC
which version of spice-gtk3 are you testing with?

Comment 21 Jonathon Jongsma 2014-10-07 17:18:36 UTC
OK, after some more extensive testing, I have the following observations:

A. I am not ever able to reproduce the behavior described by CongDong (e.g. display 3 and display 1 on monitor 3, display 2 and display 4 on monitor 4)

B. I am able to reproduce something slightly similar  *if and only if* the guest has more monitors enabled than are specified in the config file: display 1 fullscreen on monitor 3, display 2 fullscreen on monitor 4, displays 3&4 on monitor 1 (but not in fullscreen). The frequency of occurrence depends partly on the spice-gtk version. With spice-gtk 0.20, it happens quite often, but with spice-gtk 0.22, it happens perhaps 5% of the time that the conditions mentioned above are met (enabled guest displays > configured displays).

C. When the issue mentioned in (B) occurs, I cannot see any difference in the behavior of the client compared to the times when the issue does not occur. So it seems to be a bug or race condition in the guest/server rather than a bug in the client.

D. I am not able to reproduce the issue *at all* with a windows guest, which suggests that it is probably a bug in the RHEL guest.


Based on my observations, the following seems to be true: with spice-gtk 0.22, the bug only occurs quite rarely, and only when we connect to a rhel guest that currently has more displays enabled than are specified in the config file. If your experience is different than this, please let me know. Otherwise it seems that we should file a new bug to track the race condition in the guest where displays fail to get configured properly

Comment 22 CongDong 2014-10-08 05:40:17 UTC
(In reply to Jonathon Jongsma from comment #20)
> which version of spice-gtk3 are you testing with?

spice-gtk3-0.22-2.el7.x86_64

I'll do more test with the latest version.

BTW, what's the OS of your rhel guest?

Comment 23 David Jaša 2014-10-08 11:20:41 UTC
Created attachment 944945 [details]
virt-viewer + spice-gtk debug log

Scratch build is not available anymore so testing just with what is in nightlies:
virt-viewer-0.6.0-7.el7.x86_64
spice-gtk3-0.22-2.el7.x86_64

The guest display 2 and 3 are on client monitor 4 where only guest display 2 should be (guest 3 should be on client 2 where there is no virt-viewer window).

Comment 24 David Jaša 2014-10-08 11:22:43 UTC
Created attachment 944946 [details]
screenshot

(In reply to David Jaša from comment #23)
> Created attachment 944945 [details]
> virt-viewer + spice-gtk debug log
> 
> Scratch build is not available anymore so testing just with what is in
> nightlies:
> virt-viewer-0.6.0-7.el7.x86_64
> spice-gtk3-0.22-2.el7.x86_64
> 
> The guest display 2 and 3 are on client monitor 4 where only guest display 2
> should be (guest 3 should be on client 2 where there is no virt-viewer
> window).

picture is worth 1000s of words

Comment 26 David Jaša 2014-10-08 13:13:50 UTC
Created attachment 944989 [details]
irt-viewer + spice-gtk debug log (better)

(In reply to David Jaša from comment #23)
> Created attachment 944945 [details]
> virt-viewer + spice-gtk debug log

better log (with cleared irrelevant top)

Comment 27 Jonathon Jongsma 2014-10-08 16:45:38 UTC
(In reply to David Jaša from comment #26)
> Created attachment 944989 [details]
> irt-viewer + spice-gtk debug log (better)
> 
> (In reply to David Jaša from comment #23)
> > Created attachment 944945 [details]
> > virt-viewer + spice-gtk debug log
> 
> better log (with cleared irrelevant top)

OK, so David's issue is a bit different as well. The guest is enabling the correct number of displays, and (apparently) sizing them correctly, but apparently the client is not placing them on the correct client monitor. I think I need some better logging to figure out why. Is this 100% reproducible?

Comment 28 Jonathon Jongsma 2014-10-08 16:48:11 UTC
(In reply to CongDong from comment #22)
> (In reply to Jonathon Jongsma from comment #20)
> > which version of spice-gtk3 are you testing with?
> 
> spice-gtk3-0.22-2.el7.x86_64
> 
> I'll do more test with the latest version.
> 
> BTW, what's the OS of your rhel guest?

I've tested with both rhel6 and rhel7 guests. Both of them behave basically as I've mentioned in comment #21, although rhel7 seems to exhibit the issue mentioned in (B) more often, even with spice-gtk 0.22 (but still, only when extra displays are enabled in the guest when connecting)...

Comment 29 David Jaša 2014-10-09 14:53:16 UTC
> but apparently the client is not placing them on the correct client monitor.
> I think I need some better logging to figure out why. Is this 100%
> reproducible?

Yes.



Jonathon, would it be able to rearrange guest monitor layout as well to match client layout? E.g.:

monitor-mapping=1:2;2:1 with client layout:

+---+---+
| 1 | 2 |
+---+---+

will produce also guest layout:

+---+---+
| 1 | 2 |
+---+---+

leading to non-contiguous guest desktop in fullscreen:

+------------+-----------+
|------+     |  +--------|
|INDOW |     |  | GUEST W|
|------+     |  +--------|
+------------+-----------+

so the guest layout should be:

+---+---+
| 2 | 1 |
+---+---+


The fix to this issue shouldn't however make bug 1018180 regress.

Comment 30 Jonathon Jongsma 2014-10-09 16:23:41 UTC
Hello David,

I was not able to reproduce your non-contiguous guest desktop mentioned above. I tested this configuration and I did find a bug that was initially causing both client windows to end up on the same monitor. I've posted a patch to the virt-tools mailing list to fix this issue [1]. After fixing this issue, It behaves as you expect it to: 

+---+---+
| 2 | 1 |
+---+---+


[1] https://www.redhat.com/archives/virt-tools-list/2014-October/msg00069.html

Comment 31 Jonathon Jongsma 2014-10-09 17:03:12 UTC
(In reply to Jonathon Jongsma from comment #30)
> Hello David,
> 
> I was not able to reproduce your non-contiguous guest desktop mentioned
> above. I tested this configuration and I did find a bug that was initially
> causing both client windows to end up on the same monitor. I've posted a
> patch to the virt-tools mailing list to fix this issue [1]. After fixing
> this issue, It behaves as you expect it to: 
> 
> +---+---+
> | 2 | 1 |
> +---+---+
> 
> 
> [1]
> https://www.redhat.com/archives/virt-tools-list/2014-October/msg00069.html

Sorry, it turns out that I was testing with upstream virt-viewer, rather than the rhel7 version, which is why I didn't reproduce your issue. I will investigate further. Some additional patches from upstream may need to be backported.

Comment 32 Jonathon Jongsma 2014-10-09 17:07:31 UTC
> Sorry, it turns out that I was testing with upstream virt-viewer, rather
> than the rhel7 version, which is why I didn't reproduce your issue. I will
> investigate further. Some additional patches from upstream may need to be
> backported.

I should clarify that this comment only applies to the testing I did in comment #30. Previously I was testing with the rhel7 build.

Comment 33 CongDong 2014-10-10 08:49:32 UTC
I retest with virt-viewer-0.6.0-7.el7.x86_64
spice-glib-0.22-2.el7.x86_64
spice-gtk3-0.22-2.el7.x86_64

Steps:
1. Prepare a rhel7 guest
# virsh dominfo rhel7.0
Id:             4
Name:           rhel7.0
UUID:           b87cc000-5725-4830-b201-602ce1ea8d6f
OS Type:        hvm
State:          running
...

2. Edit setting file:
# cat settings
#rhel7.0

[b87cc000-5725-4830-b201-602ce1ea8d6f]
monitor-mapping=1:3;2:4;3:2

3. # virt-viewer rhel7.0 -f

Result:
Display 1 is on Monirot 3, display 2 and 3 are on monitor 4, can check in screenshot.

As the result, assigned

Comment 34 CongDong 2014-10-10 08:52:20 UTC
Created attachment 945527 [details]
Screenshot for comment 33

Comment 35 CongDong 2014-10-10 08:56:23 UTC
Created attachment 945529 [details]
virt-viewer log with spice-debug for comment 33

Comment 36 Jonathon Jongsma 2014-10-14 15:12:08 UTC
(In reply to David Jaša from comment #29)
> > but apparently the client is not placing them on the correct client monitor.
> > I think I need some better logging to figure out why. Is this 100%
> > reproducible?
> 
> Yes.
> 
> 
> 
> Jonathon, would it be able to rearrange guest monitor layout as well to
> match client layout? E.g.:
> 
> monitor-mapping=1:2;2:1 with client layout:
> 
> +---+---+
> | 1 | 2 |
> +---+---+
> 
> will produce also guest layout:
> 
> +---+---+
> | 1 | 2 |
> +---+---+
> 
> leading to non-contiguous guest desktop in fullscreen:
> 
> +------------+-----------+
> |------+     |  +--------|
> |INDOW |     |  | GUEST W|
> |------+     |  +--------|
> +------------+-----------+
> 
> so the guest layout should be:
> 
> +---+---+
> | 2 | 1 |
> +---+---+
> 
> 
> The fix to this issue shouldn't however make bug 1018180 regress.


Hi David,

I've looked into this particular issue a little bit, but haven't come up with a solution yet. The one thing that I have concluded is that this does not appear to be a virt-viewer/remote-viewer issue. We are sending down the right configuration, but for some reason the guest is not being configured properly. 

Sent by client:

(remote-viewer:14047): GSpice-DEBUG: ../../gtk/channel-main.c:1078 main-1:0: monitor config: #0 1280x720+1280+0 @ 32 bpp
(remote-viewer:14047): GSpice-DEBUG: ../../gtk/channel-main.c:1078 main-1:0: monitor config: #1 1280x720+0+0 @ 32 bpp

Received from guest:

(remote-viewer:14047): GSpice-DEBUG: ../../gtk/channel-display.c:1734 display-2:0: monitor id: 0, surface id: 0, +0+0-1280x720
(remote-viewer:14047): GSpice-DEBUG: ../../gtk/channel-display.c:1734 display-2:0: monitor id: 1, surface id: 0, +1280+0-1280x720


Notice the difference in x-offsets. In the request, display 0 is +1280 and display 1 is +0. In the response, display 0 is +0 and display 1 is +1280. Somehow these got swapped. 

Can you open a new bug for this issue?

Comment 37 Christophe Fergeau 2014-10-15 07:38:18 UTC
This might be a mutter issue I've been spending some time in the last weeks.

Comment 38 Jonathon Jongsma 2014-10-15 22:00:23 UTC
There seem to be 2 or 3 different bugs being discussed here, and only one of them is a client bug. I've filed new bugs for the non-client bugs.

1. windows don't get placed on the correct monitor (this bug)

2. extra displays don't get disabled on the guest (filed new Bug 1153372)

3. guest displays are not aligned properly as mentioned in comment 29 (filed new Bug 1153377)


Unfortunately, I've so far been unable to reproduce issue #1...

Comment 39 David Jaša 2014-10-24 12:03:52 UTC
virt-viewer-0.6.0-10 works for me.

Comment 41 CongDong 2014-10-27 07:32:30 UTC
VERIFIED with virt-viewer-0.6.0-10.el7

Steps:
1. prepare a spice guest, and configure the guest :
# virsh dumpxml $vm
<domain type='kvm' id='5' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <qemu:commandline>
    <qemu:arg value='-global'/>
    <qemu:arg value='qxl-vga.vgamem_mb=32'/>
  </qemu:commandline>
</domain>

2. edit setting file
# cat ~/.config/virt-viewer/settings
[e022993f-2ec3-4de3-8806-75e9dc6bde63]
monitor-mapping=1:4
3. #virt-viewer -f
4, repeat with setting file like:
 - 1:4;2:3;
 - 1:3;2:4;3:2
 - 1:2;2:4;3:1;4:3
 - 1:1;2:1(invalid)
 - 1:2;2:b(invalid)
 - 1:3;a:2(invalid)

Result:
display can be placed to the right monitor with right resolution.
For invalid setting, can report the warning msg:
 - 1:1;2:1
(virt-viewer:22598): virt-viewer-WARNING **: Invalid monitor-mapping configuration: a display or monitor id was specified twice
 - 1:2;a:2
(virt-viewer:20886): virt-viewer-WARNING **: Invalid monitor-mapping configuration: display id is invalid: a 0x143fdf0='a'
 - 1:3;2:b
(virt-viewer:22258): virt-viewer-WARNING **: Invalid monitor-mapping configuration: monitor id 'b' is invalid


Also test with two monitors. 

As the result, VERIFIED this bug.

Comment 46 errata-xmlrpc 2015-03-05 13:39:40 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.

https://rhn.redhat.com/errata/RHBA-2015-0295.html


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