Bug 978785 - Reboot of linux-based libvirtd guest causes kernel crash
Summary: Reboot of linux-based libvirtd guest causes kernel crash
Status: CLOSED DUPLICATE of bug 975065
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-27 07:09 UTC by Sam Jorna
Modified: 2013-07-03 00:18 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-07-03 00:18:44 UTC
Type: Bug

Attachments (Terms of Use)

Description Sam Jorna 2013-06-27 07:09:30 UTC
Description of problem:
Using a linux-based guest with KVM (tested both CentOS 6.4 and Fedora 17 guests), rebooting the guest machine causes host to completely lock up - nothing even shown in /var/log/messages.  Occurred on previous kernel but waited for new kernel to check if it was still happening, however the trigger on the previous kernel was different.  With previous kernel, noted that one of the components in the stack trace (which managed to display) was kms_drm, however unsure if this is also the case now as no stack trace displayed and no other information available.

Version-Release number of selected component (if applicable):
kernel-3.9.5-201.fc18.x86_64 (previous)
kernel-3.9.6-200.fc18.x86_64 (current)

How reproducible:
For me, every time, though it may also be hardware-related.

Steps to Reproduce:
1. Install linux-based guest in libvirt.
2. Update guest using `yum update`
3. Reboot guest

On previous kernel, occasionally the guest would boot without incident, however could induce a similar crash through the following:
1. Boot guest to runlevel 3 (with ssh running)
2. SSH to root@guest
3. `vim` .ssh/authorized_keys

Actual results:
Host machine freezes completely, cannot switch to terminal, cannot ssh in, no output or stack trace to screen, nothing in /var/log/messages

Expected results:
Host machine to remain stable and guest machine to either handle exception itself or, preferably, work correctly.

Additional info:
As I am unable to provide full stack trace information, I understand that it would be difficult to reproduce this bug for testing; however if it may help, I can provide hardware specifications on request.

Comment 1 Josh Boyer 2013-07-01 15:36:32 UTC
Are you using virtio for the guests?  If so, does the issue go away if you use some other network emulation, such as e1000e?

Comment 2 Sam Jorna 2013-07-02 23:53:09 UTC
Interestingly, yes.

I've done some testing and the results are below.  The test I was using is to boot the virtual machine, ssh in and attempt `vim .ssh/authorized_keys`.  If successful, reboot the guest and attempt again.  Results are:

HDD         NIC         Result
Virtio      Virtio      Fail
IDE         e1000       Pass
IDE         Virtio      Fail
Virtio      e1000       Pass

It seems that when the NIC is using a VirtIO driver, it seems to cause issues in the host's kernel...

Comment 3 Sam Jorna 2013-07-02 23:54:47 UTC
Additional: I have two Windows 7 x86 Guests using VirtIO with the appropriate VirtIO drivers from Red Hat installed, both without issue (or at least, without related issue).

Comment 4 Josh Boyer 2013-07-03 00:18:44 UTC
OK.  I'm going to dup this bug to 975065

*** This bug has been marked as a duplicate of bug 975065 ***

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