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
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):
Still happening with libguestfs upstream and recent libvirt.
A test program which demonstrates this and nearly always
fails for me is here:
I believe this can be solved with my "Keep original file label" patchset:
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.
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.
This bug is pretty old... Rich do you still see it on occasion?
Reopening as this still happens with libvirt-1.3.0-1.fc24
*** This bug has been marked as a duplicate of bug 1269975 ***