Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 550269

Summary: qemu-kvm segfalt when migrate guest from rhel5.4 to rhel5.5
Product: Red Hat Enterprise Linux 5 Reporter: Miya Chen <michen>
Component: kvmAssignee: Juan Quintela <quintela>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 5.5CC: anton.fang, khong, llim, quintela, virt-maint, ykaul
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-04 13:33:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Miya Chen 2009-12-24 10:22:32 UTC
Description of problem:
qemu-kvm segfalt when migrate guest from rhel5.4 to rhel5.5

Version-Release number of selected component (if applicable):
kvm-83-142.el5
kvm-83-105.el5_4.13

How reproducible:
100%

Steps to Reproduce:
1.start guest in rhel5.4:
/usr/libexec/qemu-kvm -rtc-td-hack -no-hpet -usbdevice tablet -cpu qemu64,+sse2 -drive file=rhel5u4-64-virtio.qcow2,if=virtio,boot=on -smp 2 -m 2G -vnc :2 -net nic,macaddr=20:20:20:11:88:19,model=e1000,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -monitor stdio
2.start listening mode in rhel5.5:
/usr/libexec/qemu-kvm -rtc-td-hack -no-hpet -usbdevice tablet -cpu qemu64,+sse2 -drive file=rhel5u4-64-virtio.qcow2,if=virtio,boot=on -smp 2 -m 2G -vnc :2 -net nic,macaddr=20:20:20:11:88:19,model=e1000,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -monitor stdio -incoming tcp:0:5888 -M rhel5.4.0
3. start migration.
  
Actual results:
After migration complete, qemu-kvm segfault in destination host(rhel5.5)

Expected results:


Additional info:
Backtrace:
(gdb) r -rtc-td-hack -no-hpet -usbdevice tablet -cpu qemu64,+sse2 -drive file=rhel5u4-64-virtio.qcow2,if=virtio,boot=on -smp 2 -m 2G -vnc :2 -net nic,macaddr=20:20:20:11:88:19,model=e1000,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -monitor stdio -incoming tcp:0:5888 -M rhel5.4.0
Starting program: /usr/libexec/qemu-kvm -rtc-td-hack -no-hpet -usbdevice tablet -cpu qemu64,+sse2 -drive file=rhel5u4-64-virtio.qcow2,if=virtio,boot=on -smp 2 -m 2G -vnc :2 -net nic,macaddr=20:20:20:11:88:19,model=e1000,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -monitor stdio -incoming tcp:0:5888 -M rhel5.4.0
[Thread debugging using libthread_db enabled]
Detaching after fork from child process 3518.
[New Thread 0x2b0d4fe1ff90 (LWP 3515)]
[New Thread 0x411cb940 (LWP 3524)]
[New Thread 0x423b9940 (LWP 3525)]
[New Thread 0x42dba940 (LWP 3526)]
[New Thread 0x437bb940 (LWP 3527)]
QEMU 0.9.1 monitor - type 'help' for more information
(qemu) [New Thread 0x441bc940 (LWP 3528)]
[Thread 0x437bb940 (LWP 3527) exited]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000429075 in ide_load (f=0x13b929c0, s=0x13b75260, version_id=3)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/hw/ide.c:2907
2907            s->bs->enable_write_cache = 0;
(gdb) bt
#0  0x0000000000429075 in ide_load (f=0x13b929c0, s=0x13b75260, version_id=3)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/hw/ide.c:2907
#1  0x000000000042d304 in pci_ide_load (f=0x13b929c0, opaque=0x13b75010, 
    version_id=3)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/hw/ide.c:3285
#2  0x0000000000472460 in qemu_loadvm_state (f=0x13b929c0) at savevm.c:981
#3  0x000000000046b70c in tcp_incomming_run_hook () at migration-tcp.c:472
#4  0x000000000046bb08 in tcp_accept_incoming_migration (
    opaque=<value optimized out>) at migration-tcp.c:561
#5  0x0000000000409502 in main_loop_wait (timeout=<value optimized out>)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/vl.c:3981
#6  0x00000000004fe6fa in kvm_main_loop ()
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/qemu-kvm.c:596
#7  0x000000000040e445 in main (argc=25, argv=0x7fff71e053b8, 
    envp=<value optimized out>)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/vl.c:4038

