Bug 1348434
Summary: | internal error: Unable to apply rule 'The name org.fedoraproject.FirewallD1 was not provided by any .service files' | |||
---|---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Damian Nowak <spam> | |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> | |
Status: | CLOSED DEFERRED | QA Contact: | ||
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | unspecified | CC: | cfillekes, crobinso, herrold, laine, libvirt-maint, rbalakri, wvoesch, ztehypervisor | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | If docs needed, set a value | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1544937 (view as bug list) | Environment: | ||
Last Closed: | 2016-06-22 11:31:50 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1903544 |
Description
Damian Nowak
2016-06-21 07:38:19 UTC
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 |