Bug 1631622

Interesting problem - part of this is fixed as a "byproduct" of bz1607202. The fix for that results in failure of the API to just "VIR_WARN" any errors and continue on through restart without causing a failure.  So to that degree your guest will not reboot.

However, the second half of this is the error :

2018-09-21 05:24:28.271+0000: 2440: error : virAccessDriverPolkitGetCaller:87 : access denied: Policy kit denied action org.libvirt.api.connect.getattr from <anonymous>

and ends up generating those sanitized error reports.

What's interesting about this is that it doesn't seem we should be getting <anonymous> in virAccessDriverPolkitGetCaller, but that's coming because virIdentityGetCurrent is returning NULL.

This didn't quite make sense until one considers that the qemuProcessReconnect* code was made into a thread in order to process the reconnect - this way multiple domains can be reconnected simultaneously rather than in single file.

However, in creating that thread we don't maintain the identity values from the caller and thus when we try to make a connection call from that thread we fail because we don't have identity.

I've proposed a fix upstream as patch 2 of :

https://www.redhat.com/archives/libvir-list/2018-November/msg00339.html

After a review cycle, patch v2 series posted:

https://www.redhat.com/archives/libvir-list/2018-November/msg00434.html

reviewed and pushed:


commit b04b82f8cb671f067bad2d5e922acf88f13f0934
Author: John Ferlan <jferlan>
Date:   Mon Nov 12 08:27:26 2018 -0500

    qemu: Set identity for the reconnect all thread
    
    ...
    
    If polkit authentication is enabled, an attempt to open
    the connection failed during virAccessDriverPolkitGetCaller
    when the call to virIdentityGetCurrent returned NULL resulting
    in the errors:
    
      virAccessDriverPolkitGetCaller:87 : access denied:
      Policy kit denied action org.libvirt.api.connect.getattr from <anonymous>
    
    Because qemuProcessReconnect runs in a thread during
    daemonRunStateInit processing it doesn't have the thread
    local identity. Thus when the virGetConnectNWFilter is
    called as part of the qemuProcessFiltersInstantiate when
    virDomainConfNWFilterInstantiate is run the attempt to get
    the idenity fails and results in the anonymous error above.
    
    To fix this, let's grab/use the virIdenityPtr of the process
    that will be creating the thread, e.g. what daemonRunStateInit
    has set and use that for our thread. That way any other similar
    processing that uses/requires an identity for any other call
    that would have previously been successfully run won't fail in
    a similar manner.
 ...

$ git describe b04b82f8cb671f067bad2d5e922acf88f13f0934
v4.9.0-56-gb04b82f8cb
$

Reproduce the error with the steps in comment 0 on libvirt-4.5.0-10.el7_6.7.x86_64
Test on libvirt-4.5.0-12.el7.x86_64, the bug is fixed.

1. Edit the libvirtd.conf with below settings:
unix_sock_rw_perms = "0777"
auth_unix_rw = "none"
access_drivers = [ "polkit" ]
log_level=2
log_outputs='2:file:/var/log/libvirt/libvirtd.log'

2. Restart libvirtd and start a vm with nwfilter configured.
3. Restart libvirtd.
4. check the vm is still running and healthy.
# virsh list 
 Id    Name                           State
----------------------------------------------------
 2     rhel                           running

5. check libvirtd log, no errors

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2294