Description of problem: Using Disk.reduce API is allowed on active disk image, possibly corrupting the disk. When reducing an image, vdsm check current qcow2 allocation, and then reduce the logical volume using the calculated value. If the guest writes data fast enough, it can allocated new qcow2 clusters before the logical volume is reduced. Reducing the logical volumes will delete these clusters, corrupting the image. Version-Release number of selected component (if applicable): Reproducible with 4.4.3.6 Bug exists since 4.2.5.1. How reproducible: Always. Steps to Reproduce: 1. Run VM with qcow2 disk (e.g. with a snapshot) 2. Reduce the disk using the SDK disks_service = connection.system_service().disks_service() disk_service = disks_service.disk_service(disk_id) disk_service.reduce() Actual results: Reduce succeeds. Expected results: Reduce must be blocked for active image. Additional info: The bug exist since the Disk.reduce API was exposed to API, part of bug 1443963.
Reduce image is not supported for active image on engine-4.4.3-7 as expected. Moving to 'Verified'.
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
Interesting enough, reduce disk functionality is not documented anywhere - I searched customer portal for the word 'reduce' in RHV and nothing came up. We do have a KCS saying that reduce is not supported though: https://access.redhat.com/solutions/697303. Looking into bz#1443963 that introduced this functionality, no release note also to provide more details on it, it mentions that it is important to v2v on qcow disks. So maybe this bz could benefit from some release note documenting the fact that reduce disk is only available for non-active disks. And then we may also want to confirm with v2v team to understands if this blocks any workflow for them.
(In reply to Marina Kalinin from comment #3) One of the reasons to add this was virt-v2v, but it not use qcow2 format yet. When they start to use qcow2, they can use "qemu-img measure" to estimate the required allocation before the import, and use reduce to shrink the image to optimal size after an import.