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
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!