Bug 466865 - kvm: virtual machine reset during OS reboot
kvm: virtual machine reset during OS reboot
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kvm (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Glauber Costa
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-14 04:35 EDT by Tomas Hoger
Modified: 2009-07-09 04:29 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-09 04:29:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
host dmesg (35.84 KB, text/plain)
2008-10-30 07:28 EDT, Tomas Hoger
no flags Details
el5 guest dmesg - successful boot (11.25 KB, text/plain)
2008-10-30 07:30 EDT, Tomas Hoger
no flags Details

  None (edit)
Description Tomas Hoger 2008-10-14 04:35:24 EDT
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 04:38:02 EDT
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 03:58:23 EDT
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 08:06:10 EDT
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 09:23:15 EDT
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 10:15:40 EDT
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 07:28:43 EDT
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 07:30:08 EDT
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-09 22:57:28 EDT
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 02:54:33 EDT
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 04:29:01 EDT
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.

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