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.
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 <pkrempa at 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. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20211130/d664e11e/attachment.htm>
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 <eliasmobery at 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 <pkrempa at 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. >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20211201/595ceb4b/attachment.htm>