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
Reproduced locally. Working on it
Created attachment 355833 [details] Add correct ide version to all register_savevm calls in ide.c
This patch fixes the issue for me. It was an obvious bug (obvious now) in this patch: commit ee49f80b360dd57acc61df1694fc7ea798ffa485 Author: Gleb Natapov <gleb> Date: Wed Jul 29 19:15:11 2009 +0300 make windows notice media change
*** Bug 515482 has been marked as a duplicate of this bug. ***
Tested in kvm-83-105.el5,kernel-2.6.18-160.el5 PASS.
Event posted on 08-05-2009 05:40am EDT by bugzilla These changes made by lihuang. 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
Event posted on 08-05-2009 07:54am EDT by Glen Johnson ------- Comment From santwana.samantray.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
Event posted on 08-05-2009 10:26am EDT by Glen Johnson ------- Comment From tpnoonan.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.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
This also regressed Spice: after migration, it used to output two keys per keystroke (tried on 83-103). 83-105 seems to be OK.
Event posted on 08-06-2009 06:39am EDT by Glen Johnson ------- Comment From santwana.samantray.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
Event posted on 08-07-2009 12:03pm EDT by Glen Johnson ------- Comment From santwana.samantray.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
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.
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.
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.
I don't have anything else to add to comment #30 from Eduardo, Ryan.
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