On Wed, Nov 24, 2021 at 04:01:34PM +0100, 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 do not see why would the images need to be executable, you might need
an executable bit set on the directory so that your and qemu user can
browse it.

>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.
>

Does that happen when you try to run it with virsh instead of
virt-manager?  Are you connected to the system daemon?

>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?
>

Oh, interesting, is the USB stick filesystem mounted R/W and the live
ISO filesystem mounted read-only?  How is the overlay mounted?

>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
>

For issues like this it is most helpful to check the documentation:

   https://libvirt.org/formatdomain.html

where you can see it is just a missing attribute `model`, in this case
model="dac".

>Here I tried setting security_driver=none in qemu.conf but same error after.
>
></devices>
>    <seclabel type='none'/>
>  </domain>
>

Same here.

>This also returns an Error but I'm still googling to understand it properly.
>
>XML document failed to validate against schema
>Unable to validate doc against /usr/share/libvirt/schemas/domain.rng
>Invalid element relabel  for element seclabel
>Extra element seclabel in interleave
>Element domain failed to validate content
>
>Thanks again so much for your helo, I've been messing with this for weeks
>now and it's killing me.
>
>On Tue, Nov 23, 2021, 9:43 PM Michal Prívozník <mprivozn@redhat.com> wrote:
>
>> On 11/23/21 17:25, Elias Mobery wrote:
>> >
>> > Hi everyone!
>> >
>> > I've built a Debian Live ISO with packages qemu and libvirt to run a VM
>> > in the live environment.
>> >
>> > The guest images are placed in  /var/lib/libvirt/images and 2GB each.
>> >
>> > Everything works great, except for one issue.
>> >
>> > When starting a VM, libvirt automatically issues a chown command to the
>> > images, changing ownership.
>> >
>> > This results in a copy of the images being created in
>> > /run/live/overlay/rw/var/lib/libvirt/images
>> >
>> > I don't want these copies to be made but can't stop it.
>> >
>> > I've tried editing qemu.conf user/group, dynamic ownership etc. without
>> > any luck.
>> >
>> > Is there a way to STOP libvirt from changing the ownership of these
>> images?
>> >
>> >
>>
>> Setting dynamic_ownership=0 in qemu.conf is the way to go (don't forget
>> to restart the daemon after you made the change).
>>
>> Alternatively, you can set <seclabel/> either for whole domain or
>> individual disks, e.g. like this:
>>
>>   <disk type='file' device='disk'>
>>     <driver name='qemu' type='qcow2'/>
>>     <source file='/var/lib/libvirt/images/vm1.qcow2'>
>>       <seclabel relabel='no'/>
>>     </source>
>>   </disk>
>>
>> or for whole domain:
>>
>>     ...
>>     </devices>
>>     <seclabel type='none'/>
>>   </domain>
>>
>> I'm not sure what your setup is, but if chown() is a problem then what
>> if guest tries to write onto its disk? Wouldn't that create a copy in
>> overlay?
>>
>> Michal
>>
>>