Bug 1130080 - new resolution doesn't take effect after guest reboot
Summary: new resolution doesn't take effect after guest reboot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-vdagent
Version: 6.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 6.8
Assignee: Eduardo Lima (Etrunko)
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks: 1309315
TreeView+ depends on / blocked
 
Reported: 2014-08-14 09:55 UTC by Chao Yang
Modified: 2016-05-11 01:04 UTC (History)
19 users (show)

Fixed In Version: spice-vdagent-0.14.0-11.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1309315 (view as bug list)
Environment:
Last Closed: 2016-05-11 01:04:19 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0950 normal SHIPPED_LIVE spice-vdagent bug fix update 2016-05-10 22:56:14 UTC

Description Chao Yang 2014-08-14 09:55:37 UTC
Description of problem:

Changed default resolution of my rhel6.6 guest, which is 1024x768 in my test, to 1440x900 then rebooted it. I found current resolution changed back to 1024x768.

This didn't happen if using rhel7 as guest.

Version-Release number of selected component (if applicable):

Host:
qemu-kvm-0.12.1.2-2.436.el6.x86_64
spice-server-0.12.4-9.el6.x86_64

Guest:
rhel6.6: xorg-x11-drv-qxl-0.1.1-13
rhel7  : xorg-x11-drv-qxl-0.1.1-9

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
I downgraded qxl driver in rhel6.6 guest to xorg-x11-drv-qxl-0.1.1-9, but this didn't make any difference.

CLI:
/usr/libexec/qemu-kvm -name rhel6.6 -S -machine rhel6.6.0,dump-guest-core=off -cpu Opteron_G5 -enable-kvm -m 980G -realtime mlock=off -smp 64,sockets=8,cores=4,threads=2 -uuid 25d91d6f-5848-39e8-ca69-e2165a8134ea -nodefconfig -nodefaults -monitor stdio -qmp unix:/tmp/qmp,server,nowait -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive file=rhel6.6.qcow2,if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:84:16:e1,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on -fda /home/scalability/disk1 -fdb /home/scalability/disk2

Comment 2 Gerd Hoffmann 2014-08-28 14:43:28 UTC
  Hi,

> Changed default resolution of my rhel6.6 guest, which is 1024x768 in my
> test, to 1440x900 then rebooted it. I found current resolution changed back
> to 1024x768.

Details please.  What exactly have you done?

