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 871196 - qemu: could not load kernel ... Permission denied
Summary: qemu: could not load kernel ... Permission denied
Keywords:
Status: CLOSED DUPLICATE of bug 1269975
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Michal Privoznik
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs 910270 922891
TreeView+ depends on / blocked
 
Reported: 2012-10-29 21:31 UTC by Richard W.M. Jones
Modified: 2016-04-26 21:30 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 921135 (view as bug list)
Environment:
Last Closed: 2016-01-15 20:22:00 UTC
Embargoed:

Attachments (Terms of Use)

Description Richard W.M. Jones 2012-10-29 21:31:44 UTC 
Description of problem:

This manifests itself as the libguestfs test suite
occasionally failing like this:

*stdin*:2: libguestfs: error: could not create appliance through libvirt: internal error process exited while connecting to monitor: 2012-10-29 21:27:55.614+0000: 20366: debug : virFileClose:72 : Closed fd 22
2012-10-29 21:27:55.614+0000: 20366: debug : virFileClose:72 : Closed fd 35
2012-10-29 21:27:55.630+0000: 20366: debug : virFileClose:72 : Closed fd 3
2012-10-29 21:27:55.653+0000: 20367: debug : virCommandHook:2143 : Hook is done 0
qemu: could not load kernel '/home/rjones/d/libguestfs/tmp/.guestfs-1000/kernel.20244': Permission denied
 [code=1 domain=10]

There are multiple parallel libguestfs instances running.
The best explanation of this I can come up with is that
libvirtd is unlabelling the <kernel/> element at the same
time that another qemu is trying to open it.

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

libvirt-0.10.2-3.fc18.x86_64

How reproducible:

Very rare.
Comment 1 Richard W.M. Jones 2013-03-13 11:12:22 UTC 
Still happening with libguestfs upstream and recent libvirt.

libvirt-daemon-1.0.2-3.fc19.x86_64

A test program which demonstrates this and nearly always
fails for me is here:

https://github.com/libguestfs/libguestfs/blob/master/tests/parallel/test-parallel.c
Comment 2 Michal Privoznik 2013-03-13 14:46:43 UTC 
I believe this can be solved with my "Keep original file label" patchset:

https://www.redhat.com/archives/libvir-list/2013-March/msg00497.html

Although I am solving this issue for DAC only for now. I am introducing reference counter on XATTR level to trace how many times did libvirt label a file, so it the label is restored only at the last restore request. So if your explanation is right, the kernel image will be:

1. labeled due to domain A startup, refCount = 1,
2. labeled due to domain B startup, refCount = 2,
3. domain A shutdown will just decrease refCount to 1,
4. shutting down domain B will decrease refCount and since it's 0 now, the original file label is restored.
Comment 3 Richard W.M. Jones 2013-10-17 12:16:45 UTC 
Just seen this again with libvirt-daemon-1.1.3-2.fc21.x86_64
when running the highly parallel virt-df test in the
libguestfs test suite.
Comment 4 Cole Robinson 2015-04-25 23:07:47 UTC 
This bug is pretty old... Rich do you still see it on occasion?
Comment 5 Richard W.M. Jones 2015-04-26 08:15:19 UTC 
Not recently.
Comment 6 Richard W.M. Jones 2016-01-13 10:02:44 UTC 
Reopening as this still happens with libvirt-1.3.0-1.fc24
Comment 7 Richard W.M. Jones 2016-01-15 20:22:00 UTC 

*** This bug has been marked as a duplicate of bug 1269975 ***
Note You need to log in before you can comment on or make changes to this bug.