Bug 508767 - host crash when libvirtd is run
host crash when libvirtd is run
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-29 15:04 EDT by Wayne Feick
Modified: 2009-07-14 14:01 EDT (History)
10 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Wayne Feick 2009-06-29 15:04:28 EDT
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start libvirtd and qemu on virtual machines that ran fine under Fedora 11.
Actual results:

Host hangs.

Expected results:

Host doesn't hang.

Additional info:

Installed Packages
libvirt.x86_64  0.6.2-12.fc11    @updates
qemu.x86_64     2:0.10.5-3.fc11  @updates
Comment 1 Wayne Feick 2009-06-29 15:10:57 EDT
I don't see anything in /var/log/messages. Are there other log files I should be looking in?

I had to disable libvirtd and qemu from automatically starting at boot to avoid these crashes.

I have two virtual machines that were starting up automatically: one is fedora 10, the other is Vista. Both are 64 bit.

The host machine is an Apple desktop with 2 Xeon E5462 quad core Intel chips and 8G of memory.

I'm not sure what else needs to be collected as relevant information, but let me know and I'll get what you need.
Comment 2 Mark McLoughlin 2009-07-03 10:07:41 EDT
What exactly do you mean by "host crash" - is this a kernel oops, or a lock up, or ...?

If you make it so the guests don't start automatically, does libvirtd start okay at boot? If so, then which of the guests causes the host to crash?

Hopefully this wiki page helps in gathering the information we need:

https://fedoraproject.org/wiki/Reporting virtualization bugs
Comment 3 Wayne Feick 2009-07-03 10:29:27 EDT
I mean the host locks up, the cursor and keyboard are dead, and I have to hold the power button down for a while to force a shut off.

No oops message is apparent.

The page you pointed me to is empty.

One potential reason for the issue is that I installed F11 to a new partition, and then copied in the /etc/libvirt files from the old F10 partition (doing diffs where the files were installed as part of F11 to make sure I wasn't overwriting anything important that had changed). It's possible the F11 install would have migrated my qemu machine definitions in some way if I had done an upgrade.
Comment 4 Wayne Feick 2009-07-03 10:31:22 EDT
I haven't tried disabling automatic startup yet, but I can do that next week when I'm back in the office. It's a busy week with a company wide offsite for three days, so I'll likely not get to it until Friday (Jul 10).
Comment 5 Mark McLoughlin 2009-07-03 10:37:28 EDT
URL is https://fedoraproject.org/wiki/Reporting_virtualization_bugs

What you describe sounds like a kernel bug, so moving there. Please do try disabling automatic startup and report back your results

See also

Comment 6 Wayne Feick 2009-07-13 20:19:13 EDT
I removed the state I'd copied over from my F10 install and recreated my three virtual machines with the existing virtual disks (they're LVM logical volumes). Everything is working fine, so I'd say don't waste your time trying to narrow the issue down. It's likely due to me copying the /etc/libvirtd/qemu/* files from my old F10 image to the new F11 image that caused the problem.

Perhaps if I'd done an upgrade the .xml files would have been modified in some way?
Comment 7 Daniel Berrange 2009-07-14 05:22:50 EDT
THe XML files don't need any changes upon upgrade, since libvirt guarantees 100% stability / compatability of its XML data formats.

Regardless your host OS should never crash upon launching a VM. If you think you might be able to get a kernel panic log / more debugging, leave this BZ open, otherwise close it INSUFFICIENT_DATA.
Comment 8 Wayne Feick 2009-07-14 14:01:31 EDT
Realistically, I'm not going to get a chance to poke around on this any further.

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