Hey man, I tried both suggestions, thanks again. Option 1.) Create/attach a second qcow2 disk & unplug when wiping. This did not work unfortunately. After wiping the overlay filesystem on the host (where the snapshots are sitting), I cannot create another snapshot, a similar error message like before appears.
Option 2.) Enabling Discard Now I think this worked, but I'm not sure. I read all the docs, and enabled discard like so on the VM domain: <driver name='qemu' type='qcow2' discard='unmap'> I tried both discard=unmap and discard=on (same thing) Then I enabled fstrim in the guest like this: (Not entirely sure if I am missing smth) sudo fstrim -av Or permanently sudo systemctl enable --now fstrim.timer On Tue, Nov 30, 2021, 4:08 PM Elias Mobery <eliasmob...@gmail.com> wrote: > Hey Peter, thanks for the super quick reply, you're awesome! > > So you mean the first option would be to create a second disk instead of > using snapshot for write, when it gets too big I can then unplug the disk, > delete it (or wipe entire overlay fs) and recreate it to start fresh? > > OK I will try that, thanks for the tip! > > Option 2 with trim/discard I have to do some research, this seems a bit > more challenging. > > Thank you SO much for the great advice. I will try everything out and > report back. :-) > > > On Tue, Nov 30, 2021, 3:25 PM Peter Krempa <pkre...@redhat.com> wrote: > >> On Tue, Nov 30, 2021 at 14:51:54 +0100, Elias Mobery wrote: >> > Hello Peter, thank you so much for that detailed info! >> > >> > Sorry, you were right, when trying to delete my external snapshot via >> > snapshot-delete, the error says "deletion of external snapshots >> unsupported" >> > >> > I can't merge the snapshot because the VM image is in a read-only >> > filesystem. Sorry I should've said, it's a live system. So the image is >> in >> > the read-only squashfs and external snapshot in overlay is used for >> writing. >> >> Okay, that changes the situation quite a bit: >> >> > >> > Now I would like the snapshot emptied or deleted/recreated when it >> reaches >> > 4GB. >> > >> > Is there even a way to do this with the image being read-only? >> >> If the base image is on a read-only filesystem you obviously can't >> commit to it. >> >> Now the question is what should happen to the data in the overlay. >> >> Discarding/recreating the overlay image is possible only once you turn >> off the VM because it basically rolls back the state of the disk back to >> the time when the overlay was created. This means that everything >> written to the disk will be lost. >> >> Filesystems obviously can't handle that so that's why it simply won't be >> possible to do live with the root image. >> >> You can have a second disk, which you hot-unplug, wipe the overlay and >> plug it back. >> >> Another possibility is to enable trim/discard and just simply delete the >> data in the VM which was added after the overlay was created. When >> trim/discard is enabled on all layers incluging the guest filesystem, >> then deleting stuff inside the VM will also mean that the overlay will >> shrink again. >> >>
