Bug 1030554 - if firewalld stopped, starting network gives unclear error: failed to add iptables rule to allow DHCP requests from 'virbr0'
if firewalld stopped, starting network gives unclear error: failed to add ipt...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-14 11:57 EST by Jozef Mlich
Modified: 2016-09-19 14:07 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-05-29 13:10:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 104968 None None None 2016-02-25 10:08 EST

  None (edit)
Description Jozef Mlich 2013-11-14 11:57:52 EST
Description of problem:
Error starting network 'default': failed to add iptables rule to allow DHCP requests from 'virbr0'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/network.py", line 89, in start
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2318, in create
    if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self)
libvirtError: failed to add iptables rule to allow DHCP requests from 'virbr0'


Version-Release number of selected component (if applicable):
Version     : 0.10.0
Release     : 5.git1ffcc0cc.fc20

How reproducible:
always

Steps to Reproduce:
1) I open virt-manager
2) enter the password
3) right click (localhost QEMU)
4) details
5) "+" button
6) I type "network1" into network name (or any other name) - Forward
7) Forward (with default settings, I tried to delete other networks to avoid collision afterwards)
8) Finish
- error message occurred


Actual results:
virtual network is not working

Expected results:


Additional info:
Comment 1 Jozef Mlich 2013-11-14 12:05:18 EST
I am sorry, I have found what was causing the problem. 

Unfortunately, the Firewalld was stopped. The error message is not really descriptive.
Comment 2 Cole Robinson 2013-12-18 12:10:10 EST
If we showed the command output hopefully it'll make things clear
Comment 3 Ivan Romanov 2013-12-19 13:08:43 EST
+1 for me too
Comment 4 Fedora End Of Life 2015-05-29 05:45:47 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.
Comment 5 Laine Stump 2015-05-29 13:10:11 EDT
This is the message now logged when yoou try to start a libvirt network after stopping firewalld. It's not ideal, but it does point you at a service with FirewallD in the name (and this can only happen if firewalld was already running, but was then stopped after libvirtd was started, so it should be adequate to understand the source of the problem.)

# virsh net-start default
error: Failed to start network default
error: The name org.fedoraproject.FirewallD1 was not provided by any .service files
Comment 6 IBM Bug Proxy 2016-02-25 10:17:11 EST
------- Comment From hannsj_uhl@de.ibm.com 2016-02-25 09:46 EDT-------
.
Comment 7 yalzhang@redhat.com 2016-09-19 13:04:57 EDT
(In reply to Laine Stump from comment #5)
> This is the message now logged when yoou try to start a libvirt network
> after stopping firewalld. It's not ideal, but it does point you at a service
> with FirewallD in the name (and this can only happen if firewalld was
> already running, but was then stopped after libvirtd was started, so it
> should be adequate to understand the source of the problem.)
> 
> # virsh net-start default
> error: Failed to start network default
> error: The name org.fedoraproject.FirewallD1 was not provided by any
> .service files

Hi Lanie,

Could you please help to confirm if I get the point?
Current libvirt has been integrated with firewalld, that is to say,if we start the libvirtd service while the firewalld service is active,libvirtd will use DBus API to use firewalld to manage the iptables rules (this is the default choice).If the firewalld is inactive or not available while libvirtd is start,libvirt will use the iptables/ip6tables/ebtables tools directly to add the rules, which has nothing to do with the firewalld service. Right?

And this error is because the libvirtd start while the firewalld is active, so by default, this libvirtd daemon will use firewalld to manage its rules through its lifecycle. When we start default network which need to invoke the firewalld to add the rules, the error will occur as the firewalld is inactive. right?

Thank you in advance and look forward for your response...
Comment 8 Laine Stump 2016-09-19 14:07:27 EDT
(In reply to yalzhang@redhat.com from comment #7)

> Could you please help to confirm if I get the point?
> Current libvirt has been integrated with firewalld, that is to say,if we
> start the libvirtd service while the firewalld service is active,libvirtd
> will use DBus API to use firewalld to manage the iptables rules (this is the
> default choice).

Not the default choice, but just the way it is - if firewalld is running when libvirtd starts, libvirtd will use firewalld's DBUS API for that entire run of libvirtd (and fail with an error message if firewalld suddenly becomes unavailable).

> If the firewalld is inactive or not available while libvirtd
> is start,libvirt will use the iptables/ip6tables/ebtables tools directly to
> add the rules, which has nothing to do with the firewalld service. Right?

Correct.

> And this error is because the libvirtd start while the firewalld is active,
> so by default, this libvirtd daemon will use firewalld to manage its rules
> through its lifecycle. When we start default network which need to invoke
> the firewalld to add the rules, the error will occur as the firewalld is
> inactive. right?

Yes, if you've stopped firewalld after libvirtd has determined it was running, the next time you try to do anything that requires adding or removing iptables rules, the operation will fail because the DBUS API is no longer available.

If this occurs, libvirtd can be restarted, and will then re-probe for the presence of firewalld.

> 
> Thank you in advance and look forward for your response...

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