[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH v2] process: Ignore nwfilter binding instantiation issues during reconnect

On Fri, Aug 24, 2018 at 08:30:50AM -0400, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1607202
> It's essentially stated in the nwfilterBindingDelete that we
> will allow the admin to shoot themselves in the foot by deleting
> the nwfilter binding which then allows them to undefine the
> nwfilter that is in use for the running guest...
> However, by allowing this we cause a problem for libvirtd
> restart reconnect processing which would then try to recreate
> the missing binding attempting to use the deleted filter
> resulting in an error and thus shutting the guest down.
> So rather than keep adding virDomainConfNWFilterInstantiate
> flags to "ignore" specific error conditions and since (so far)
> this is the only path that cared about checking if the filter
> already exists and ignoring, let's just ignore all errors and
> make the qemuProcessFiltersInstantiate be a void which will
> attempt to check all networks for bindings and reload all filters
> that exist. Using the VIR_INFO in order to at least "log" the
> avoided issue.
> This also means virDomainConfNWFilterInstantiate no longer
> needs to handle/check the ignoreExists possbility.
> Signed-off-by: John Ferlan <jferlan redhat com>
> ---
>  v1: https://www.redhat.com/archives/libvir-list/2018-August/msg01407.html
>  Changes - removed the ignoreExists and just change the logic for
>  reconnect processing to essentially ignore all errors.  If it's felt
>  the VIR_INFO would be too chatty (especially since it'll be generated
>  for every already defined filter binding), I can remove it. Another
>  option would be to keep the ignoreExists logic and only generate that
>  VIR_INFO for "other" messages. In that case, I'd probably want to change
>  it to a VIR_WARN.  Still figured I'd post the remove it all option first
>  for consideration with this caveat so that "option" can be considered
>  as well.

I guess the difference with 'ignore exists' is that this situation is
harmless. The binding is still active and thus network traffic is

In the other error scenarios, the failure indicates a problem that
likely means the network traffic is not confined.

So it probably makes sense to keep the ignoreExists flag and use
VIR_WARN for other errors.

|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]