Re: Libvirt + Debian Live = Heart Attack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hey Martin & Michal, thank you both for the replies!

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.

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

@Martin yeah both virsh start and virt-manager cause the images to be copied to /run..... first.

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

I use ISO loopback and toram to load the system directly into ram via tmpfs mount. That's my grub.cfg

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-amd64 boot=live components toram findiso=$iso initrd (loop)/live/initrd.img-4.19.0-6-amd64 }

So, the squashfs is mounted read-only in /run/live/rootfs/filesystem.squashfs and its /dev/loop1

/proc/mounts says:

tmpfs /run/live/overlay rw
overlay rw  lowerdir=/run/live/rootfs/filesystem.squashfs 
upperdir=/run/live/overlay/rw  (same place where the images are copied)

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?

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.

Also I made the same build with Virtualbox and there is no copying of the images to /run/live/overlay.

I will do some serious research into squashfs and tmpfs rn.

On Wed, Nov 24, 2021, 5:10 PM Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:
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:

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

>Here I tried setting security_driver=none in qemu.conf but same error after.
>    <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

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux