<div dir="auto">Hey Martin & Michal, thank you both for the replies!<div dir="auto"><br></div><div dir="auto">Yes, sorry I messed up that seclabel entry, thanks. I fixed it and there is no more error, but the images are still copied unfortunately.</div><div dir="auto"><br></div><div dir="auto"><span style="background-color:rgb(239,154,154)">@Michal</span> yes, I have been reading the Debian Live Manual like a contract, after messing with qemu.conf and permissions for days, I think its something in the live build and not libvirt.</div><div dir="auto"><span style="background-color:rgb(144,202,249)"><br></span></div><div dir="auto"><span style="background-color:rgb(144,202,249)">@Martin</span> yeah both virsh start and virt-manager cause the images to be copied to /run..... first.</div><div dir="auto"><br></div><div dir="auto">Yes, when I boot the Debian Live ISO, plug in the USB (mounted rw), copy the images to the live system from the USB and click run in virt-manager, the VM starts instantly and no copies are made in /run....</div><div dir="auto"><br></div><div dir="auto">I use ISO loopback and toram to load the system directly into ram via tmpfs mount. That's my grub.cfg</div><div dir="auto"><br></div><div dir="auto"><span style="color:rgb(46,139,87);font-family:monaco,"andale mono","courier new",courier,monospace;font-size:11.7px;white-space:pre-wrap;background-color:rgb(255,255,255)">menuentry "debian-live.iso" {
  set iso="/ISO/debian-live.iso"
  set root=(hd0,5)
  loopback loop $iso
  linux (loop)/live/vmlinuz-4.19.0-6-</span><span style="color:rgb(46,139,87);font-family:monaco,"andale mono","courier new",courier,monospace;font-size:11.7px;white-space:pre-wrap;background-color:rgb(255,255,255)">amd64 boot=live components toram findiso=$iso
  initrd (loop)/live/initrd.img-4.19.0-</span><span style="color:rgb(46,139,87);font-family:monaco,"andale mono","courier new",courier,monospace;font-size:11.7px;white-space:pre-wrap;background-color:rgb(255,255,255)">6-amd64
}</span><br></div><div dir="auto"><br></div><div dir="auto">So, the squashfs is mounted read-only in /run/live/rootfs/filesystem.squashfs and its /dev/loop1</div><div dir="auto"><br></div><div dir="auto">/proc/mounts says:</div><div dir="auto"><br></div><div dir="auto">tmpfs /run/live/overlay rw</div><div dir="auto">overlay rw  lowerdir=/run/live/rootfs/filesystem.squashfs </div><div dir="auto">upperdir=/run/live/overlay/rw  (same place where the images are copied)</div><div dir="auto"><br></div><div dir="auto">So you think that because the images are part of the squashfs which is read-only, they are first copied to /run/live/overlay/rw... to be written to?</div><div dir="auto"><br></div><div dir="auto">I always thought that tmpfs is mounted on top of squash, so it's as if the squashfs were writable, without having to literally copy between the two filesystems.</div><div dir="auto"><br></div><div dir="auto">Also I made the same build with Virtualbox and there is no copying of the images to /run/live/overlay.</div><div dir="auto"><br></div><div dir="auto">I will do some serious research into squashfs and tmpfs rn.</div><div dir="auto"><br></div><div dir="auto"><br></div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Nov 24, 2021, 5:10 PM Martin Kletzander <<a href="mailto:mkletzan@redhat.com" target="_blank" rel="noreferrer">mkletzan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Nov 24, 2021 at 04:01:34PM +0100, Elias Mobery wrote:<br>
>Hello Michal, thank you for the reply!<br>
><br>
>I've carefully tested everything you suggested, thanks.<br>
><br>
>I set dynamic_ownership=0 and use these hooks during the live build for<br>
>permissions. (I googled a lot, and apparently libvirt needs the images to<br>
>be executable too)<br>
><br>
>chown -R libvirt-qemu:kvm  /var/lib/libvirt/images<br>
>chmod -R g+rwx /var/lib/libvirt/images<br>
><br>
<br>
I do not see why would the images need to be executable, you might need<br>
an executable bit set on the directory so that your and qemu user can<br>
browse it.<br>
<br>
>Booting the live debian iso everything works in virt-manager, but again,<br>
>after clicking "run", a copy of the vm image is created in<br>
>/run/live/overlay/rw/var/lib/libvirt/images and only then does the VM start.<br>
><br>
<br>
Does that happen when you try to run it with virsh instead of<br>
virt-manager?  Are you connected to the system daemon?<br>
<br>
>Either it's still being chowned or chmodded somehow, or it's something<br>
>else, but I can't stop this copy being made.<br>
><br>
>Interestingly, when I boot the Live debian iso and then copy the images<br>
>into /var/lib/libvirt/images from my USB stick, the VM starts immediately<br>
>without creating any copies in the /run/live.... directory. So my guess is<br>
>that maybe the squashfs could be the issue?<br>
><br>
<br>
Oh, interesting, is the USB stick filesystem mounted R/W and the live<br>
ISO filesystem mounted read-only?  How is the overlay mounted?<br>
<br>
>Editing the XML<br>
><br>
><source file='/var/lib/libvirt/images/vm1.qcow2'><br>
>      <seclabel relabel='no'/><br>
>    </source><br>
><br>
>This results in an error:<br>
>Unsupported Configuration:<br>
>Security driver model 'null' not available<br>
><br>
<br>
For issues like this it is most helpful to check the documentation:<br>
<br>
   <a href="https://libvirt.org/formatdomain.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://libvirt.org/formatdomain.html</a><br>
