After several days of work, libvirt no longer wanted to start VMs. root@ovh1 ~ # virsh start 138_xy.com_abcd error: Failed to start domain 138_xy.com_abcd error: The name org.fedoraproject.FirewallD1 was not provided by any .service files I stumbled upon a piece of advise on the internet: "Solution : libvirtd restart is needed between firewalld stopped and iptables started." https://github.com/redhat-cip/infra-virt#troubleshooting I would expect to not have to restart libvirtd. Package info - CentOS 7.2: Name : libvirt Arch : x86_64 Version : 1.2.17 Release : 13.el7_2.4
We discussed this at the time firewalld support was added to libvirt, and decided that the occurrence of starting/stopping firewalld is quite rare, and the solution (restarting libvirtd) is simple. That, combined with the difficulty of getting it right *without* a libvirtd restart, led to the decision to not support switching from firewalld use to raw iptables use without restarting libvirtd. That said, it might be nice if we could catch this particular condition and report something more useful.
(In reply to Laine Stump from comment #1) > We discussed this at the time firewalld support was added to libvirt, and > decided that the occurrence of starting/stopping firewalld is quite rare, > and the solution (restarting libvirtd) is simple. That, combined with the > difficulty of getting it right *without* a libvirtd restart, led to the > decision to not support switching from firewalld use to raw iptables use > without restarting libvirtd. > Makes sense to me. > That said, it might be nice if we could catch this particular condition and > report something more useful. IMO it's not worth fixing... how do we distinguish between a user deliberately stopping firewalld, or firewalld crashing, or just connection fails for other reasons? We could throw in a hint but if a user deliberately disables firewalld, and libvirtd throws an error like that, I think it's a pretty good indication that a libvirtd restart is worth a shot. Plus that linked page with the troubleshooting section, the steps at the top of the page should be stick a libvirtd restart after disabling firewalld. Their steps basically enforce hitting that error Closing as DEFERRED, but if someone has suggestions for improving the error that avoid that ambiguity I suggest sending a patch to libvir-list
> if a user deliberately disables firewalld, and libvirtd throws an error like that, I think it's a pretty good indication that a libvirtd restart is worth a shot. How can user be aware that changing something in the system may affect a different service, like libvirt? What if sysadmin #1 changes while sysadmin #2 gets that error? (Actually my case) This type of message belongs to a category of wtf-like messages that only Google can help with. Why not something like that? root@ovh1 ~ # virsh start 138_xy.com_abcd error: Failed to start domain 138_xy.com_abcd error: The name org.fedoraproject.FirewallD1 was not provided by any .service files error: If you disabled Firewalld after libvirtd start, please restart libvirtd It makes everyone's life easier at the expense of a couple extra lines of code. Libvirt error messages are typically very informative so it would play well with the rest.
(In reply to Damian Nowak from comment #3) > > It makes everyone's life easier at the expense of a couple extra lines of > code. Libvirt error messages are typically very informative so it would play > well with the rest. For beginners,if we have these debugging information,it will be easier to solve the problem.
Not just for beginners - it's for everyone's convenience.
This problem still occurs, and its cause is 'invisible' (we manipulate the firewalld, for network ACL reasons) impairing / interrupting libvirtd connections (mostly interior networks facing) with a restart is a problem
it showed up in my comment 13 at: https://bugzilla.redhat.com/show_bug.cgi?id=1486803