Dear Maintainer!<style>
                        
                                body {
                                        font-family: 'Arial';
                                        font-size: 100% !important;
                                        margin: 0;
                                        line-height: 1.2rem;
                                        color: #1F497D;
                                }
                                
                        </style><div><br></div><div>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):</div><div><br></div><div>> root@root:~# virsh blockcommit {vm-name} vda --active --wait --pivot</div><div>> error: internal error: unable to execute QEMU command 'block-commit': Could not reopen file: Permission denied</div><div><br></div><div><div>> qemu-img version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u4)</div></div><div><div>> libvirtd (libvirt) 5.0.0</div></div><div><br></div><div>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):</div><div>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932456#25</div><div><br></div><div>However, the behaviour does *not* disappear when AppArmor is disabled using complain mode:</div><div><br></div><div>> apt install apparmor-utils</div><div>> aa-complain /usr/sbin/libvirtd</div><div>> aa-complain /etc/apparmor.d/libvirt/libvirt-{id}</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>This bug is critical because one is not able to create backups of the guests without shutting them down.</div><div><br></div><div>Is there any workaround available?</div><div><br></div><div>Kind Regards,</div><div>Kaulkwappe</div>