Unable to shrink QCOW2 volumes

[OlegChuev]

problem

A regression has been identified in the volume resizing logic introduced in ACS 4.20. Following the changes in PR #8755, specifically at this place, users are unable to shrink QCOW2 volumes in any state other than Allocated, unless StorPool storage is being used.

This change was introduced by the StorPool team in version 4.20 and affects the Volume Resize feature. As a result, ACS raises an error whenever a volume meets all of the following conditions:
• The volume state in ACS is not Allocated
• The volume type in ACS is QCOW2
• The storage pool in ACS is not StorPool
• A shrink operation (resizing to a smaller size) is attempted

Since we currently use LINSTOR as the storage provider with ACS, we are unable to shrink any QCOW2 volumes.

versions

4.20.2.0

The steps to reproduce the bug

1. Have LINSTOR Storage provider
2. Create a QCOW2 volume and assign it to the VM
3. Try to resize volume with shrink enabled

What to do about it?

Allow any storage provider to shrink volumes

[weizhouapache]

cc @slavkap

[slavkap]

@OlegChuev, according to the code before the mentioned PR change, shrinking QCOW2 volumes is not supported. Before my changes there is a check if the volume is QCOW2

if (volume != null && ImageFormat.QCOW2.equals(volume.getFormat()) && !Volume.State.Allocated.equals(volume.getState()))

[slavkap]

@weizhouapache , @DaanHoogland, I don't think that this is a regression. If you check the code before my change shrinking volumes in QCOW2 was not allowed for all storage pools (it is possible only in Allocated state). My change is only to pass this if the volumes are on StorPool

[weizhouapache]

thanks @slavkap for the investigation !

@OlegChuev
can you confirm that it worked in older versions but not in 4.20.2.0 ?

cc @rp-

[OlegChuev]

thanks @slavkap for the investigation !

@OlegChuev can you confirm that it worked in older versions but not in 4.20.2.0 ?

cc @rp-

If I’m not mistaken, it definitely worked in version 4.19, and after upgrading to 4.20 we noticed that volume shrinking no longer works.

[rp-]

I can confirm that shrinking worked/works in 4.19, with Linstor storage, from CloudStack side.

As a side note, in the current Linstor release there is bug were shrinking doesn't work and would leave resources in "resizing" state.
And also shrinking is a delicate topic as not everything supports it (xfs)

[nvazquez]

Hi @OlegChuev @rp-, I think as @slavkap and @weizhouapache it may not be a regression from the PR above as the check for the volume state was already added before. I did a quick test on 4.19.3 with NFS and a volume in Ready state shrinking failed with the same error:

Failed to resize volume operation of volume UUID: [96de79ce-a918-49ae-afda-1b0a3b1bec64] due to - Unable to shrink volumes of type QCOW2

Can you specify the exact CloudStack version which is working for the Linstor storage? I have tried tracing the code back and found the original check is added by the PR: https://github.com/apache/cloudstack/pull/5008/files#diff-b93da5c5293f8cb4470ff6b1642d312131bb053df07b71b4b951b08dff0ad9abR1963-R1969 on 4.17.

[rp-]

@nvazquez I did today a fresh 4.19.3 Linstor setup and could shrink ROOT and DATA volumes.

But as I found out today, shrinking in Linstor is currently not really working and needs some more fixes, I would be happy if shrinking isn't working.

[nvazquez]

Thanks @rp- if possible can you share the management server logs around the resize API operation? It is strange the code may be following a different execution path

[slavkap]

@nvazquez, thank you for testing this! @rp- are all Linstor volumes in QCOW2 format?