Bug 514887 - Mouse and keyboard of guest are unavailable after migration-[kvm-83-101.el5]
Mouse and keyboard of guest are unavailable after migration-[kvm-83-101.el5]
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
5.4
All Linux
high Severity high
: rc
: ---
Assigned To: Juan Quintela
Lawrence Lim
: Regression
: 515482 (view as bug list)
Depends On:
Blocks: LiveMigration 5.4/TechnicalNotes
  Show dependency treegraph
 
Reported: 2009-07-31 05:12 EDT by Qunfang Zhang
Modified: 2016-04-26 09:43 EDT (History)
13 users (show)

See Also:
Fixed In Version: kvm-83-104.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:28:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Add correct ide version to all register_savevm calls in ide.c (1.62 KB, patch)
2009-07-31 13:07 EDT, Juan Quintela
no flags Details | Diff

  None (edit)
Description Qunfang Zhang 2009-07-31 05:12:28 EDT
Description of problem:
After migrated guest from source host to dst host, the mouse can not move and keyboard is unavailable also. 
1.This issue occurs on kvm-83-101.el5 and the version upward kvm-83-101.el5.
  kvm-83-100.el5 is OK.
2.This issue occurs on both windows and rhel guests.

CLI:
/usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -smp 1 -m 2G -uuid d1297179-84b7-453e-b1ea-51173ad8f95e -net nic,model=rtl8139,macaddr=00:1a:4a:dd:97:86,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -drive file=/mnt/winXP-32.qcow2,media=disk,if=ide -cpu qemu64,+sse2 -boot c -vnc: 10

3.Boot the guest without the "-usbdevice tablet" in command line and implement migration, the mouse and keyboard of guest are still unavailable on 
destination host.


Version-Release number of selected component (if applicable):
RHEL5.4-Server-20090729.0
kernel /vmlinuz-2.6.18-160.el5 
kvm-83-101.el5

How reproducible:
100%

Steps to Reproduce:
1. Start the VM on hostA.
2. Start the VM on hostB in migration-listen mode
3. Start the migration (on host A).
4. Check the guest on hostB after migration.

Actual results:
Mouse and keyboard of guest are unavailable on hostB after migration.

Expected results:
The guest should start successfully after migration.The mouse and keyboard should work well.

Additional info:

Host info:
#cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 67
model name	: Dual-Core AMD Opteron(tm) Processor 1216
stepping	: 3
cpu MHz		: 1000.000
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips	: 2009.36
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Comment 1 Juan Quintela 2009-07-31 10:52:11 EDT
Reproduced locally.  Working on it
Comment 2 Juan Quintela 2009-07-31 13:07:58 EDT
Created attachment 355833 [details]
Add correct ide version to all register_savevm calls in ide.c
Comment 3 Juan Quintela 2009-07-31 13:08:53 EDT
This patch fixes the issue for me.
It was an obvious bug (obvious now) in this patch:

commit ee49f80b360dd57acc61df1694fc7ea798ffa485
Author: Gleb Natapov <gleb@redhat.com>
Date:   Wed Jul 29 19:15:11 2009 +0300

    make windows notice media change
Comment 12 Juan Quintela 2009-08-04 11:20:09 EDT
*** Bug 515482 has been marked as a duplicate of this bug. ***
Comment 13 lihuang 2009-08-05 05:40:01 EDT
Tested in kvm-83-105.el5,kernel-2.6.18-160.el5 PASS.
Comment 14 Issue Tracker 2009-08-05 11:41:51 EDT
Event posted on 08-05-2009 05:40am EDT by bugzilla

These changes made by lihuang@redhat.com.
Bugzilla comment added:
 Tested in kvm-83-105.el5,kernel-2.6.18-160.el5 PASS.

Bugzilla status changed from 'ON_QA' to 'VERIFIED'

https://bugzilla.redhat.com/show_bug.cgi?id=514887

This event sent from IssueTracker by jkachuck 
 issue 325938
Comment 15 Issue Tracker 2009-08-05 11:41:54 EDT
Event posted on 08-05-2009 07:54am EDT by Glen Johnson

------- Comment From santwana.samantray@in.ibm.com 2009-08-05 07:46
EDT-------
Hello Redhat,

I verified this issue with the below nightly build version's, and could
conclude that, "Issue still persists with RHEL5.4-Snap5 32bit guest (i.e
guest becomes unresponsive after migration). However, migration is working
fine with RHEL5.4-Snap5-64bit guest.

Versions:
kvm-83-104.el5
libvirt-0.6.3-17.el5
RHEL5.4(2.6.18-160)

