On Fri, Feb 01, 2019 at 07:40:36PM -0200, Daniel Henrique Barboza wrote: > Update: I've figured it out. > > The bug here was that, even running as root, I was getting errors like: > > error : virQEMUCapsNewForBinaryInternal:4687 : internal error: Failed to > probe QEMU binary with > QMP: libvirt: error : prctl failed to enable 'dac_override' in the AMBIENT > set: > Operation not permitted Being responsible for the latest changes wrt to capabilities, this error itself is very strange because the prctl man page says the following about EPERM errno: "option is PR_CAP_AMBIENT and arg2 is PR_CAP_AMBIENT_RAISE, but either the capability specified in arg3 is not present in the process's permitted and inheritable capability sets, or the PR_CAP_AMBIENT_LOWER securebit has been set." So I'm wondering how can that be since that prctl call happens after we applied the capabilities we want with capng_apply. Just out of curiosity, what happens if you move the whole PR_CAP_AMBIENT at the very end of virSetUIDGIDWithCaps function? Does it change anything? Thanks, Erik > > The reason is that the host has libcap-ng installed. ./configure uses it if > available, > setting WITH_CAPNG in the code. I am unsure if this has something to do with > the libcap-ng configuration in this system I'm using or if there is > something > missing in the Libvirt code, but the spawned QEMU process isn't inheriting > the > capabilities it should have. > > Disabling support of this lib with "--with-capng=no" in autogen.sh and > rebuilding Libvirt fixed the problem. I was even able to see more NUMA > nodes than I was before using the system libvirt (which is the original > bug I am/was investigating). > > > Thanks! > > > > > > On 2/1/19 4:04 PM, Daniel Henrique Barboza wrote: > > Hi, > > > > I'm facing a strange behavior when running Libvirt from source code, > > latest upstream, on an Ubuntu 18.04.1 LTS Power 9 server. My QEMU > > guest - which is using VFIO and GPU passthrough - breaks on boot when > > trying to allocate a DMA window inside KVM. > > > > Debugging the code, I've found out that the problem is related to the > > process > > not having CAP_IPC_LOCK - at least from the host kernel perspective. > > > > This is strange because: > > > > - the same VM running directly from QEMU command line works > > - the same VM running in the system Libvirt (v4.0.0, Ubuntu version) > > also works > > > > What am I missing? My understanding on Linux process is that a process > > running as root should inherit the same capabilities of the user, which > > includes > > CAP_IPC_LOCK. Running Libvirt from source code should grant ipc_lock > > to it ... right? > > > > > > > > Any help is appreciated. I can provide more details (VM XML for example) > > if necessary. > > > > > > Thanks! > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
