Comment 17 for bug 1678322

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