Comment 2 for bug 1710960

Thanks for spawning off that bug from the former discussion Dann!
I'd really like to see the associated dmesg for the expected apparmor denial to be confirmed.

Given your XML was able to check what we get generated (stripped down to the interesting bits).
$ ./src/virt-aa-helper --create --dryrun --uuid 'libvirt-bead65d7-c9ed-4cdc-9a2c-953fbb59faf8' < ~/Downloads/5531-0.xml
  "/home/ubuntu/vm-start-stop/vms/5531-0.img" rwk,
  "/home/ubuntu/vm-start-stop/vms/5531-0_CODE.fd" r,
  # don't audit writes to readonly files
  deny "/home/ubuntu/vm-start-stop/vms/5531-0_CODE.fd" w,
  "/home/ubuntu/vm-start-stop/vms/5531-0_VARS.fd" rw,

So we have an explicit readonly and the new code is trying a lock.
The deny is to have writes not fill up logs and deny silently.
Very likely we need (mind the k there):
  "/home/ubuntu/vm-start-stop/vms/5531-0_CODE.fd" rk,

If you want you can try to tune "/etc/apparmor.d/libvirt/libvirt-<uuid>" before the include to the .files (or in /etc/apparmor.d/abstractions/libvirt-qemu for all guests) with rules to allow that if that unblocks you.

I'm not sure if locking requires write in the apparmor way of thinking.
In the worst case the explcit deny wil hide that - so consider removing it if you see nothing.

Looking forward to the dmesg to confirm