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