On 11/24/21 16:01, Elias Mobery wrote:
Hello Michal, thank you for the reply!
I've carefully tested everything you suggested, thanks.
I set dynamic_ownership=0 and use these hooks during the live build for permissions. (I googled a lot, and apparently libvirt needs the images to be executable too)
chown -R libvirt-qemu:kvm /var/lib/libvirt/images chmod -R g+rwx /var/lib/libvirt/images
I don't think this is correct. I don't have any of my images executable and still run VMs happily.
Booting the live debian iso everything works in virt-manager, but again, after clicking "run", a copy of the vm image is created in /run/live/overlay/rw/var/lib/libvirt/images and only then does the VM start.
So who/what creates this copy? Is this a feature of underlying FS or what exactly? It's definitely not libvirt who creates those copies.
Either it's still being chowned or chmodded somehow, or it's something else, but I can't stop this copy being made.
Interestingly, when I boot the Live debian iso and then copy the images into /var/lib/libvirt/images from my USB stick, the VM starts immediately without creating any copies in the /run/live.... directory. So my guess is that maybe the squashfs could be the issue?
Editing the XML
<source file='/var/lib/libvirt/images/vm1.qcow2'> <seclabel relabel='no'/> </source>
This results in an error: Unsupported Configuration: Security driver model 'null' not available> Here I tried setting security_driver=none in qemu.conf but same error after.
</devices> <seclabel type='none'/> </domain>
This should have been: <seclabel type='none' model='dac'/> and if you are running with SELinux you want to repeat that for model='selinux' too. Michal