Bug 1352265

Summary: After upgrade to F24, qemu:///session guest can't start due to capability error
Product: [Fedora] Fedora Reporter: Dimitris <dimitris>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: agedosier, berrange, clalancette, itamar, jdenemar, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-04 01:53:56 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:

Description Dimitris 2016-07-03 05:16:38 UTC
Description of problem:

Upgraded from F23 to F24, trying to start my work-related qemu:///session VMs.  After working around another regression (bug 1352263), I encountered this:

error: Failed to start domain <name>
error: internal error: Process exited prior to exec: libvirt:  error : internal error: cannot apply process capabilities -1

Version-Release number of selected component (if applicable):

1.3.3.1-4.fc24

How reproducible:

Every time

Steps to Reproduce:
1. Start the qemu:///session guest
2. Fails with the error above

Actual results:

Requires an security-reducing workaround: Setting clear_emulator_capabilities=0 in ~/.config/libvirt/qemu.conf (which didn't exist previously btw).

Expected results:

Previously I was able to run qemu:///session guests without any security-reducing step.

Additional info:

Comment 1 Dimitris 2016-07-04 01:53:56 UTC
Well, I don't know what changed; I wrote a user unit file to work around bug 1352263 and have virtlogd running whenever I log in; then when I tried to reproduce this bug, I could no longer do so.  Closing for now, will reopen if it happens again.

Comment 2 Jiri Denemark 2016-07-04 08:13:52 UTC
I think this is actually a duplicate of bug 1351995, which claims installing audit >= 2.6.2-1 fixes the issue, so I guess this could have fixed the issue for you...

Comment 3 Daniel Berrangé 2016-07-04 08:42:01 UTC

*** This bug has been marked as a duplicate of bug 1351995 ***

Comment 4 Dimitris 2016-07-04 17:30:17 UTC
That seems to be the case, audit was upgraded yesterday just as I was reading up on unit files.  Thanks for the quick response folks!