Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
(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.
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"