It's quite simple. For example , you got vm1 with 10GB OS disk that is fully preallocated (actual size is really 10GB). Now imagine that you create a snapshot of this vm1 and you download 1GB file from another place. You will see 2 disk files on the storage domain: - The original one that was made read-only during the snapshot process - A new 1GB file that represents the delta (changes between snapshot and current state) The second file is read-write and if left as is - it will grow up to 10GB (the actual disk of the vm1). When the Virtualization is looking for some data it has to search into 2 places which will reduce performance a little bit.If you decide to create another snapshot, the second disk will be made read-only and another one will be created and so on and so on. When you delete a snapshot, the disks will be merged in such way so newer snapshot disks remain, while the rest are merged into a single file. Restoring a snapshot is simplest - everything after that snapshot is deleted and the vm1 will use the snapshot disk till you delete (which will merge base disk with snapshot disk) that snapshot. Best Regards, Strahil Nikolov На 2 август 2020 г. 3:53:11 GMT+03:00, jorgevisentini(a)gmail.com написа: >Hello everyone. > >I would like to know how disk size and snapshot allocation works, >because every time I create a new snapshot, it increases 1 GB in the >VM's disk size, and when I remove the snap, that space is not returned >to Domain Storage. > >I'm using the oVirt 4.3.10 > >How do I reprovision the VM disk? > >Thank you all. >_______________________________________________ >Users mailing list -- users(a)ovirt.org >To unsubscribe send an email to users-leave(a)ovirt.org >Privacy Statement: https://www.ovirt.org/privacy-policy.html >oVirt Code of Conduct: >https://www.ovirt.org/community/about/community-guidelines/ >List Archives: >https://lists.ovirt.org/archives/list/users@ovirt.org/message/3TG24XR77PISMBRZ5S5L4P7DV56SUDON/

Yes, I understand, but my question is whether I can reclaim the allocated space after deleting the snapshot. Because oVirt is not returning space, it is only increasing, even though you have not done anything in the snapshot. That is, with each snapshot I create, it increases 1GB, and even after deleting it, it does not reclaim this space.

On Tue, Aug 4, 2020 at 4:50 PM <jorgevisentini(a)gmail.com&gt; wrote: This is a known issue when you remove the last snapshot with a running VM. If you stop the VM before deleting the snapshot, this will not happen. The only way to reclaim the space now is: 1. Stop the VM 2. Create snapshot 3. Delete the created snapshot This will merge the new empty snapshot into the old top volume, which has 1G extra space for every snapshot you created in the past. Since the VM is not running, we can safely shrink the top volume to the optimal size after the merge. A little better way is to call the Disk.reduce() API - this can be scripted: 1. Stop the VM 2. Reduce the disk to optimal size 3. Start the VM Use the API: http://ovirt.github.io/ovirt-engine-api-model/4.4/#services/disk/methods/... Or the SDK: http://ovirt.github.io/ovirt-engine-sdk/4.4/services.m.html#ovirtsdk4.ser... It is possible to fix this in libvirt 6.0, and may also solve other problems with snapshots, but this is a very delicate change. If you think this is important to fix, please file a vdsm bug: https://bugzilla.redhat.com/enter_bug.cgi?product=vdsm Nir

On Thu, Oct 28, 2021 at 7:21 PM <christian.peater(a)gmx.de&gt; wrote: I think the only way you can optimize the disk size is to move the disk to another storage domain and back to the original storage domain. When we copy a disk, we measure every volume in the chain, and create a new volume in the destination storage, using the optimal size for this volume. Then we copy the data from the source volume to the new volume using qemu-img convert. When qemu-img convert copy an image, it detects unallocated areas or areas which reads as zeroes. In the target image, these areas will not be allocated, or will be stored efficiently as zero clusters (8 byte for 64k of data). Detecting zeroes happens during the copy, not when you measure the volume, so after the first copy the disk, may still have unneeded allocation at lvm level. When you copy the disk back to original storage, this extra allocation will be eliminated. This is not a fast operation, but you can move disks when vms are running, so there is no downtime. You can try this with a new vm: 1. create vm with 100g thin data disk 2. in the guest, fill the disk with zeros dd if=/dev/zero bs=1M count=102400 of=/dev/sdb oflag=direct status=progress 3. the vm disk will be extended to 100g+ 4. move the disk to another storage domain 5. after the move, the disk's actual size will be 100g+ 6. move the disk back to original storage 7. the disk actual size will go back to 1g Note that enabling discard and using fstrim in the guest before the copy will optimize the process. 1. create vm with 100g thin virtio-scsi data disk, with "enable discard" 2. in the guest, fill the disk with zeros dd if=/dev/zero bs=1M count=102400 of=/dev/sdb oflag=direct status=progress 3. the vm disk will be extended to 100g+ 4. in the guest, run "fstrim /dev/sdb" 5. the disk size will remain 100g+ 6. move the disk to another storage domain 7. this move will be extremly quick, no data will be copied 8. the disk actual size on the destination storage domain will be 1g In ovirt 4.5 we plan to support disk format conversion - this will allow this kind of sparsification without copying the data twice to another storage domain. Nir