Comment 1 Miya Chen 2009-12-25 04:47:02 UTC
source host kernel:
# uname -r
2.6.18-164.8.1.el5
destination host kernel
# uname -r
2.6.18-183.el5

BTW: without using -M rhel5.4.0, qemu-kvm segfault too.

Comment 2 Juan Quintela 2009-12-31 03:05:31 UTC
Patch sent that fixes it.  I forgot to check that s->bs was != NULL.  Why it was not catched on my local testing is still a mistery.  Now it works (tm).

Comment 3 Keqin Hong 2010-01-04 07:32:37 UTC
FYI :
By executing "loadvm snapshot" results in the same fault.

host: kvm-83-142.el5 on both intel and amd cpus
guest: 4k cluster_size RHEL5.4-32bit.qcow2 using virtio

Additional Info:
(qemu) info snapshots 
Snapshot devices: virtio0
Snapshot list (from virtio0):
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         sn1                    548M 2010-01-03 21:29:57   00:05:25.557
(qemu) loadvm sn1
[Thread 0x40c08940 (LWP 17422) exited]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000429075 in ide_load (f=0x97c4010, s=0x9750260, version_id=3)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/hw/ide.c:2907
2907	        s->bs->enable_write_cache = 0;
(gdb) bt
#0  0x0000000000429075 in ide_load (f=0x97c4010, s=0x9750260, version_id=3)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/hw/ide.c:2907
#1  0x000000000042d304 in pci_ide_load (f=0x97c4010, opaque=0x9750010, 
    version_id=3)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/hw/ide.c:3285
#2  0x0000000000472460 in qemu_loadvm_state (f=0x97c4010) at savevm.c:981
#3  0x0000000000472689 in do_loadvm (name=0x9797f40 "sn1") at savevm.c:1244
#4  0x00000000004107f3 in monitor_handle_command1 (
    opaque=<value optimized out>, cmdline=<value optimized out>)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/monitor.c:2703
#5  0x0000000000463dd2 in readline_handle_byte (ch=<value optimized out>)
    at readline.c:398
#6  0x000000000040ed1f in term_read (opaque=<value optimized out>, 
    buf=0x9750260 "", size=1)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/monitor.c:3071
#7  0x000000000046fad1 in fd_chr_read (opaque=<value optimized out>)
    at qemu-char.c:541
#8  0x0000000000409502 in main_loop_wait (timeout=<value optimized out>)
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/vl.c:3981
#9  0x00000000004fe6fa in kvm_main_loop ()
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/qemu-kvm.c:596
#10 0x000000000040e445 in main (argc=30, argv=0x7fffe647aa98, 
    envp=<value optimized out>)
---Type <return> to continue, or q <return> to quit---
    at /usr/src/debug/kvm-83-maint-snapshot-20090205/qemu/vl.c:4038
(gdb)

Comment 4 Miya Chen 2010-01-21 09:21:07 UTC
Retest migration guest from kvm-83-105.el5_4.13 to kvm-83-147, this problem does not exist.

kvm-83-147.el5
kvm-83-105.el5_4.13

steps:
1.start guest in rhel5.4:
/usr/libexec/qemu-kvm -drive file=win23k-64-virtio.qcow2,if=virtio,boot=on
-no-hpet -rtc-td-hack -usbdevice tablet -startdate now -smp 2 -m 2G -net
nic,macaddr=20:20:20:11:23:66,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -cpu
qemu64,+sse2 -monitor stdio -vnc :1

2.start listening mode in rhel5.5:
/usr/libexec/qemu-kvm -drive file=win23k-64-virtio.qcow2,if=virtio,boot=on
-no-hpet -rtc-td-hack -usbdevice tablet -startdate now -smp 2 -m 2G -net
nic,macaddr=20:20:20:11:23:66,vlan=0 -net tap,vlan=0,script=/etc/qemu-ifup -cpu
qemu64,+sse2 -monitor stdio -vnc :1 -incoming tcp:0:5889 -M rhel5.4.0

3. start migration.

Actual result:
migration complete successfully, and guest can be operated normally.

Comment 6 Miya Chen 2010-03-04 09:39:57 UTC
FYI:
this bug has been fixed in bug 549938.

Comment 7 Bill Burns 2010-03-04 13:33:31 UTC

*** This bug has been marked as a duplicate of bug 549938 ***