Bug 628219

Summary:	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
Product:	[Fedora] Fedora	Reporter:	Tom London <selinux>
Component:	libvirt	Assignee:	Daniel Veillard <veillard>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	aquini, berrange, clalance, crobinso, itamar, jforbes, laine, mjevans1983, 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:	2010-10-27 12:36:39 EDT	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Description Tom London 2010-08-28 12:53:37 EDT

Description of problem:
Notice the following spew in /var/log/messages.

Not sure its a problem, but thought I would log it....

Aug 28 07:03:38 tlondon libvirtd: 07:03:38.639: 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
Aug 28 07:03:38 tlondon libvirtd: 07:03:38.641: warning : networkAddIptablesRules:850 : Could not add rule to fixup DHCP response checksums on network 'default'.
Aug 28 07:03:38 tlondon libvirtd: 07:03:38.641: warning : networkAddIptablesRules:851 : May need to update iptables package & kernel to support CHECKSUM rule.


Version-Release number of selected component (if applicable):
libvirt-0.8.3-2.fc15.x86_64

How reproducible:
Appears every boot/libvirtd start

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Michael J Evans 2010-09-18 01:28:20 EDT

On my (generic linux) system this combines with an issue in creating any kind of routed network to preclude /any/ networking of virtual systems.

Severity should be increased proportionately since this is the default use case.


(Error when creating a network 'bridged' 10.255.255.0/24, DHCP disabled, forwarding route to eth0)

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/createnet.py", line 357, in finish
    self.conn.create_network(xml)
  File "/usr/share/virt-manager/virtManager/connection.py", line 742, in create_network
    net.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 866, in create
    if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self)
libvirtError: internal error '/sbin/iptables --table filter --delete INPUT --in-interface virbr1 --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?).

Comment 2 Laine Stump 2010-10-27 12:36:39 EDT

One bug report, two separate issues.

The original reported message (by Tom London) is just informational - see Bug 642355. I'm closing this bug as a duplicate of Bug 642355. Basically the answer is that it's harmless, and will go away if, as the warning log suggests, you update iptables.

As for the error listed in Comment 1 (by Michael J Evans), it is unrelated to the original report, is most likely an ancillary error encountered during the cleanup of a failure to start the network, and thus is 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


You maybe get more complete information with your current libvirt from "grep libvirtd /var/log/messages". Or, if you're able to build from source, grab the latest libvirt source from git (or the upcoming 0.8.5 release), build and install, and the *real* error should show up in the logs.

After you've collected that information, rather than filing a bug against Fedora, it would probably be more productive to either file a bug against the Linux distro you are using (you say "generic Linux", leading me to believe it's not Fedora), or if there is no appropriate bug tracker for that, against upstream libvirt (since it's not a Fedora-specific problem); the latter can be done in bugzilla.redhat.com, by filing under "Other" / "Virtualization Tools" / "libvirt". (when you do so, don't forget to attach your domain and network config XML files)

(BTW, since a total failure of networking to work is something that would likely be noticed by regression testing prior to release, it's highly likely you have a configuration problem that could be solved by getting help from the people on libvirt's IRC channel - see libvirt.org for details).

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