Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1352265 - After upgrade to F24, qemu:///session guest can't start due to capability error
Summary: After upgrade to F24, qemu:///session guest can't start due to capability error
Keywords:
Status: CLOSED DUPLICATE of bug 1351995
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-03 05:16 UTC by Dimitris
Modified: 2016-07-04 17:30 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-04 01:53:56 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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!
Note You need to log in before you can comment on or make changes to this bug.