<br>
where you can see it is just a missing attribute `model`, in this case<br>
model="dac".<br>
<br>
>Here I tried setting security_driver=none in qemu.conf but same error after.<br>
><br>
></devices><br>
>    <seclabel type='none'/><br>
>  </domain><br>
><br>
<br>
Same here.<br>
<br>
>This also returns an Error but I'm still googling to understand it properly.<br>
><br>
>XML document failed to validate against schema<br>
>Unable to validate doc against /usr/share/libvirt/schemas/domain.rng<br>
>Invalid element relabel  for element seclabel<br>
>Extra element seclabel in interleave<br>
>Element domain failed to validate content<br>
><br>
>Thanks again so much for your helo, I've been messing with this for weeks<br>
>now and it's killing me.<br>
><br>
>On Tue, Nov 23, 2021, 9:43 PM Michal Prívozník <<a href="mailto:mprivozn@redhat.com" rel="noreferrer noreferrer" target="_blank">mprivozn@redhat.com</a>> wrote:<br>
><br>
>> On 11/23/21 17:25, Elias Mobery wrote:<br>
>> ><br>
>> > Hi everyone!<br>
>> ><br>
>> > I've built a Debian Live ISO with packages qemu and libvirt to run a VM<br>
>> > in the live environment.<br>
>> ><br>
>> > The guest images are placed in  /var/lib/libvirt/images and 2GB each.<br>
>> ><br>
>> > Everything works great, except for one issue.<br>
>> ><br>
>> > When starting a VM, libvirt automatically issues a chown command to the<br>
>> > images, changing ownership.<br>
>> ><br>
>> > This results in a copy of the images being created in<br>
>> > /run/live/overlay/rw/var/lib/libvirt/images<br>
>> ><br>
>> > I don't want these copies to be made but can't stop it.<br>
>> ><br>
>> > I've tried editing qemu.conf user/group, dynamic ownership etc. without<br>
>> > any luck.<br>
>> ><br>
>> > Is there a way to STOP libvirt from changing the ownership of these<br>
>> images?<br>
>> ><br>
>> ><br>
>><br>
>> Setting dynamic_ownership=0 in qemu.conf is the way to go (don't forget<br>
>> to restart the daemon after you made the change).<br>
>><br>
>> Alternatively, you can set <seclabel/> either for whole domain or<br>
>> individual disks, e.g. like this:<br>
>><br>
>>   <disk type='file' device='disk'><br>
>>     <driver name='qemu' type='qcow2'/><br>
>>     <source file='/var/lib/libvirt/images/vm1.qcow2'><br>
>>       <seclabel relabel='no'/><br>
>>     </source><br>
>>   </disk><br>
>><br>
>> or for whole domain:<br>
>><br>
>>     ...<br>
>>     </devices><br>
>>     <seclabel type='none'/><br>
>>   </domain><br>
>><br>
>> I'm not sure what your setup is, but if chown() is a problem then what<br>
>> if guest tries to write onto its disk? Wouldn't that create a copy in<br>
>> overlay?<br>
>><br>
>> Michal<br>
>><br>
>><br>
</blockquote></div></div>