The original bug was fixed only in half way. To be exact, display resolution can survive VM reboot only that was set in "Display Preferences" dialogue. There are other ways to set VM resolution. One of them is pulling borders of virt-viewer window. Just resize the virt-viewer window and the guest will adapt automatically. In this case resolution doesn't survive VM reboot and resets to 1024x768.

Steps to reproduce:

1. Login to guest 
2. Pull remote-viewer border to setup arbitrary resolution in VM.
3. Reboot in guest
4. Login to guest again 
5. Check current resolution. (xrand) It tells 1024x768 instead of from step #2.

resolution changes are not handled by the agent. Fix will have to go to a component which is aware of the changes

no solution upstream, moving to 7.4

(In reply to Andrei Stepanov from comment #2)
> The original bug was fixed only in half way. To be exact, display resolution
> can survive VM reboot only that was set in "Display Preferences" dialogue.
> There are other ways to set VM resolution. One of them is pulling borders of
> virt-viewer window. Just resize the virt-viewer window and the guest will
> adapt automatically. In this case resolution doesn't survive VM reboot and
> resets to 1024x768.
> 
> Steps to reproduce:
> 
> 1. Login to guest 
> 2. Pull remote-viewer border to setup arbitrary resolution in VM.
> 3. Reboot in guest
> 4. Login to guest again 
> 5. Check current resolution. (xrand) It tells 1024x768 instead of from step
> #2.

So, this is related to the issue discussed by myself and Ray Strode above (see bug 1130080 comment 17). In order to ensure that arbitrary resizing works properly, when the graphics driver supports hotplug_mode_update property the desktop will bypass the monitors.xml configuration file and always set the resolution to the preferred resolution of the driver. As Ray argued above, this could be considered 'incorrect' behavior, but the alternative is that resizing from the client will not work properly. 

What is happening is this:

- user resizes their client to some arbitrary size (let's say 1234x912)
  - 1234x912 is now the preferred resolution of the driver. 
  - Even if the desktop already has a configuration for this display (monitors.xml), it will be ignored
  - the desktop sets the resolution to the preferred mode of the driver (1234x912)
- user reboots guest
  - during shutdown, the QXL driver gets unloaded so the driver no longer "remembers" its preferred mode of 1234x912.
  - guest switches to text mode and the display is resized to something like 800x600
  - The client window also gets resized to match
  - After reboot, the qxl driver gets reloaded and it comes up using its default resolution (e.g. 1024x768)

I believe that this problem did not exist in the past, but started appearing after qemu made a change that unloaded the QXL driver during reboot (the same root cause as Bug 1274447). Before that change, it's possible that the QXL device maintained the same preferred resolution through the reboot and therefore that resolution was restored after reboot.


The only real option that I can think of for fixing this behavior is for the desktop to restore the resolution after re-logging into gnome. Restoring the configuration from monitors.xml is the normal way to achieve this. But A) arbitrary resolutions configured via the spice client are not written to monitors.xml, and B) we currently bypass this functionality since it interferes with arbitrary resizing via the client. So fixing this will not be trivial, I fear.

Honestly, I'm not sure that this should actually be considered a bug. It seems to be at most a minor annoyance. I don't think that rebooting a guest should be considered a common event, so most users will not experience this behavior very often. And the workaround is as simple as resizing the window to the desired size after the reboot. Given the effort that would be required to support this behavior, I don't think it's worth fixing right now.