Red Hat Bugzilla – Bug 1009018
Windows taskbar defaults to the non-primary monitor after reboot.
Last modified: 2014-03-19 12:23:05 EDT
Created attachment 798827 [details] Screenshot of the taskbar on the non-primary monitor Description of problem: When multiple displays are configured and the VM is in anyway restarted, the taskbar ends up on the non-primary display. To get the taskbar on the primary display, you need to close the display with the taskbar and then it will show up on the primary display (Display 1). Version-Release number of selected component (if applicable): rhev-guest-tools-iso-3.3-5.noarch.rpm RHEL6.5-20130912.n.2 rhev-hypervisor6-6.5-20130910.2.el6ev.noarch.rpm Windows XP VM How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: After reboot, the taskbar ends up on the non-primary display. Expected results: After reboot, the taskbar stays on the primary display. Additional info: First terminal /usr/libexec/qemu-kvm -m 2048 -spice port=3001,disable-ticketing,addr=127.0.0.1,seamless-migration=on -vga 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/WinXP.img -monitor stdio Second terminal /usr/libexec/qemu-kvm -m 2048 -spice port=3002,disable-ticketing,addr=127.0.0.1,seamless-migration=on -vga 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/WinXP.img -monitor stdio -incoming tcp:127.0.0.1:4444 Third terminal remote-viewer spice://127.0.0.1?port=3001
The bug was submitted during the RHEL 6.5 testing. Moving to the RHEL for triage.
This seems to work if the VM is Windows 7x86.
I can reproduce this with : virt-viewer-0.5.6-8.el6.x86_64 Steps: 1. Have a winxp guest with 2 displays on a 2 monitors host. 2. Connect the guest and just open one display # virt-viewer winxp 3. Open "Display Properties" Right click - > Properties -> Settings. Make sure there are two monitors, but only the primary one is enabled. Then close "Display Properties" 4. Open another display. "View" -> "Display" -> "Display 2" 5. Make sure can see two displays, then open "Display Properties". The two monitors are all enabled. Result: Step5, after open another display, the task status bar will on the non-primary display.
Sorry the comment 4 is not correct, I think it's another problem. Steps: 1. Have a winxp guest with 2 displays on a 2 monitors host. 2. connect the guest with 2 display. 3. Restart winxp Result: Step4, after restart the guest, the task status bar will on the non-primary display, but the icons is on the primary monitor.
I tried to reproduce this, and wasn't able to reproduce it. Here was my process: - open win xp guest in virt-viewer - enable 2nd display - click start > turn off computer > Restart - wait for guest to reboot After the guest finished rebooting, the taskbar reliably ended up on the primary monitor. However, I was eventually able to reproduce the behavior with the following procedure: - open winxp guest in virt-viewer - enable 2nd display - ** move guest display 1 to client monitor 2 - ** move guest display 2 to client monitor 1 - click start > turn off computer > Restart - wait for guest to reboot In this situation, the task bar ended up on display 2 (the display that is located on the primary client monitor). When you first noticed this bug, were your displays reversed on the client ?
No the displays were fine, it was the toolbar that was off.
When you say the 'displays were fine', what does that mean? The more precise your answer, the easier it is to diagnose the problem. In my second scenario above, I would consider the displays to be 'fine' as well. My question was about how they were arranged when you observed the problem. Should I interpret your reply to mean that the guest display 1 was on client monitor 1 and guest display 2 was on client monitor 2, etc?
Same root cause as Bug 1002156. Fixed upstream.
*** This bug has been marked as a duplicate of bug 1018180 ***