Bug 637184

Summary: libvirtd can't start
Product: [Fedora] Fedora Reporter: Ahmed M. Araby <araby.ahmed>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: berrange, clalance, crobinso, itamar, jforbes, laine, veillard, 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: 2011-01-11 13:15:44 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Ahmed M. Araby 2010-09-24 10:41:59 EDT
Description of problem:
I'm trying to use libvirt and it's not working so I tried 
service libvirtd restart
and it said ok ok, but virt-manger said it's not running


Version-Release number of selected component (if applicable):
libvirt-0.8.3-2.fc14.x86_64
libvirt-client-0.8.3-2.fc14.x86_64
libvirt-python-0.8.3-2.fc14.x86_64
qemu-img-0.13.0-0.6.rc1.fc14.x86_64


How reproducible:
Try to restart libvirtd and check your log

Steps to Reproduce:
1. service libvirtd restart
  
Actual results:
Not working

Expected results:
Should be up and working

Additional info:
from /var/log/messages


   1.
      Sep 24 17:29:36 localhost libvirtd: 17:29:36.379: warning : qemudDispatchSignalEvent:396 : Shutting down on signal 15
   2.
      Sep 24 17:29:38 localhost libvirtd: Could not find keytab file: /etc/libvirt/krb5.tab: No such file or directory
   3.
      Sep 24 17:29:38 localhost libvirtd: 17:29:38.490: error : virRunWithHook:857 : internal error '/sbin/iptables --table mangle --delete POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' exited with non-zero status 2 and signal 0: iptables v1.4.9: unknown option `--checksum-fill'#012Try `iptables -h' or 'iptables --help' for more information.#012
   4.
      Sep 24 17:29:38 localhost libvirtd: 17:29:38.716: error : virRunWithHook:857 : internal error '/sbin/iptables --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 69 --jump ACCEPT' exited with non-zero status 1 and signal 0: iptables: Bad rule (does a matching rule exist in that chain?).#012
   5.
      Sep 24 17:29:38 localhost libvirtd: 17:29:38.833: error : virRunWithHook:857 : internal error '/sbin/iptables --table mangle --insert POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' exited with non-zero status 2 and signal 0: iptables v1.4.9: unknown option `--checksum-fill'#012Try `iptables -h' or 'iptables --help' for more information.#012
   6.
      Sep 24 17:29:38 localhost libvirtd: 17:29:38.833: warning : networkAddIptablesRules:850 : Could not add rule to fixup DHCP response checksums on network 'default'.
   7.
      Sep 24 17:29:38 localhost libvirtd: 17:29:38.833: warning : networkAddIptablesRules:851 : May need to update iptables package & kernel to support CHECKSUM rule.
   8.
      Sep 24 17:29:42 localhost libvirtd: 17:29:42.602: warning : qemudStartup:1832 : Unable to create cgroup for driver: No such device or address
   9.
      Sep 24 17:29:43 localhost kernel: lo: Disabled Privacy Extensions
Comment 1 Laine Stump 2010-10-26 00:09:56 EDT
Items 3 - 7 are red herrings - Those messages are informational only, and don't lead to shutting down of libvirtd. See Bug 642355.

Item 8 is also a red herring, although I don't have a reference for it.
Comment 2 Laine Stump 2010-10-26 15:57:31 EDT
(Actually I spoke to quickly - items 3 & 4 are not related to Bug 642355).

Ahmed,

is the fact that virt-manager can't find libvirt your only indication that libvirtd is not running? Have you looked for libvirtd in the output of ps:

   ps -AlF | grep libvirtd

None of the messages you included from your log indicate that libvirtd is going to shut down; even those that are valid errors would not lead to libvirtd terminating.

Since there is no indication of a legitimate shutdown, libvirtd would have to be crashing, and that should show up as an abrt alert (run "abrt-gui" as root to see if there are any crashes recorded).
Comment 3 Laine Stump 2010-10-27 12:53:53 EDT
Also, items 3 & 4 are possibly ancillary errors encountered during the
cleanup of a failure to start the network, and thus are obscuring the actual
error. See:

  https://www.redhat.com/archives/libvir-list/2010-October/msg00997.html

which was added to upstream libvirt in this commit:

commit d68bb70a2d606b7206e78c360cbd4cf62b070493
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Tue Oct 26 11:17:25 2010 +0100

    Avoid squashing errors during network startup cleanup path

    When failing to start a virtual network, we have to cleanup,
    tearing down any iptables rules. If the iptables rules were
    not present yet though, this raises an error, which squashes
    the original error we were handling.

    * src/network/bridge_driver.c: When failing to start a virtual
      network, don't squash the original error in cleanup


If possible, try the upcoming 0.8.5 release (or just grab the latest git sources and build/install yourself) and see if the error log changes.