Bug 1009144

The bug was submitted during the rhel 6.5 testing. Moving to the RHEL for triage.

In the first case, I suspect you closed the client.

When you start the client, it's either in fullscreen or in window mode, no a mix of both or whatever old state you might have been.

What is the issue exactly?

Where did I state I closed the client?

The windowed mode "Display 2" can't be moved after the VM is shutdown and restarted. I then try to change the resolution setting within windows and the second display acts badly like I stated in the bug.

This also happens in:

virt-viewer-0.5.6-7.el6.x86_64
rhev-guest-tools-iso-3.3-5.noarch.rpm
RHEL6.5-20130912.n.2
rhev-hypervisor6-6.5-20130910.2.el6ev.noarch.rpm
Windows 7x86 VM

(In reply to Bill Sanford from comment #4)
> Where did I state I closed the client?

shutdown usually means vm shutdown, which close spice connection and close the client.

> The windowed mode "Display 2" can't be moved after the VM is shutdown and
> restarted. I then try to change the resolution setting within windows and
> the second display acts badly like I stated in the bug.

How do you restart the VM?

How did you restart the client?

Oh ok, now I understand about the client. 

To test this,

I brought up the guest, changed guest resolution, shutdown the guest through "Start Button -> Restart" and started the guest back up. The "Starting" of the whole environment before and after the shutdown are from the command-lines below.

First terminal window
/usr/libexec/qemu-kvm -m 2048 -spice port=3001,disable-ticketing,addr=127.0.0.1,seamless-migration=on -vga qxl -device qxl -device qxl -device qxl -global qxl-vga.vram_size=67108864 -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3,filter='0x08:-1:-1:-1:1|-1:-1:-1:-1:0' -readconfig /etc/qemu/ich9-ehci-uhci.cfg /home/images/Win7x86.img -monitor stdio 

Second terminal window
/usr/libexec/qemu-kvm -m 2048 -spice port=3002,disable-ticketing,addr=127.0.0.1,seamless-migration=on -vga qxl -device qxl -device qxl -device qxl -global qxl-vga.vram_size=67108864 -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3,filter='0x08:-1:-1:-1:1|-1:-1:-1:-1:0' -readconfig /etc/qemu/ich9-ehci-uhci.cfg /home/images/Win7x86.img -monitor stdio -incoming tcp:127.0.0.1:4444 

Third terminal window
remote-viewer spice://127.0.0.1?port=3001

(In reply to Bill Sanford from comment #7)
> Oh ok, now I understand about the client. 
> 
> To test this,
> 
> I brought up the guest, changed guest resolution, shutdown the guest through
> "Start Button -> Restart" and started the guest back up. The "Starting" of
> the whole environment before and after the shutdown are from the
> command-lines below.

You are not consistant, it's hard to know what we are talking about.

In your comment 1, you said "If I do the same steps but reboot the Windows VM within Windows, instead of a shutdown, the remote-viewer windows stay open and restores the previous configuration of both monitors"

but the bug "Shutdown of VM results in full-screen display returning in windowed mode" seems to imply a different mechanism than VM restart, which I assume will shutdown the VM and close the client. In which case, the window state is lost, and there isn't much we can do about that, nor do I think we should.

> First terminal window
> /usr/libexec/qemu-kvm -m 2048 -spice
> port=3001,disable-ticketing,addr=127.0.0.1,seamless-migration=on -vga qxl
> -device qxl -device qxl -device qxl -global qxl-vga.vram_size=67108864
> -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device
> virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev
> spicevmc,name=usbredir,id=usbredirchardev1 -device
> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3,filter='0x08:-1:-
> 1:-1:1|-1:-1:-1:-1:0' -readconfig /etc/qemu/ich9-ehci-uhci.cfg
> /home/images/Win7x86.img -monitor stdio 
> 
> Second terminal window
> /usr/libexec/qemu-kvm -m 2048 -spice
> port=3002,disable-ticketing,addr=127.0.0.1,seamless-migration=on -vga qxl
> -device qxl -device qxl -device qxl -global qxl-vga.vram_size=67108864
> -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device
> virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev
> spicevmc,name=usbredir,id=usbredirchardev1 -device
> usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3,filter='0x08:-1:-
> 1:-1:1|-1:-1:-1:-1:0' -readconfig /etc/qemu/ich9-ehci-uhci.cfg
> /home/images/Win7x86.img -monitor stdio -incoming tcp:127.0.0.1:4444 

Why do you have second qemu instance now?

> Third terminal window
> remote-viewer spice://127.0.0.1?port=3001

(In reply to Marc-Andre Lureau from comment #8)
> (In reply to Bill Sanford from comment #7)
> > Oh ok, now I understand about the client. 
> > 
> > To test this,
> > 
> > I brought up the guest, changed guest resolution, shutdown the guest through
> > "Start Button -> Restart" and started the guest back up. The "Starting" of
> > the whole environment before and after the shutdown are from the
> > command-lines below.
> 
> You are not consistant, it's hard to know what we are talking about.
> 
> In your comment 1, you said "If I do the same steps but reboot the Windows
> VM within Windows, instead of a shutdown, the remote-viewer windows stay
> open and restores the previous configuration of both monitors"
> 
> but the bug "Shutdown of VM results in full-screen display returning in
> windowed mode" seems to imply a different mechanism than VM restart, which I
> assume will shutdown the VM and close the client. In which case, the window
> state is lost, and there isn't much we can do about that, nor do I think we
> should.

What happens is the previously full-screen window is now in "Windowed-mode" and at the max resolution value of the monitor. The issue of not being able to move that second display and change the resolution is covered in https://bugzilla.redhat.com/show_bug.cgi?id=1009146

What I would expect to happen when the VM is shutdown and the virt-viewer is gone, is that the two displays return to there previously configured states and to be usable.

Started with:

Display 1 1024x768 (Windowed mode Monitor 1)
Display 2 1024x768 (Windowed mode Monitor 2)

Then I switched Display 2 to full-screen.
Display 1 1024x768 (Windowed mode Monitor 1)
Display 2 1920x1080 (Virt-viewer toggle F11, Full-screen Monitor 2)

I will agree with you that the full-screen is not supported after virt-viewer is destroyed by the VM shutting down. BUT, if I toggle Display 2 to full-screen, then on VM shutdown, when I restart the same VM, I should get what I started with, which is 2 1024x768 displays that are usable.

> > First terminal window
> > /usr/libexec/qemu-kvm -m 2048 -spice
> > port=3001,disable-ticketing,addr=127.0.0.1,seamless-migration=on -vga qxl
> > -device qxl -device qxl -device qxl -global qxl-vga.vram_size=67108864
> > -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device
> > virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev
> > spicevmc,name=usbredir,id=usbredirchardev1 -device
> > usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3,filter='0x08:-1:-
> > 1:-1:1|-1:-1:-1:-1:0' -readconfig /etc/qemu/ich9-ehci-uhci.cfg
> > /home/images/Win7x86.img -monitor stdio 
> > 
> > Second terminal window
> > /usr/libexec/qemu-kvm -m 2048 -spice
> > port=3002,disable-ticketing,addr=127.0.0.1,seamless-migration=on -vga qxl
> > -device qxl -device qxl -device qxl -global qxl-vga.vram_size=67108864
> > -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device
> > virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev
> > spicevmc,name=usbredir,id=usbredirchardev1 -device
> > usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3,filter='0x08:-1:-
> > 1:-1:1|-1:-1:-1:-1:0' -readconfig /etc/qemu/ich9-ehci-uhci.cfg
> > /home/images/Win7x86.img -monitor stdio -incoming tcp:127.0.0.1:4444 
> 
> Why do you have second qemu instance now?

I was in the middle of testing migration and multimonitor and wanted to give you the exact scenario that I had to work with and where I found the bugs.

> > Third terminal window
> > remote-viewer spice://127.0.0.1?port=3001

(In reply to Bill Sanford from comment #9)
> (In reply to Marc-Andre Lureau from comment #8)
> > (In reply to Bill Sanford from comment #7)
> > > Oh ok, now I understand about the client. 
> > > 
> > > To test this,
> > > 
> > > I brought up the guest, changed guest resolution, shutdown the guest through
> > > "Start Button -> Restart" and started the guest back up. The "Starting" of
> > > the whole environment before and after the shutdown are from the
> > > command-lines below.
> > 
> > You are not consistant, it's hard to know what we are talking about.
> > 
> > In your comment 1, you said "If I do the same steps but reboot the Windows
> > VM within Windows, instead of a shutdown, the remote-viewer windows stay
> > open and restores the previous configuration of both monitors"
> > 
> > but the bug "Shutdown of VM results in full-screen display returning in
> > windowed mode" seems to imply a different mechanism than VM restart, which I
> > assume will shutdown the VM and close the client. In which case, the window
> > state is lost, and there isn't much we can do about that, nor do I think we
> > should.
> 
> What happens is the previously full-screen window is now in "Windowed-mode"
> and at the max resolution value of the monitor. The issue of not being able
> to move that second display and change the resolution is covered in
> https://bugzilla.redhat.com/show_bug.cgi?id=1009146
> 
> What I would expect to happen when the VM is shutdown and the virt-viewer is
> gone, is that the two displays return to there previously configured states
> and to be usable.
> 
> Started with:
> 
> Display 1 1024x768 (Windowed mode Monitor 1)
> Display 2 1024x768 (Windowed mode Monitor 2)
> 
> Then I switched Display 2 to full-screen.
> Display 1 1024x768 (Windowed mode Monitor 1)
> Display 2 1920x1080 (Virt-viewer toggle F11, Full-screen Monitor 2)
> 
> I will agree with you that the full-screen is not supported after
> virt-viewer is destroyed by the VM shutting down. BUT, if I toggle Display 2
> to full-screen, then on VM shutdown, when I restart the same VM, I should
> get what I started with, which is 2 1024x768 displays that are usable.

When you (re)connect the client (in window mode) to a guest previously configured with Display 1 1024x768, Display 2 1920x1080, it should keep this resolution. 

ie, "Shutdown of VM results in full-screen display returning in windowed mode", is not a bug if you restarted the client.

Now you seem to indicate that the bug is "I should get what I started with, which is 2 1024x768 displays that are usable"

But that would mean that we lost previously configured resolution, which would be a bug.

Sorry, but I don't get where is the bug now

That second display that is the 1920x1080, I can't move anywhere. I try to edit the settings in Windows and it maximizes itself in the first monitor. This is now into bug https://bugzilla.redhat.com/show_bug.cgi?id=1009146.

The bug is that the full-screen resolution is getting saved when virt-viewer is not being closed. The Windows VM is being shutdown and the full-screen resolution information should not be saved.

I should either have the second display in full-screen or it should be what I had before the full-screen change, not something in between.

I tested the issue with:
virt-viewer-0.5.6-7.el6.x86_64

Steps:
1.Use remote-viewer to launch a winxp guest from rhevm,enable 2 displays.
Display 1 1024x768 (Windowed mode Monitor 1)
Display 2 1024x768 (Windowed mode Monitor 2)

2.Switched Display 2 to full-screen.
Display 1 1024x768 (Windowed mode Monitor 1)
Display 2 1280x1024 (Full-screen Monitor 2)

3.In guest,click "Start"->"Reboot".

4.The remote-viewer windows stay open and restores the previous configuration of both monitors (Display 1 in windowed mode and Display 2 in full-screen).

I think remote-viewer client doesn't close,so when you reboot the guest,it saves the previous resolution,it is acceptable.

from comment #12)
> The bug is that the full-screen resolution is getting saved when virt-viewer
> is not being closed. The Windows VM is being shutdown and the full-screen
> resolution information should not be saved.
> 
> I should either have the second display in full-screen or it should be what
> I had before the full-screen change, not something in between.

There's no 'saving' or 'not saving' involved here. When a virt-viewer window switches to fullscreen mode, it simply re-configures the associated guest display to have a resolution equal to the size of the client monitor. The guest then maintains that configuration until it gets re-configured again. So when you say the "resolution information should not be saved", what you actually mean is that we should explicitly re-configure the guest to the pre-full-screen resolution.

If you close virt-viewer and then re-connect to that guest again (regardless of whether the guest has been shut down or restarted in the meantime), the guest will still have the same display configuration it had when you quit virt-viewer. This means that virt-viewer will open a window for each guest display equal to the size reported for that display by the guest. Since one of the displays was configured to 1920x1080 when virt-viewer exited, it will still be 1920x1080 upon re-connection, so virt-viewer will open a window that is 1920x1080. 

This is behaving exactly as designed, so this report is not describing a bug but rather a request to change our specified behavior. As a user, I'm sympathetic to the fact that opening windows that are larger than the physical resolution of the client monitor can be a bit annoying. But changing this behavior is not as simple a matter as you imply above, for several reasons:
- the guest has no concept of "fullscreen" windows -- it has no way of knowing whether its display is being shown in a windowed or fullscreen mode. It only knows its current resolution.
- if the client has been restarted, when it re-starts it will have no memory of the pre-fullscreen resolution for a particular display on a particular guest. Theoretically we could save that state between sessions in a config file somewhere, but keeping track of per-display-per-guest display configurations would get complex very quickly.
- Even if we did remember display resolution state between client sessions, perhaps user B has connected to the guest and reconfigured the displays between the time that user A exited virt-viewer with a fullscreen window and the time that user A re-connected to the guest in windowed mode.  What should the display resolution be in that case?  The pre-fullscreen resolution that we saved? or the resolution that user B set for the display?
- It is very intentional that virt-viewer does not automatically reconfigure the guest displays at startup unless specifically requested (with --full-screen[=auto-conf]). Changing resolution without user interaction tends to annoy people. If they had set up their displays exactly how they wanted them and then quit and re-connected to the guest, things will be re-arranged and they will have to set everything up again.

I can think of a couple possible ways to approach this issue:

A. close as NOTABUG and keep the current behavior.

B. change virt-viewer so that if a guest display is bigger than the client monitor at startup, it will automatically set the zoom factor to scale it down to fit into the client monitor.

C. change virt-viewer so that if virt-viewer is closed with a fullscreen window, we send a display re-configuration to the guest just before exiting to set the display back to the resolution they had before they were full-screened (though it's possible that this would annoy some people for the same reasons automatic reconfiguration at startup annoys people).

My inclination is to do either A or B, but I'd welcome additional feedback from others.

please reply to Jonathon, comment 14