[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
confined.

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.


Regards,
Daniel
-- 
|: 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]