RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 796203 - spice client mouse doesn't work since 0.12.1.2-2.228 build
Summary: spice client mouse doesn't work since 0.12.1.2-2.228 build
Keywords:
Status: CLOSED DUPLICATE of bug 791200
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-22 13:25 UTC by Yonit Halperin
Modified: 2014-01-21 00:00 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-11 08:19:33 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Yonit Halperin 2012-02-22 13:25:47 UTC 
Description of problem:

Windows 7 (64 and 32 bit) guest.
qemu-kvm >= qemu-kvm-0.12.1.2-2.228.el6

spice client mouse doesn't work (no mouse operation affects the guest).
Bisecting the problem shows that this bug apperead since qemu-kvm-0.12.1.2-2.228.el6 build.
In the Windows guest vdeserice log we see that GetOverlappedResult returns the error NO_SYSTEM_RESOURCES
Comment 2 Arnon Gilboa 2012-02-22 14:27:51 UTC 
(In reply to comment #0)
> Description of problem:
> 
> Windows 7 (64 and 32 bit) guest.
> qemu-kvm >= qemu-kvm-0.12.1.2-2.228.el6
> 
> spice client mouse doesn't work (no mouse operation affects the guest).
> Bisecting the problem shows that this bug apperead since
> qemu-kvm-0.12.1.2-2.228.el6 build.
> In the Windows guest vdeserice log we see that GetOverlappedResult returns the
> error NO_SYSTEM_RESOURCES

Async ReadFile() from virtio serial is called, its overlapped event is set and we get:
"VirtioVDIPort::read_completion::GetOverlappedResult failed: 1450"
I'm doing a further debugging from vdservice as well, although it works well up until -227.
Comment 3 juzhang 2012-02-23 01:56:51 UTC 
https://bugzilla.redhat.com/show_bug.cgi?id=787974#c19

---snip from this comments---
A brief summary:
According to my testing:
This bug is nothing to do with migration, once start vdservice,Spice Client
mouse loss.

FYI,it is same issue?
Comment 4 juzhang 2012-02-23 06:12:49 UTC 
Update

https://bugzilla.redhat.com/show_bug.cgi?id=787974#c20

---snip from this comments---
retested with older qemu-kvm, like qemu-kvm-0.12.1.2-2.192.el6.x86_64. After
starting vdservice, spice client mouse _won't_ lose.

Seems this issue is as same as bz787974 comment19
Comment 6 juzhang 2012-02-29 03:04:38 UTC 
> 1. Get any version between 218-227
> 2. Start vdservice to get client mouse mode -  Does it work?
Tested 227, Start vdservice,the mouse works well
> 3. Migrate - Does mouse work?
Currently,tested with 227 using qemu-kvm command line directly,mouse works fine after migration.we will have a try using rhel-M,we will updates in bz787974 once we get.
> 4. Get 228.
> 5. Start vdservice to get client mouse mode - Does it work?
Tested 228 and later, Start vdservice,the mouse lost.


Mark this issue as qa ack+
Comment 7 juzhang 2012-02-29 06:26:11 UTC 
FYI
we just tried 234 that just come out under environment as same as comment6.

Results:

Start vdservice,the mouse works well

I checked the qemu-kvm changelog,maybe this patch give this issue a help.

Changelog  	
* Tue Feb 28 2012 Michal Novotny <minovotn> - qemu-kvm-0.12.1.2-2.234.el6 - kvm-Always-notify-consumers-of-char-devices-if-they-re-o.patch [bz#791200] 

qemu-kvm cmd
#/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 2048 -smp 2,sockets=1,cores=2,threads=1 -name test -uuid 3d4aff0c-f8f0-4341-872d-4aabca9d5293 -rtc base=localtime,clock=host,driftfix=slew -boot menu=on -drive file=/mnt/windows7-64.qcow2,if=none,id=drive-virtio-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop -device ide-drive,drive=drive-virtio-0-0,id=virt0-0-0 -netdev tap,id=net -device v
irtio-net-pci,netdev=net,id=net0,mac=64:31:50:23:49:1f -usb -spice port=9000,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -monitor stdio -balloon none -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device intel-hda,id=sound -device
hda-duplex
Comment 8 Arnon Gilboa 2012-03-06 09:10:56 UTC 
(In reply to comment #7)
> FYI
> we just tried 234 that just come out under environment as same as comment6.
> 
> Results:
> 
> Start vdservice,the mouse works well
> 

juzhang, so why not close with CURRENTRELEASE?
Comment 9 juzhang 2012-03-07 04:47:27 UTC 
According to comment6 and comment7,close this issue as CURRENTRELEASE. please free to re-open if hit again or think our verify testing is not sufficient.
Comment 10 David Jaša 2012-04-03 21:37:20 UTC 
back to assigned, this stopped working again after update from -147 to -168.
Comment 11 David Jaša 2012-04-03 21:46:49 UTC 
+TestBlocker
Comment 12 Marian Krcmarik 2012-04-04 10:59:10 UTC 
(In reply to comment #10)
> back to assigned, this stopped working again after update from -147 to -168.

was meant from -247 to -268
Comment 15 David Jaša 2012-04-10 08:06:19 UTC 
on qemu-kvm-0.12.1.2-2.270.el6.x86_64, I can not reproduce anymore.
Comment 16 Ademar Reis 2012-04-10 14:16:15 UTC 
(In reply to comment #15)
> on qemu-kvm-0.12.1.2-2.270.el6.x86_64, I can not reproduce anymore.

Moving target from beta to rc for now. Please retest it on a different scenario to make sure we can close it.
Comment 17 Ademar Reis 2012-04-10 21:53:18 UTC 
(In reply to comment #16)
> (In reply to comment #15)
> > on qemu-kvm-0.12.1.2-2.270.el6.x86_64, I can not reproduce anymore.
> 
> Moving target from beta to rc for now. Please retest it on a different scenario
> to make sure we can close it.

BTW, by different scenario, I mean a different host, different configuration and/or different steps (please check previous comments).
Comment 18 Amit Shah 2012-04-11 08:19:33 UTC 
This is a dup of Bug 791200.  Can't say what caused the blip from -247 to -268 (as comment 10 notes),  but that could be due to other reasons or some bad test.  The original report, however, corresponds to what we had in bug 791200 and that's fixed since -234.

*** This bug has been marked as a duplicate of bug 791200 ***
Note You need to log in before you can comment on or make changes to this bug.