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 609818 - mouse and keyboard of win7 guest do not work after migration
Summary: mouse and keyboard of win7 guest do not work after migration
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Luiz Capitulino
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-01 08:36 UTC by Shirley Zhou
Modified: 2015-03-05 00:51 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-21 02:32:33 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Shirley Zhou 2010-07-01 08:36:10 UTC 
Description of problem:
After migration, the mouse and keyboard in win7 guest do not work after some general operation(like open folder)

Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.82.el6.x86_64
kernel-2.6.32-37.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1.run win7 guest on source host
/usr/libexec/qemu-kvm -m 4G -smp 4 -cpu qemu64,+x2apic  -usb -device usb-tablet,id=input0 -drive file=/mnt/win7-32-virtio.qcow2,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,mac=0a:00:34:3F:20:1A,bus=pci.0 -uuid f25687ba-e2b3-4179-a2aa-5fc4aa0fc051 -rtc-td-hack -no-kvm-pit-reinjection -monitor stdio -name win7-32-114 -qmp tcp:0:4444,server,nowait -vnc :1 -boot c
2.start listening mode on dst host
3.do migration
  
Actual results:
After migration complete, do some basic operation, then mouse and keyboard do not work

Expected results:
The guest can be operated by mouse and keyboard smoothly. 

Additional info:

1.The guest can ping from host
2.(qemu) info migrate 
Migration status: completed
3.top
top - 01:54:12 up 2 days, 20 min,  4 users,  load average: 0.00, 0.01, 0.00
Tasks: 302 total,   1 running, 301 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us,  0.8%sy,  0.0%ni, 98.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  12191184k total,  9526224k used,  2664960k free,    97372k buffers
Swap: 14434296k total,        0k used, 14434296k free,  8333328k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                           
32368 root      20   0 9091m 465m 3220 S  8.0  3.9   0:24.95 qemu-kvm                                                                                                                                          
32425 root      20   0 15068 1368  912 R  0.7  0.0   0:00.05 top                                                                  
                                                                             
    1 root      20   0 19224 1340 1068 S  0.0  0.0   0:01.90 init 
