Red Hat Bugzilla – Bug 1031928
Rhel6.5 guest hung after executing system_reset 20 times
Last modified: 2014-06-18 04:09:53 EDT
Created attachment 825928 [details]
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):
Steps to Reproduce:
1. start up guest
-name 'virt-tests-vm1' \
-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 \
2. reset guest system for 20 times with "system_reset" qmp command
3. after step2, verify whether the guest can boot up.
The guest hung up.
Guest should works normal.
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
refer to the attachment "kvm_stat"
Created attachment 825931 [details]
Refer to the hung screenshot-1.
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?
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?
(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.
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.
(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.