Bug 786652

Summary: Guest get calltrace and failed to boot up after several times iofuzz testing
Product: Red Hat Enterprise Linux 6 Reporter: Qunfang Zhang <qzhang>
Component: qemu-kvmAssignee: Paolo Bonzini <pbonzini>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 6.3CC: acathrow, akong, bsarathy, fyang, jasowang, juzhang, michen, mkenneth, pbonzini, tburke, virt-maint
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-13 15:11:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
autotest log
none
Serial log of the guest none

Description Qunfang Zhang 2012-02-02 03:06:52 UTC 
Description of problem:
Running iofuzz testing on RHEL5.8 guest and repeat several times, after 3 or 4 rounds later, guest image can not boot up and get a call trace. Attachment will be upload.

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

How reproducible:
Always

Steps to Reproduce:
1. Run iofuzz testing on RHEL6.3 host, I tested rhel5.7 and 5.8 guest, got the same result.
2.

CLI:
/home/staf-kvm-devel/autotest-devel/client/tests/kvm/qemu -name vm1 -chardev
socket,id=qmp_monitor_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20120201-143600-63Pq,server,nowait
-mon chardev=qmp_monitor_id_qmpmonitor1,mode=control -chardev
socket,id=serial_id_20120201-143600-63Pq,path=/tmp/serial-20120201-143600-63Pq,server,nowait
-device isa-serial,chardev=serial_id_20120201-143600-63Pq -device
ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 -drive
file=/home/staf-kvm-devel/autotest-devel/client/tests/kvm/images/RHEL-Server-5.7-64.qcow2,index=0,if=none,id=drive-ide0-0-0,media=disk,cache=none,format=qcow2,aio=native
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -device
e1000,netdev=idxEvOi8,mac=9a:ad:28:4b:eb:ea,id=ndev00idxEvOi8,bus=pci.0,addr=0x3
-netdev tap,id=idxEvOi8,fd=19 -m 512 -smp 1,cores=1,threads=1,sockets=1 -cpu
cpu64-rhel6,+sse2,+x2apic -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1
-vnc :0 -rtc base=utc,clock=host,driftfix=slew -M rhel6.2.0 -boot
order=cdn,once=c,menu=off -no-kvm-pit-reinjection -enable-kvm

  
Actual results:
Guest got call trace and  failed to boot up after 3 or 4 rounds of iofuzz testing.

Expected results:
Guest could boot up.

Additional info:
Comment 1 Qunfang Zhang 2012-02-02 03:08:06 UTC 
Created attachment 558959 [details]
autotest log
Comment 2 Qunfang Zhang 2012-02-02 03:08:31 UTC 
Created attachment 558960 [details]
Serial log of the guest
Comment 4 Paolo Bonzini 2012-02-15 09:58:07 UTC 
I think this is not a problem; iofuzz is mostly a QEMU test and can destabilize the guest hardware (which leads to crashes).  Unless QEMU core dumps, as in bug 751937 for example, I think there is no problem.

That said, getting the output of the gdb command "thread apply bt full" on the QEMU process can help.
Comment 5 Paolo Bonzini 2012-02-15 09:58:57 UTC 
Closed by mistake, setting NEEDINFO for Qunfang
Comment 6 Qunfang Zhang 2012-02-16 10:20:24 UTC 
Hi, Paolo
I meet this issue during iofuzz autotest. Now the job is running and I will provide the bt log after it get the calltrace point.

So, this issue is most likely not a bug?