Bug 466865

Summary: kvm: virtual machine reset during OS reboot
Product: [Fedora] Fedora Reporter: Tomas Hoger <thoger>
Component: kvmAssignee: Glauber Costa <gcosta>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 10CC: berrange, clalance, gcosta, markmc, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-09 08:29:01 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:
Attachments:
Description Flags
host dmesg
none
el5 guest dmesg - successful boot none

Description Tomas Hoger 2008-10-14 08:35:24 UTC 
Description of problem:
On kvm on x86_64, guest virtual machines reset unexpectedly during the guest OS reboot.  This reset occurs during the early part of the OS boot sequence.  This problem was observed with multiple guest OSes (all current RHEL (2.1, 3, 4, 5) and Fedora (8, 9) versions, other OSes were not tried), both i386 and x86_64 arch used by the guests.

Version-Release number of selected component (if applicable):
kvm-65-9.fc9.x86_64
kernel-2.6.26.5-45.fc9.x86_64
libvirt-0.4.6-2.fc9.x86_64

Steps to Reproduce:
1. Boot VM
2. Issue a reboot of the VM (either by logging in and running reboot, or by Ctrl-Alt-Del on the console), watch VNC console during the reboot
3. VM Bios screen -> Grub -> system starts booting
4. During the kernel initialization, or early during the init scripts run, VM resets
5. VM Bios screen -> Grub -> successful system boot
6. At next reboot, steps 3. - 5. repeat, i.e. there's one unsuccessful boot attempt, followed by successful one.
  
Additional info:
Reset does not seem to be triggered by some specific step in OS / OS kernel boot, as issue affects multiple different OS versions, and reset occurs at different time - sometime while kernel initialization is still running, sometimes parts of initscripts are run.

CPU on the system is: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz, hence using kvm-intel

Let me know what other info may help.
Comment 1 Tomas Hoger 2008-10-14 08:38:02 UTC 
I have not managed to reproduce the same on:

Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz

kvm-60-6.fc8.x86_64
kernel-2.6.26.5-28.fc8.x86_64
libvirt-0.4.4-2.fc8.x86_64
Comment 2 Tomas Hoger 2008-10-25 07:58:23 UTC 
Same hardware as in comment #1 when running F9 kvm demonstrates the same flaw:

kvm-65-9.fc9.x86_64
kernel-2.6.26.6-79.fc9.x86_64
libvirt-0.4.6-2.fc9.x86_64
Comment 3 Glauber Costa 2008-10-27 12:06:10 UTC 
Can you get the boot logs (dmesg) for both guest and host?
It'd be useful to see at which point guest reboots, and whether the host get any suspicious message.

For the host, only the first execution matters. The other are potentially bogus, since emulation failures are reported only once. If this is the case of an emulation failure (a pagetable emulation failure could easily trigger this), you'd see it only in the first run.
Comment 4 Tomas Hoger 2008-10-27 13:23:15 UTC 
So should I:
- boot host
- save host dmesg
- boot guest
- save guest dmesg
- save host dmesg diffs against the first host dmesg
?
Comment 5 Glauber Costa 2008-10-27 14:15:40 UTC 
you should save guest dmesg before it crashes. The console is usually output in a serial line (which means a file here), so just send me this file.
You only need to save one host dmesg, after the guest crashes.
Comment 6 Tomas Hoger 2008-10-30 11:28:43 UTC 
Created attachment 321917 [details]
host dmesg

Additional tags were added to note when system booted, guest booted, guest was rebooted.
Comment 7 Tomas Hoger 2008-10-30 11:30:08 UTC 
Created attachment 321918 [details]
el5 guest dmesg - successful boot

I'll try to get dmesg from the reset during the reboot, but haven't got to it yet.
Comment 8 Bug Zapper 2009-06-10 02:57:28 UTC 
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Tomas Hoger 2009-06-10 06:54:33 UTC 
I believe I've seen this with F10 too, though I can test now.  Will try re-testing later.
Comment 10 Tomas Hoger 2009-07-09 08:29:01 UTC 
So I got an opportunity to re-test on F10 and identical hw.  I'm no longer seeing this problem with kernel-2.6.27.25-170.2.72.fc10.x86_64 and kvm-74-10.fc10.x86_64.

Closing.