Bug 1365717

Created attachment 1189546 [details]
debug & spice debug for the issue

From the debug:
(virt-viewer:19659): virt-viewer-DEBUG: Performing full screen auto-conf, 2 host monitors
(virt-viewer:19659): virt-viewer-DEBUG: Set SPICE display 0 to (0,0)-(1920x1080)
(virt-viewer:19659): virt-viewer-DEBUG: Set SPICE display 1 to (1920,0)-(1920x1080)
(virt-viewer:19659): GSpice-DEBUG: channel-main.c:1160 main-1:0: sending new monitors config to guest
(virt-viewer:19659): GSpice-DEBUG: channel-main.c:1177 main-1:0: monitor #0: 1920x1080+0+0 @ 32 bpp
(virt-viewer:19659): GSpice-DEBUG: channel-main.c:1177 main-1:0: monitor #1: 1920x1080+1920+0 @ 32 bpp
....
(virt-viewer:19659): GSpice-DEBUG: channel-display.c:1713 display-2:0: received new monitors config from guest: n: 2/4
(virt-viewer:19659): GSpice-DEBUG: channel-display.c:1733 display-2:0: monitor id: 0, surface id: 0, +0+0-1920x1080
(virt-viewer:19659): GSpice-DEBUG: channel-display.c:1733 display-2:0: monitor id: 1, surface id: 0, +1920+120-1280x960


There is a race, virt-viewer sends correct size request, but the guest also sends its current display config. It is not a regression, mostlikely changes will be required in other spice components. Lets investigate it for 7.4.

Moving to rhel 8

Take

Take

So, this is in fact caused by a change in mutter. That change happened here:
 - https://gitlab.gnome.org/GNOME/mutter/commit/183f4b0c13f3dc9565bf5f693f2e5d61ca0199c9
 - https://bugzilla.gnome.org/show_bug.cgi?id=783073

Some background:
Some time in the past, spice guest resolution changes were handled by spice-vdagent. The spice client sent a monitor configuration message to the server, the server passed it to the vdagent, and the vdagent used the xrandr APIs to reconfigure the display resolution. This caused problems because there were two different components that could change the guest's display resolution: 1) the desktop environment (responding to hotplug events, resizing due to explicit requests via the control panel) and 2) spice-vdagent (handling spice monitor config messages). These could sometimes interfere with eachother and cause conflicts. Around the time of RHEL7, this was changed so that the spice vdagent no longer had responsibility for changing the resolution of the guest. Instead, monitor configuration messages from spice were handled by passing the message from the spice server directly to the QXL device. The QXL device would then update its preferred mode (resolution) and emit a hotplug event within the guest OS. To support this, the desktop environment (GNOME/mutter) was changed to respond to these hotplug events and resize the guest resolution to match the new preferred mode of the QXL device. In order for this to work properly, It was necessary to make the desktop environment ignore the monitor resolution configuration file (saved in ~/.config/monitors.xml). 

Why was it necessary to bypass the configuration file? Well, this configuration file was designed with the assumption that if the user explicitly configures the resolution for a particular monitor, the user will always want the desktop to be set to this same resolution when using that particular monitor. This assumption works well when we're talking about physical monitors, because they generally have a single specific native resolution. However, the QXL device is quite different than a physical monitor. The "native" resolution of the QXL device will change whenever the spice server sends it a monitor config message (i.e. whenever the user resizes the window of their spice client display). Assuming that the user wants to continue using the previous resolution for this monitor after it has changed size doesn't really make sense, and in fact prevents the automatic resize feature from working at all. The way that the desktop environment (mutter) determines that the device can change size is via the 'hotplug_mode_update" udev property. Therefore, mutter ignored the monitors.xml configuration file whenver we were using a device with 'hotplug_mode_update'.

Sometime in the past year, apparently somebody made a change to this logic and started using the local configuration file for hotplug_mode_update devices, but only when first logging into the desktop (see links mentioned above). Presumably they had a good reason for doing this, but the effect is that it restores the previously-set resolution for this device rather than simply using the 'native' resolution of the device at login. This is not such a big deal when the client is viewing the spice display in windowed mode: the client window simply gets resized. But when the client is viewing the spice display in fullscreen mode, the window can no longer be resized, and so it ends up displaying a scaled up or scaled down version of the desktop.

It is my opinion that the mutter change mentioned above is misguided, and perhaps should be reverted. The bug report that caused the change was justified because they said that the existing behavior "causes the saved monitor settings not to be properly recovered". But it's not obvious to me that we *want* to recover saved monitor settings for monitors (such as the QXL device) that may have a different 'native' resolution based on the size of your client window. It seems a lot friendlier to me to just allow the desktop to always use the preferred resolution rather than trying to restore a previous setting that may not even work well with the monitors of the client machine that you're currently connecting from.

I think your reasoning is valid, and I agree that the patch should be reverted to the previous behavior where VM guests don't load the configuration file on the filesystem.

Hi I am trying to verify this.
The result depends on whether I force reset/shutdown or do not make this forcibly.
a) reset/shutdown guest by force (e.g. virt-manager-> right mouse click->'Shut Down'->'Force *'):
Resolution after boot is set according to the physical monitor resolution of client - so this works ok
(~/.config/monitor.xml file does not exist)

b) reset/shutdown guest (e.g. from within guest):
Display resolution which was set before is preserved across reboot (~/.config/monitor.xml file exists). Resolution even does not change if remote-viewer display area size is modified. IMHO and my research, the only cure for such a state (when resolution of guest is not set according to remote-viewer display area size) is to delete '~/config/monitor.xml' file and reboot guest.

Given b), I can not verify this.

tested with:
guest (rhel8.2):
mutter-3.32.2-33.el8
xorg-x11-drv-qxl-0.1.5-11.el8.x86_64
spice-vdagent-0.19.0-3.el8.x86_64

client/host (rhel8.2):
spice-gtk3-0.37-1.el8.x86_64
spice-server-0.14.2-1.el8.x86_64

(In reply to Radek Duda from comment #13)
> Hi I am trying to verify this.
> The result depends on whether I force reset/shutdown or do not make this
> forcibly.
> a) reset/shutdown guest by force (e.g. virt-manager-> right mouse
> click->'Shut Down'->'Force *'):
> Resolution after boot is set according to the physical monitor resolution of
> client - so this works ok
> (~/.config/monitor.xml file does not exist)
> 
> b) reset/shutdown guest (e.g. from within guest):
> Display resolution which was set before is preserved across reboot
> (~/.config/monitor.xml file exists). Resolution even does not change if
> remote-viewer display area size is modified. IMHO and my research, the only
> cure for such a state (when resolution of guest is not set according to
> remote-viewer display area size) is to delete '~/config/monitor.xml' file
> and reboot guest.
> 
> Given b), I can not verify this.
> 
> tested with:
> guest (rhel8.2):
> mutter-3.32.2-33.el8
> xorg-x11-drv-qxl-0.1.5-11.el8.x86_64
> spice-vdagent-0.19.0-3.el8.x86_64
> 
> client/host (rhel8.2):
> spice-gtk3-0.37-1.el8.x86_64
> spice-server-0.14.2-1.el8.x86_64

Radku do you think this is a blocking issue, meaning it need to be fully fixed in 8.2? Or can we move to 8.3?

We can move this to 8.3

(In reply to Radek Duda from comment #15)
> We can move this to 8.3

OK moving to verified (partially) and cloning for 8.3.

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://access.redhat.com/errata/RHSA-2020:1766