4.kvm_stat -1
[root@dhcp-91-71 home]# kvm_stat -1
efer_reload                    0         0
exits                     254998        25
fpu_reload                  6133         0
halt_exits                 13552         4
halt_wakeup                13524         4
host_state_reload         124472        20
hypercalls                     0         0
insn_emulation             54320         4
insn_emulation_fail            0         0
invlpg                         0         0
io_exits                  109687        16
irq_exits                   4898         0
irq_injections             16531         4
irq_window                   273         0
largepages                    30         0
mmio_exits                     0         0
mmu_cache_miss               509         0
mmu_flooded                    0         0
mmu_pde_zapped                 0         0
mmu_pte_updated                0         0
mmu_pte_write                  0         0
mmu_recycled                   0         0
mmu_shadow_zapped              0         0
mmu_unsync                     0         0
nmi_injections                 0         0
nmi_window                     0         0
pf_fixed                   51668         1
pf_guest                       0         0
remote_tlb_flush             682         0
request_irq                    0         0
signal_exits                   0         0
tlb_flush                      0         0
5.This issue happens on qemu-kvm-0.12.1.2-2.81.el6.x86_64
6.This issue happens on windows 2008 x86
Comment 2 RHEL Program Management 2010-07-01 09:03:08 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Gerd Hoffmann 2010-07-07 14:24:17 UTC 
Not reproducable with qemu-kvm-0.12.1.2-2.90.el6.x86_64, please update and retest.
Comment 4 Shirley Zhou 2010-07-09 02:19:15 UTC 
(In reply to comment #3)
> Not reproducable with qemu-kvm-0.12.1.2-2.90.el6.x86_64, please update and
> retest.    

Retest this issue with qemu-kvm-0.12.1.2-2.90.el6.x86_64,this bus happens after did some general operation on guest(after migration), then mouse and keyboard not available, and can ping this guest from another box.
Comment 5 Quan Wenli 2010-07-09 10:54:30 UTC 
This issue also existed on rhel6-32 migration testing.

Following is my steps and testing env.

Host: Intel, 2.6.32-44.el6.x86_64,qemu-kvm-0.12.1.2-2.91.el6.x86_64
Guest: 2.6.32-44.el6.x86_64

How reproducible:
100%


Steps:
1.Source host:
CLI:
/usr/libexec/qemu-kvm -m 4G -smp 2  -drive file=./rhel6.0-32-tree0701.3-qcow2.bak,cache=none,format=qcow2,if=none,id=drive-virtio0-0-0 -device virtio-blk-pci,drive=drive-virtio0-0-0,id=virtio0-0-0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,mac=00:00:11:12:31:4A,bus=pci.0,addr=0x4 -boot c -uuid `uuidgen` -rtc base=utc -no-kvm-pit-reinjection -cpu qemu64,+sse2,+x2apic -balloon virtio  -vnc :1 -qmp tcp:0:4444,server,nowait -M rhel6.0.0 -name source -monitor stdio
2.Dst Host 
CIL:
 /usr/libexec/qemu-kvm -m 4G -smp 2  -drive file=/mnt/rhel6.0-32-tree0701.3-qcow2.bak,cache=none,format=qcow2,if=none,id=drive-virtio0-0-0 -device virtio-blk-pci,drive=drive-virtio0-0-0,id=virtio0-0-0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,mac=00:00:11:12:31:4A,bus=pci.0,addr=0x4 -boot c -uuid `uuidgen` -rtc base=utc -no-kvm-pit-reinjection -cpu qemu64,+sse2,+x2apic -balloon virtio  -vnc :1 -qmp tcp:0:4444,server,nowait -M rhel6.0.0 -name source -monitor stdio -incoming tcp:0:5888
3.Start migration on source host

(qemu) migrate -d tcp:10.66.91.71:5888
(qemu) info migrate 
Migration status: active
transferred ram: 2164 kbytes
remaining ram: 4208928 kbytes
total ram: 4211072 kbytes
(qemu) info migrate 
Migration status: completed

4.Access dst host by using "vncviewer 10.66.91.71:1"
login the guest,input some basic operation ,for example :ls ,pwd ....
After that,the mouse and keyboard can not be used  anymore.
And Vm's status is paused,Vm can not continue anymore.

5.The output of the dst host:
(qemu) kvm: unhandled exit 31
kvm_run returned -22

(qemu) 
(qemu) info status 
VM status: paused
(qemu) c
(qemu) kvm: unhandled exit 31
kvm_run returned -22
Comment 6 Gerd Hoffmann 2010-07-09 12:53:57 UTC 
Re comment #5

I doubt it is the same issue.  The original report says the guest is still running and reachable via network (ping), whereas comment 5 says the guest is paused.  Please open a new bug.
Comment 7 Quan Wenli 2010-07-12 06:14:19 UTC 
(In reply to comment #6)
> Re comment #5
> 
> I doubt it is the same issue.  The original report says the guest is still
> running and reachable via network (ping), whereas comment 5 says the guest is
> paused.  Please open a new bug.    

The problem form comment #5 only occur when the ksm is on. There is bug 606131 related to it.So won't open another new one. Thanks~~
Comment 8 Mike Cao 2010-07-13 08:13:13 UTC 
Windows 2008 r2 guest hit this issue after migration via compressed file.
After migration ,The guest is very slow for responding user's operations.
Comment 9 Gerd Hoffmann 2010-07-13 10:39:09 UTC 
Looked at bug 606131.  Makes me think this could be an ept issue too.  Would explain why I can't reproduce it locally as my intel test box has no ept support.

Do you have ept enabled?  Does it still happen with ept disabled?
Comment 10 Shirley Zhou 2010-07-14 06:05:39 UTC 
(In reply to comment #9)
> Looked at bug 606131.  Makes me think this could be an ept issue too.  Would
> explain why I can't reproduce it locally as my intel test box has no ept
> support.
> 
> Do you have ept enabled?  Does it still happen with ept disabled?    

Hi, Gerd
I test this issue on host with and without ept support, this bug still exist, while it is random issue.
Thanks.
Comment 11 Gerd Hoffmann 2010-07-16 11:53:03 UTC 
Hmm, I can migrate the guest back and forth between my two intel boxes and never ever hit this, with the configuration being almost identical.  Storage isn't qcow2 but raw (iscsi volume).  I give less resources to the guests (2G / 2 cpus max) because one of the hosts hasn't enough.  I can't enable EPT because my hardware doesn't have it, although that seems not to be the reason (see comment 9+10).

kvm_stat in the initial bug submission looks very suspious.  No context switches happen any more, guest seems to sit idle waiting for something to happen but also doesn't receive interrupts.  deadlock inside the guest?  interrupt controller issue?  timer interrupt issue?

Does the guest have virtio-net drivers installed?  Which version?
Does it also happen with another NIC (say rtl8139)?
Is ksm enabled?  If so, has disabling ksm any effect?
Comment 12 Luiz Capitulino 2010-07-20 19:01:33 UTC 
I'm trying to reproduce this on my (remote) test machine, but it seems to work fine. However, it's been quite slow to do this over vnc.

I'm downloading the needed ISOs to do it locally, will keep testing meanwhile and I need the following information from the reporter:

1. Is it 100% reproducible?

2. Can you try to reduce your command-line as much as possible? Ie. start dropping stuff then reduce memory, vcpus etc

3. You're migrating between machines, right? Can you try migrating in the same machine? Then try to migrate to a file?

4. What do you do before migrating? Browse the web? Run some specific program?
Comment 13 Shirley Zhou 2010-07-21 02:32:33 UTC 
Can not reproduce this issue on kernel-2.6.32-44.1.el6.x86_64,qemu-kvm-0.12.1.2-2.96.el6.x86_64.

I will close this bug, and I will open it if it happen later.Thanks.
Comment 14 Luiz Capitulino 2010-07-21 14:10:08 UTC 
Can you confirm that you have tested with virtio-net and vhost enabled?
Comment 15 Shirley Zhou 2010-07-22 02:05:26 UTC 
(In reply to comment #14)
> Can you confirm that you have tested with virtio-net and vhost enabled?    

Luiz, I tested with virtio-net and vhost=on, my driver install from http://download.lab.bos.redhat.com/devel/RHEV/virtio-win/1.1.8-0/.
Note You need to log in before you can comment on or make changes to this bug.