Bug 1031928 - Rhel6.5 guest hung after executing system_reset 20 times
Rhel6.5 guest hung after executing system_reset 20 times
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.5
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Virtualization Maintenance
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-19 02:16 EST by xhan
Modified: 2014-06-18 04:09 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-17 06:18:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
kvm_stat (192.00 KB, text/plain)
2013-11-19 02:16 EST, xhan
no flags Details
screenshot-1 (37.96 KB, image/jpeg)
2013-11-19 02:26 EST, xhan
no flags Details

  None (edit)
Description xhan 2013-11-19 02:16:54 EST
Created attachment 825928 [details]
kvm_stat

Description of problem:

Test rhel6.5 i386 guest, executing system_reset 20 times and then verify VM starts up and can be login. The result is the guest hung up. 

Version-Release number of selected component (if applicable):
kernel-2.6.32-430.el6.x86_64
qemu-kvm-0.12.1.2-2.415.el6_5.2

How reproducible:
once

Steps to Reproduce:
1. start up guest
qemu \
    -S \
    -name 'virt-tests-vm1' \
    -nodefaults \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20131118-151420-m7P0aobP,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control \
    -chardev socket,id=serial_id_serial1,path=/tmp/serial-serial1-20131118-151420-m7P0aobP,server,nowait \
    -device isa-serial,chardev=serial_id_serial1 \
    -chardev socket,id=seabioslog_id_20131118-151420-m7P0aobP,path=/tmp/seabios-20131118-151420-m7P0aobP,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20131118-151420-m7P0aobP,iobase=0x402 \
    -device ich9-usb-uhci1,id=usb1,bus=pci.0,addr=0x4 \
    -drive file='RHEL-Server-6.5-32-virtio.qcow2',index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,snapshot=off,format=qcow2,aio=native \
    -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,bootindex=0 \
    -device virtio-net-pci,netdev=idQB6VKi,mac='9a:e2:e3:e4:e5:e6',bus=pci.0,addr=0x6,id='idjCmccI' \
    -netdev tap,id=idQB6VKi,vhost=on,vhostfd=28,fd=27 \
    -m 2048 \
    -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 \
    -cpu 'Opteron_G2' \
    -M rhel6.5.0 \
    -device AC97,addr=0x7 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \
    -vnc :0 \
    -vga cirrus \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off   \
    -no-kvm-pit-reinjection \
    -enable-kvm
2. reset guest system for 20 times with "system_reset" qmp command
  {'execute': 'system_reset'}
3. after step2, verify whether the guest can boot up.


Actual results:
The guest hung up.

Expected results:
Guest should works normal.

Additional info:

cpu_info

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 107
model name	: AMD Athlon(tm) Dual Core Processor 5400B
stepping	: 2
cpu MHz		: 1000.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial 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 rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv
bogomips	: 2004.14
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 100mhzsteps


kvm_stat

refer to the attachment "kvm_stat"
Comment 1 xhan 2013-11-19 02:26:58 EST
Created attachment 825931 [details]
screenshot-1

Refer to the hung screenshot-1.
Comment 4 Ademar Reis 2013-11-19 08:37:59 EST
If you cold-boot the VM (turn it on after it being powered off, not just reset), does it start? I'm asking it to understand if this is an image corruption or a runtime (hypervisor state) problem caused by the 20 resets.

When you say you managed to reproduce it once: how many times did you try?
Comment 5 xhan 2013-11-20 04:23:52 EST
The system_reset is sent via qmp, and after 20 times, wait for the VM starts up to login. This is the process under test.

I try this case with autotest 100 times more. And could not be reproduced. 

The kvm_stat looks weird. And attach it as "kvm_stat".  Is it useful for you to debug?
Comment 6 Ademar Reis 2013-12-02 13:56:01 EST
(In reply to xhan from comment #5)
> The system_reset is sent via qmp, and after 20 times, wait for the VM starts
> up to login. This is the process under test.
> 

My question is: if you get this same image where the problem happened, shut the VM off, then try to boot it from scratch (cold boot: machine being turned on for the first time after power-off), do you still have the boot problem?

> I try this case with autotest 100 times more. And could not be reproduced. 

OK, I'm marking it cond-nak(reproducer) for now. Please report here if you ever manage to reproduce it.
Comment 7 xhan 2014-01-17 05:15:15 EST
I have tried this case on the same host again. This issue could not be hit.
If I meet it next time, I would check if the image is good to boot.
Comment 8 Ademar Reis 2014-01-17 06:18:13 EST
(In reply to xhan from comment #7)
> I have tried this case on the same host again. This issue could not be hit.
> If I meet it next time, I would check if the image is good to boot.

Given that, I'm closing it for now. Please reopen if you ever reproduce it. Thanks.

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