I can confirm that this bug (#932456) unfortunately still exists in Debian 10.3 (Buster) while using only default configurations, no custom paths (so all images are placed in /var/lib/libvirt/images):
> root@root:~# virsh blockcommit {vm-name} vda --active --wait --pivot
> error: internal error: unable to execute QEMU command 'block-commit': Could not reopen file: Permission denied
> qemu-img version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u4)
> libvirtd (libvirt) 5.0.0
After some research I suspected the AppArmor configs to be the reason for the permission error which corresponds to the research Robert Niederreiter has already done on 13th October 2019 (Message #25):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932456#25
However, the behaviour does *not* disappear when AppArmor is disabled using complain mode:
> apt install apparmor-utils
> aa-complain /usr/sbin/libvirtd
> aa-complain /etc/apparmor.d/libvirt/libvirt-{id}
But what I noticed is that the owner and rights of the guest XML files (/run/libvirt/qemu/{vm-name}.xml) always change back to root:root and 0600 even if "dynamic_ownership" is set to 0 in /etc/libvirt/qemu.conf. Since the other file permissions look good I suspect this to have something to do with that issue.
Setting "security_driver" in /etc/libvirt/qemu.conf to "none" or changing "user" and "group" to root:root or to unprivileged:unprivileged did not solve the issue.
This bug is critical because one is not able to create backups of the guests without shutting them down.
Is there any workaround available?
Kind Regards,
Kaulkwappe
