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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
