Taking out the memtune and attach gdb to libvirtd and breaks on:
- virProcessSetMaxMemLock
- virProcessPrLimit
Check limits, qemu by default is on "16777216"
Then run
virsh attach-device z-test ~/VF-5.1.1.3.xml
Thread 2 "libvirtd" hit Breakpoint 1, 0x00003fffa85e58f8 in
virProcessSetMaxMemLock (pid=35967, bytes=2164260864)
At this time we have:
- 35967 is the correct pid of the target qemu
- 2164260864 would be higher and might be what libvirt thinks it needs now
So all should be right and in fact it is - virProcessPrLimit is auto-inlined
which makes it less obvious.
But it goes the right path to call virProcessPrLimit.
This is implemented as:
prlimit(pid, resource, new_limit, old_limit);
Exactly on this call I see the setrlimit DENY appear in the log.
A qucik check revealed that this is how prlimit is implemented in glibc.
So the direct setrlimit call in virProcessSetMaxMemLock was a bit of a red
herring.
It went the right path via prlimit and then the apparmor block kills it.
On prlimit I see correctly:
$4 = {rlim_cur = 2164260864, rlim_max = 2164260864}
According to the doc of prlimit that means capabilities are needed:
To set or get the resources of a process other than itself, the caller must have
"the CAP_SYS_RESOURCE capability, or the real, effective, and saved set user
IDs of the target process must match the real user ID of the caller and
the real, effective, and saved set group IDs of the target process must match
the real group ID of the caller."
WIll discuss that on the spn-off apparmor bug 1679704
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1678322
Title:
Ubuntu 17.04 KVM: Can not do hotplug attach
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1678322/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
