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:
I am sorry, I have found what was causing the problem. Unfortunately, the Firewalld was stopped. The error message is not really descriptive.
If we showed the command output hopefully it'll make things clear
+1 for me too
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.
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 From hannsj_uhl.com 2016-02-25 09:46 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...
(In reply to yalzhang 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...