Resize Volume

Volumes can be resized based on free space on the media that the volumes are using. If there isn’t enough free space to satisfy the new requirements post-resizing, then the resize will fail. For example, if a volume is distributed over 2 media and there isn’t enough free space on one of them for the resize, then it will fail.

To address such a case, you can authorize data movement, so that free space on any other media which is defined in the system, can be used.

Resizing can be configured via the UI as follows:

Go to Storage > Volumes select a Volume in the table, and click on Resize.

Enter the new size requested for the Volume. It must be greater than the currently configured size, but no more than 10 times the current size.

Enable the Allow Data Movement toggle switch, to allow the data to use free space on any available media, rather than just the media which is currently assigned to the Volume. If media is found with enough free space, a migration of the required slices will begin. The mechanism will move only the slices needed, which are currently assigned to media without enough free space.

The movement process may take up to 8 hours.

A resize operation will be assigned a Job ID. The operation is asynchronous. The volume_modify_extend job can be monitored in the UI, or via API using GET /jobs API. When the job attains the state Done, the resize will have been completed successfully. The state Error indicates that the operation has failed.

These are the possible messages that may be displayed during the operation:

• GetModificationPlan: Could not find an in-place modification plan. This means the Volume’s size can’t be increased using free space on the assigned media.

• GetModificationPlan: Data movement is not supported for volumes with no resiliency. The feature cannot be used if the selected Volume is configured with zero node, media and zone resiliency.

• GetMovementModificationPlan: Found movement plan. Data Movement is enabled. The operation is now being attempted.

• GetModificationPlan: Failed to get modificationPlan for resizing volumeGroup. Data Movement is enabled, but a suitable target for the volume resizing cannot be found.

During Data Movement, the following operations are blocked on the selected Volume:

• Attachment create

• Attachment delete

• Attachment modify

• Snapshot create

• Snapshot delete

• Snapshot modify

• Snapshot rollback

• Volume recovery

• Additional Data Movement operation

Note: A Volume Resize operation, with or without Data Movement enabled, will also increase the filesystem, if it was provisioned by Volumez. If you provision a raw Volume, and then create a filesystem on it, then a resize operation will not affect it.

Resize via CSI

Data Movement is currently not supported via CSI. To modify a Volume, please consult the following link.

https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/

Resize via API

You can resize a Volume via API. Define the desired size using the size attribute, and use the optional allowdatamovement flag which is set to false by default.

• "name": "string",

• "volumeid": "string",

• "type": "file",

• "contentvolume": "string",

• "contentsnapshot": "string",

• "size": 1,

• "maxsize": 0,

• "policy": "string",

• "consistencygroup": "string",

• "node": "string",

• "zone": "string",

• "zonereplica": "string",

• "volumegroupname": "string",

• "volumegroupid": "string",

• "replicationnode": "string",

• "replicationvolumegroupname": "string",

• "replicationvolumegroupid": "string",

• "volumerecoveryjob": "string",

• "state": "string",

• "status": "string",

• "progress": 0,

• "capacitygroup": "string",

• "throttlingscheme": "string",

• "allowdatamovement": false,

• "flavor": "regular"