Libvirt + Debian Live = Heart Attack
Michal Prívozník
mprivozn at redhat.com
Wed Nov 24 16:04:15 UTC 2021
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
More information about the libvirt-users
mailing list