Hide Forgot
Description of problem: I'm running rhel6.3 guest on rhel5.8 host this whole wrapped by rhevm30. It did not happen with legacy spice-client so I guess it's problem of spice-gtk. (agent is not involved, as we don't support it on 5.X hosts) Version-Release number of selected component (if applicable): kvm-83-249.el5_8 qspice-libs-0.3.0-54.el5_5.2 spice-gtk-0.11-8.el6.x86_64 virt-viewer-0.5.2-4.el6.x86_64 How reproducible: Well it's almost 100% reproducible sometimes you need to migrate guest twice. Steps to Reproduce: 1. sudo update-alternatives --config spice-xpi-client # pick remote-viewer 2. connect trough userportal into rhel63 running on rhel5.8 host 3. initiate migration process 4. move mouse during migration Actual results: mouse works fine until the first hang appears (client reconnection) then it's completely unusable. Re-capturing mouse (shift-12) does not fix this issue. Expected results: no mouse issues should appear Additional info: /usr/libexec/qemu-kvm -no-hpet -usb -rtc-td-hack -startdate 2012-04-17T14:41:42 -name RHEL63-64 -smp 1,cores=1 -k en-us -m 1024 -boot cn -net nic,vlan=1,macaddr=00:1a:4a:31:7f:05,model=virtio -net tap,vlan=1,ifname=virtio_10_1,script=no -drive file=/rhev/data-center/d14d4bc9-d66c-49f3-ae89-909c631dbb11/c8fd28b9-5105-46e7-8443-753a92db83e2/images/e20a1939-c686-4821-96a0-054f03ea0e8f/2cdf8901-38d2-409d-8824-aa5d472c375e,media=disk,if=virtio,cache=off,serial=21-96a0-054f03ea0e8f,boot=on,format=qcow2,werror=stop -drive file=/rhev/data-center/d14d4bc9-d66c-49f3-ae89-909c631dbb11/9aa406d4-ded7-43f4-af90-7664ceb04d95/images/11111111-1111-1111-1111-111111111111/RHEV-toolsSetup_2.2_53011.iso,media=cdrom,index=2,if=ide -pidfile /var/vdsm/681f314d-17d0-4a81-8546-ad73903b91d9.pid -soundhw ac97 -spice sslpassword=,sslciphersuite=DEFAULT,sslcert=/var/vdsm/ts/certs/vdsmcert.pem,sslkey=/var/vdsm/ts/keys/vdsmkey.pem,ssldhfile=/var/vdsm/ts/keys/dh.pem,sslcafile=/var/vdsm/ts/certs/cacert.pem,host=0,secure-channels=main+inputs,ic=on,sport=5890,port=5910 -qxl 2 -incoming tcp::49160 -cpu qemu64,+sse2 -M rhel5.5.0 -notify all -balloon none -smbios type=1,manufacturer=Red Hat,product=RHEL,version=5Server-5.8.0.3,serial=35373031-3039-435A-3230-333443424B39_1c:c1:de:1b:60:8c,uuid=681f314d-17d0-4a81-8546-ad73903b91d9 -vmchannel di:0200,unix:/var/vdsm/681f314d-17d0-4a81-8546-ad73903b91d9.guest.socket,server -monitor unix:/var/vdsm/681f314d-17d0-4a81-8546-ad73903b91d9.monitor.socket,server
I've just tested this several times, after reconnection, the tooltip for the "applications" top menubar entry shows up, and navigating in this menu is a bit weird (it no longer follow the mouse, and some clicks are interpreted as double clicks), but it's still usable if you click on the menu entries instead of hovering over them. Rubberband selection in Nautilus is also broken, but clicking on a scrollbar and scrolling works. Restarting the client fixes it. In my opinion, what I've seen is not critical enough to qualify as a blocker. Lubos, could you describe what you tried to do and couldn't when the mouse was "unusable"?
(In reply to comment #2) > I've just tested this several times, after reconnection, the tooltip for the > "applications" top menubar entry shows up, and navigating in this menu is a > bit > weird (it no longer follow the mouse, and some clicks are interpreted as > double > clicks), but it's still usable if you click on the menu entries instead of > hovering over them. Rubberband selection in Nautilus is also broken, but > clicking on a scrollbar and scrolling works. Restarting the client fixes it. > > In my opinion, what I've seen is not critical enough to qualify as a blocker. > Lubos, could you describe what you tried to do and couldn't when the mouse > was > "unusable"? I can observer the same like Lubos, mouse is unusable because I cannot see any cursor movement, cursor always remains on place where I did last click (This all appears after migration).
(In reply to comment #3) > (In reply to comment #2) > > I've just tested this several times, after reconnection, the tooltip for the > > "applications" top menubar entry shows up, and navigating in this menu is a > > bit > > weird (it no longer follow the mouse, and some clicks are interpreted as > > double > > clicks), but it's still usable if you click on the menu entries instead of > > hovering over them. Rubberband selection in Nautilus is also broken, but > > clicking on a scrollbar and scrolling works. Restarting the client fixes it. > > > > In my opinion, what I've seen is not critical enough to qualify as a blocker. > > Lubos, could you describe what you tried to do and couldn't when the mouse > > was > > "unusable"? > > I can observer the same like Lubos, mouse is unusable because I cannot see > any cursor movement, cursor always remains on place where I did last click > (This all appears after migration). I'll have to retest then, what I observed was that I could move the mouse, clicks were mostly working, there was just a slightly weird behaviour on clicks/mouse over
(In reply to comment #3) > (In reply to comment #2) > > I've just tested this several times, after reconnection, the tooltip for the > > "applications" top menubar entry shows up, and navigating in this menu is a > > bit > > weird (it no longer follow the mouse, and some clicks are interpreted as > > double > > clicks), but it's still usable if you click on the menu entries instead of > > hovering over them. Rubberband selection in Nautilus is also broken, but > > clicking on a scrollbar and scrolling works. Restarting the client fixes it. > > > > In my opinion, what I've seen is not critical enough to qualify as a blocker. > > Lubos, could you describe what you tried to do and couldn't when the mouse > > was > > "unusable"? > > I can observer the same like Lubos, mouse is unusable because I cannot see > any cursor movement, cursor always remains on place where I did last click > (This all appears after migration). I think I can narrow the problem, after some more investigating It looks that this happens when more qxl devices are defined on rhel5 host. Then mouse is trapped in remote-viewer window and behaves crazily after migration, when only one qxl device is defined, mouse is not trapped in client window even no agent running and It behaves fine after migration. So I could say that problem is limited to a corner (maybe unsupported) case.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > > > I've just tested this several times, after reconnection, the tooltip for the > > > "applications" top menubar entry shows up, and navigating in this menu is a > > > bit > > > weird (it no longer follow the mouse, and some clicks are interpreted as > > > double > > > clicks), but it's still usable if you click on the menu entries instead of > > > hovering over them. Rubberband selection in Nautilus is also broken, but > > > clicking on a scrollbar and scrolling works. Restarting the client fixes it. > > > > > > In my opinion, what I've seen is not critical enough to qualify as a blocker. > > > Lubos, could you describe what you tried to do and couldn't when the mouse > > > was > > > "unusable"? > > > > I can observer the same like Lubos, mouse is unusable because I cannot see > > any cursor movement, cursor always remains on place where I did last click > > (This all appears after migration). > > I think I can narrow the problem, after some more investigating It looks > that this happens when more qxl devices are defined on rhel5 host. Then > mouse is trapped in remote-viewer window and behaves crazily after > migration, when only one qxl device is defined, mouse is not trapped in > client window even no agent running and It behaves fine after migration. > So I could say that problem is limited to a corner (maybe unsupported) case. close the bug. very specific use case and it is on rhel 5.8 host. Will re-visit if the above use case will require attention