Thanks,
Santwana

Ticket type changed from 'Problem' to ''

This event sent from IssueTracker by jkachuck 
 issue 325938
Comment 16 Issue Tracker 2009-08-05 11:41:57 EDT
Event posted on 08-05-2009 10:26am EDT by Glen Johnson

------- Comment From tpnoonan@us.ibm.com 2009-08-05 10:17 EDT-------
KVM 105 became available this morning in the nightly build for 8/05.
We have not tested it. 104 still had issues, 64 bit virsh and virt-manager
migration worked. 32 bit clients had issues. Qemu still was broken:
For qemu reference the reopened 54554  -  RIT316553-[Regression] Remote
migration of rhel5.4 guest using qemu-kvm fails.

------- Comment From tpnoonan@us.ibm.com 2009-08-05 10:17 EDT-------
After kvm migration regression in ss5 (vs ss4)  kvm stability is in
question as we are testing nightly builds (103 then 104 now 105),
I hope Red Hat waits until migration is working and stability is achieved
before building RC


This event sent from IssueTracker by jkachuck 
 issue 325938
Comment 17 Yaniv Kaul 2009-08-05 11:57:41 EDT
This also regressed Spice: after migration, it used to output two keys per keystroke (tried on 83-103). 83-105 seems to be OK.
Comment 19 Issue Tracker 2009-08-06 09:38:01 EDT
Event posted on 08-06-2009 06:39am EDT by Glen Johnson

------- Comment From santwana.samantray@in.ibm.com 2009-08-06 06:27
EDT-------
Hello Redhat,

I verified this issue with the kvm-83-105 nightly build version, and could
conclude that, "Issue still persists with RHEL5.4-Snap5 32bit guest (i.e
guest
becomes unresponsive after migration). However, migration is working fine
with
RHEL5.4-Snap5-64bit guest.

Versions:
kvm-83-105.el5
libvirt-0.6.3-20.el5
RHEL5.4(2.6.18-160)

Thanks,
Santwana


This event sent from IssueTracker by jkachuck 
 issue 325938
Comment 20 Issue Tracker 2009-08-07 14:03:23 EDT
Event posted on 08-07-2009 12:03pm EDT by Glen Johnson

------- Comment From santwana.samantray@in.ibm.com 2009-08-07 11:57
EDT-------
Hello Redhat,

I could still reproduce this issue: I used RHEL5.4-Early RC1 as host &
tried
migrating RHEL5.4-Snap5-32bit guest. After migration, the RHEL5.4-Snap5
32bit
guest stops responding to any keystrokes or mouse cursor.
Even the running processes like "top" or "ping" stops responding.
However, migrating back the same guest from destination to source works
fine,
i.e it starts responding to keystrokes and mouse cursor.

But this issue is not seen with RHEL5.4-Snap5-64bit guest.

Observation:- The migrated guest's qemu process is utilizing 400% CPU
utilization at the destination.

Versions:
kvm-83-105.el5
kvm-tools-83-105.el5
kmod-kvm-83-105.el5
kvm-qemu-img-83-105.el5
libvirt-0.6.3-20.el5
RHEL5.4(2.6.18-162)

Thanks,
Santwana


This event sent from IssueTracker by jkachuck 
 issue 325938
Comment 21 Juan Quintela 2009-08-07 21:19:51 EDT
It looks like the target machine has not uptodate kvm.  Could you recheck that kvm-83-105.el5 is installed in the target machine?

I am not able to reproduce this one anymore.

Thanks, Jua'n.
Comment 23 Chris Ward 2009-08-12 03:43:13 EDT
*** Bug 515482 has been marked as a duplicate of this bug. ***
Comment 28 Eduardo Habkost 2009-08-21 10:00:58 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
When migrating KVM guests between hosts, the NX CPU feature setting on both source and destination must match.

Migrating a guest between a host with the NX feature disabled (e.g. disabled by the BIOS) and a host with the NX feature enabled may make the guest hang or crash.
Comment 30 Eduardo Habkost 2009-08-21 10:04:53 EDT
Deleted Release Notes Contents.

Old Contents:
When migrating KVM guests between hosts, the NX CPU feature setting on both source and destination must match.

Migrating a guest between a host with the NX feature disabled (e.g. disabled by the BIOS) and a host with the NX feature enabled may make the guest hang or crash.
Comment 31 Juan Quintela 2009-08-23 17:33:02 EDT
I don't have anything else to add to comment #30 from Eduardo, Ryan.
Comment 34 errata-xmlrpc 2009-09-02 05:28:14 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1272.html

Note You need to log in before you can comment on or make changes to this bug.