Comment 3 Chao Yang 2014-08-29 01:38:36 UTC
(In reply to Gerd Hoffmann from comment #2)
>   Hi,
> 
> > Changed default resolution of my rhel6.6 guest, which is 1024x768 in my
> > test, to 1440x900 then rebooted it. I found current resolution changed back
> > to 1024x768.
> 
> Details please.  What exactly have you done?

1. login to guest 

2. 'System' -> 'Preference' -> 'Display', it tells current resolution in guest is 1024x768

3. change currently resolution to other mode like 1440x900, click 'Apply' -> 'Keep This Configuration'

4. reboot in guest

5. login to guest again and repeat step 2 to check current resolution. It tells 1024x768 instead of 1440x900

Comment 4 Gerd Hoffmann 2014-08-29 07:03:35 UTC
Ok, I see.  When logging in after reboot I see the display resize to the configured resolution, then quickly switch back to 1024x768.

Turned off spice agent.  Problem disappeared.

So it looks like you are running spice agent, and it is spice-agent which switches the resolution back to 1024x768.  It shouldn't do that IMO, reassigning bug.

Side note: With spice-agent being active there is no need to go through display settings to get a larger screen.  Just resize the virt-viewer window and the guest will adapt automatically.

Comment 5 Gerd Hoffmann 2014-08-29 07:11:56 UTC
Damn, bugzilla seems to be hosed, doesn't let me change the component to spice-vdagent.  Reassigning to spice-bugs for now ...

Comment 6 Marc-Andre Lureau 2015-03-27 14:12:49 UTC
I think this was done more or less by design:

commit 801f10d485c5133cd4d27ee43f2f1bc8307a24b5
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date:   Fri Mar 15 20:24:38 2013 +0100

    Update current resolution when agent is started
    
    This ensures we have the requested resolution whenever possible.

However, this is problematic when switching from console to graphical mode or when switching from gdm session (using qxl default resolution 1024x768) to user session.

Comment 7 Pavel Grunt 2015-04-08 13:28:11 UTC
Solved in spice-vdagent by the commit 9ae51f3702b1fc0d2747e44474c87a818d1e8ec3

Comment 9 Andrei Stepanov 2015-05-20 17:13:29 UTC
spice-vdagent-0.14.0-9.el6.i686

virt-viewer-2.0-1.fc21.x86_64
virt-viewer-2.0-7.el6.x86_64

After reboot&login resolution resets to 1024x768

Comment 13 Eduardo Lima (Etrunko) 2015-10-02 20:51:13 UTC
An easier way to reproduce this bug is by simply logging out and logging in again on the guest.

I found that this bug is actually a regression introduced by the patch proposed as solution for bug 1086657. By reverting that patch, this problem is fixed.

Comment 14 Ray Strode [halfline] 2016-01-06 17:09:52 UTC
I think the analysis in bug 108665 might be a little off.  Deleting the file is wrong. The file contains user configured setups for the various monitor topologies the user has encountered.  Deleting it will delete not just the current setup, but all setups (granted we're talking about virt here, so there won't be other setups).

Now, enabling or disabling a monitor in virt-viewer is the virtual equivalent of plugging in or unplugging a monitor.  You're interacting with the virtual "hardware" not with the OS, so when that happens the OS should react in the same way it would if a physical monitor was getting plugged in or unplugged.

I think the "change_timestamp < config_timestamp" mention in bug 1086657 is a red herring.  We treat change < config to mean "hot plug happened".  In the case the user "plugs the monitor in" using the virt-viewer UI, we want it to be treated like a hotplug since virt-viewer is modeling hardware.

The display preferences in RHEL6 remembers monitor profiles for the user.  If a user with a laptop docks to their desk monitors, it will remember the config the user set up previously and apply it automatically as soon as it detects the docking. If the user explicitly disables one of the monitors that are plugged in, that monitor will remain disabled next time the user docks.

This same monitor profile logic applies for virtualization setups as well. In bug 1086657 comment 0 step 4, the reporter is doing exactly that: turning the monitor off in the profile.  Next time the explicitly disabled monitor is "plugged in" (using virt-viewer) it won't be turned on automatically, precisely because the user told it to stay off.

What is weird behavior is bug 1086657 comment 6: that disabling the monitor in the rhel6 display preferences makes it show up as disconnected in xrandr output.  If you turn a monitor off using the OS display preferences, it should still show as connected (plugged in) ! So that's probably a root bug, or at least the first bug that needs to get addressed.  Turning a monitor off in the OS, shouldn't make the virtual plug fall off the virtual connector.

Comment 15 Ray Strode [halfline] 2016-01-06 17:10:39 UTC
to be clear, I think the "unlink monitors.xml" behavior should be reverted.

Comment 16 Marc-Andre Lureau 2016-01-06 17:17:08 UTC
(In reply to Ray Strode [halfline] from comment #15)
> to be clear, I think the "unlink monitors.xml" behavior should be reverted.

I think #1086657 could really use your help if it's reopened.

Comment 17 Jonathon Jongsma 2016-01-08 19:53:29 UTC
(In reply to Ray Strode [halfline] from comment #15)
> to be clear, I think the "unlink monitors.xml" behavior should be reverted.


By the way, this "unlink monitors.xml" behavior was a workaround for rhel6 only. In rhel7/upstream, it's handled differently (though you might still consider it wrong). 

The relevant commit is here: https://git.gnome.org/browse/mutter/commit/?id=7012c82fc7ac1ff5f2d6ef12d2e6e01b2bef9472

Basically, if the X driver has the 'hotplug_mode_update' property (which is basically only the QXL driver at this point), mutter will simply ignore the monitors.xml file and never try to load configurations from it. This avoids the "need" to remove this file, though it results in the same basic behavior.

The reason we chose this approach is because even though adding a new virtual monitor is analogous to plugging in a new physical monitor, there are some important differences:

- a physical machine can get a new monitor as a side-effect of another action such as docking a laptop. When the user plugs the laptop into a dock, she usually has the setup configured in a certain way and wants this configuration to be restored. On the other hand, we only ever get a new virtual monitor by explicitly enabling the monitor in virt-viewer (which sends a "monitors config" message to the spice server). I think it would be a pretty unexpected (and a poor user experience) if, when the user enables a display in virt-viewer, the guest chose not to enable this display due to a previously stored configuration and required the user to open the gnome display configuration utility to enable it from within the guest.

- monitors.xml basically assumes that a given monitor will always support the mode that is stored in the monitors.xml file. For physical monitors, this is basically true because they support a fixed set of modes. For virtual monitors, this is not the case. Due to how the QXL driver is implemented, a virtual monitor always supports a set of standard modes (800x600, 1280x720, etc), and possibly a single arbitrary mode that has been configured via spice (for example, 1463x1056). If we store this 1463x1056 mode in the config file and then resize the virt-viewer window (to e.g. 1234x987), virt-viewer will send a monitors-config message down to the spice server, which will update the device such that it now supports the standard modes and also 1234x987. 1463x1056 is no longer a supported mode, so even if we tried to retain the user's saved configuration, we would not be able to. The "hardware" no longer supports that mode. 

For these reasons (and possibly others that I can't remember at the moment), we chose to bypass the saved configuration infrastructure for devices with "hotplug_mode_update". If you have ideas on ways to handle this better, I'd be happy to hear them, but I haven't been able to come up with anything better yet.

Your comment about the disabled monitor becoming disconnected is probably true -- that may be a bug in QXL. But the above issues would still remain even if this was changed.

Comment 19 Andrei Stepanov 2016-02-08 12:01:29 UTC
spice-vdagent-0.14.0-11.el6.i686

virt-viewer-2.0-13.el6.x86_64 & virt-viewer-2.0-6.el7.x86_64

# ps axwu | grep spice-vdagent
root      2043  0.0  0.0   3640   824 ?        Ss   12:58   0:00 /usr/sbin/spice-vdagentd
gdm       2514  0.0  0.0   5544  1344 ?        Ss   12:58   0:00 /usr/bin/spice-vdagent
astepano  2695  0.0  0.0   5544  1428 ?        Ss   12:58   0:00 /usr/bin/spice-vdagent


After reboot&login resolution resets to 1024x768

Comment 20 Andrei Stepanov 2016-02-10 16:27:18 UTC
There are several ways to change GuestOS's resolution:

1. Using 'System' -> 'Preference' -> 'Display' at GuestOS.
2. Pulling remote-viewer's window borders.
3. etc...

For the current fix, it is true that:

Changes at "Display Settings" can survive GuestOS reboot. After login to VM resolution becomes as it was before to reboot. 

But, there is a problem : Another methods for changing resolution do not survive after VM reboot. For example, if you pull remote-viewer window to set custom resolution, it resets to 1024x768 after VM reboot.

There are few questions to the reporter: Chao Yang, what is your test case? What is priority for this bug? Are you satisfied with current solution?

Comment 21 Chao Yang 2016-02-17 02:07:11 UTC
(In reply to Andrei Stepanov from comment #20)
> There are several ways to change GuestOS's resolution:
> 
> 1. Using 'System' -> 'Preference' -> 'Display' at GuestOS.
> 2. Pulling remote-viewer's window borders.
> 3. etc...
> 
> For the current fix, it is true that:
> 
> Changes at "Display Settings" can survive GuestOS reboot. After login to VM
> resolution becomes as it was before to reboot. 
> 
> But, there is a problem : Another methods for changing resolution do not
> survive after VM reboot. For example, if you pull remote-viewer window to
> set custom resolution, it resets to 1024x768 after VM reboot.
> 
> There are few questions to the reporter: Chao Yang, what is your test case?
> What is priority for this bug? Are you satisfied with current solution?

Yes, it is ok to me if this behavior is expected.

Comment 22 Pavel Grunt 2016-02-17 12:13:40 UTC
Andrei, is the confirmation from the comment 21 enough to verify the bug? 

Steps to reproduce are described in the comment 3

Comment 24 errata-xmlrpc 2016-05-11 01:04:19 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-2016-0950.html


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